NATing and the Temptation of the Source/Destination NAT Combo

The temptation is to look at each site individually, and use a combination of source and destination NAT to translate between the duplicate IP addresses and their mapped IPs. This will work, but as we will see it can cause some unwanted behavior.

To keep things orderly we'll follow the path of the traffic from the client to the server. We'll start at the client side, work our way over to the server and then take care of the return traffic from the server to the client. First, we translate the source of any traffic going from 192.168.1.0/24 to it's mapped to the IP space for the client pool. We'll limit the range to the .2 to the .254 so we don't inadverntenly use the network, broadcast or an IP we might give a router later on (.1).

NAT rules to map client source addresses

[edit security nat source]
juniper@SRX-11# show 
pool CLIENT-POOL {
    address {
        192.168.81.2/32 to 192.168.81.254/32;
    }
    port no-translation;
}
address-persistent;
rule-set CLIENT-2-SERVER {
    from zone TRUST;
    to zone UNTRUST;
    rule CLIENT-2-SERVER {
        match {
            source-address 192.168.1.0/24;
        }
        then {
            source-nat {
                pool {
                    CLIENT-POOL;
                }
            }
        }
    }
}
                                        
[edit security nat source]
juniper@SRX-11# 

We'll test our NAT rules from the client to see how things are progressing.

IP traffic to the server's mapped IP

juniper@client:~$ nc 192.168.80.80 80

And the resulting session on SRX-11.

NAT session on SRX-11

juniper@SRX-11# run show security flow session nat 
Session ID: 3949, Policy name: default-policy-00/2, Timeout: 12, Valid
  In: 192.168.1.80/58705 --> 192.168.81.80/80;tcp, If: ge-0/0/4.0, Pkts: 4, Bytes: 240
  Out: 192.168.81.80/80 --> 192.168.80.3/58705;tcp, If: ge-0/0/5.0, Pkts: 0, Bytes: 0
Total sessions: 1

[edit security nat source]
juniper@SRX-11# 

Now we'll move onto the SRX that is sitting in front of the server. We conjure up some destination NAT to remap the 192.168.80.0/24 space back to the 192.168.1.0/24 space. This takes care of the other side of the flow.

Destination NAT rules on SRX-13

[edit security nat destination]
juniper@SRX-13# show 
pool SERVER-POOL {
    address 192.168.1.0/24;
}
rule-set CLIENT-2-SERVER {
    from zone UNTRUST;
    rule CLIENT-2-SERVER {
        match {
            destination-address 192.168.80.0/24;
        }
        then {
            destination-nat {
                pool {
                    SERVER-POOL;
                }
            }
        }
    }
}

[edit security nat destination]
juniper@SRX-13# 

We perform a quick test again by running a netcat listener on the server.

Server listener

juniper@server:~$ nc -l 5555 < testfile 

We connect to the server from the client, and we instantly get a connection.

Client connection succeeding

juniper@client:~$ nc 192.168.80.80 5555
This is a IP overlap test.  Client to Server
juniper@client:~$ 

Now we can examine the NAT session on the far side of our test on SRX-13.

NAT session on SRX-13

[edit security nat]
juniper@SRX-13# run show security flow session nat 
Session ID: 4345, Policy name: default-policy-00/2, Timeout: 1778, Valid
  In: 192.168.81.10/42942 --> 192.168.80.80/5555;tcp, If: ge-0/0/5.0, Pkts: 2, Bytes: 112
  Out: 192.168.1.80/5555 --> 192.168.81.10/42942;tcp, If: ge-0/0/3.0, Pkts: 1, Bytes: 60
Total sessions: 1

[edit security nat]
juniper@SRX-13# 

This works, but only in one direction -- from the client to the server. To make it bidirectional we configure the same source and destination NAT rules in the reverse direction. However, when monitoring the sessions that are created on the SRX's we can see a possible issue that may arise later on. We run the exact same commands on the client and server, and repeat the test.

Additional NAT session on SRX-11

[edit security nat source]
juniper@SRX-11# run show security flow session 
Session ID: 4212, Policy name: default-policy-00/2, Timeout: 1756, Valid
  In: 192.168.1.80/42944 --> 192.168.80.80/5555;tcp, If: ge-0/0/4.0, Pkts: 2, Bytes: 112
  Out: 192.168.80.80/5555 --> 192.168.81.12/42944;tcp, If: ge-0/0/5.0, Pkts: 1, Bytes: 60
Total sessions: 1

[edit security nat source]
juniper@SRX-11# 

Addtional NAT session on SRX-13

juniper@SRX-13# run show security flow session nat    
Session ID: 4347, Policy name: default-policy-00/2, Timeout: 1798, Valid
  In: 192.168.81.12/42944 --> 192.168.80.80/5555;tcp, If: ge-0/0/5.0, Pkts: 2, Bytes: 112
  Out: 192.168.1.80/5555 --> 192.168.81.12/42944;tcp, If: ge-0/0/3.0, Pkts: 1, Bytes: 60
Total sessions: 1

[edit security nat]
juniper@SRX-13# 

The IP address that the client has been mapped to changed from 192.168.81.10 to 192.168.80.12. The lack of a 1:1 mapping can make troubleshooting difficult. If some tighter firewall policies were needed, for instance if only the client on the .80 address was allowed to ssh to the server with the .80 address, it would be impossible to write an accurate one that would work all of the time, but not let any other IPs slip through.