Baselining our SRX

Before we look at NAT, we'll create some test sessions to see what "normal" traffic passing through the SRX looks like by running the nat-test_overload_multipleIP.sh on the client without any NAT rules configured. The session table on the SRX looks like:

Sessions from Client to Server (without NAT)

juniper@SRX# run show security flow session 
Session ID: 1126, Policy name: ACCEPT-LOG/4, Timeout: 300, Valid
  In: 192.168.200.88/51912 --> 10.80.80.80/80;tcp, If: ge-0/0/4.0, Pkts: 92, Bytes: 4911
  Out: 10.80.80.80/80 --> 192.168.200.88/51912;tcp, If: ge-0/0/3.0, Pkts: 280, Bytes: 395392

Session ID: 1127, Policy name: ACCEPT-LOG/4, Timeout: 300, Valid
  In: 192.168.200.89/51265 --> 10.80.80.80/80;tcp, If: ge-0/0/4.0, Pkts: 92, Bytes: 4911
  Out: 10.80.80.80/80 --> 192.168.200.89/51265;tcp, If: ge-0/0/3.0, Pkts: 280, Bytes: 395392

Session ID: 1128, Policy name: ACCEPT-LOG/4, Timeout: 300, Valid
  In: 192.168.200.86/51231 --> 10.80.80.80/80;tcp, If: ge-0/0/4.0, Pkts: 92, Bytes: 4911
  Out: 10.80.80.80/80 --> 192.168.200.86/51231;tcp, If: ge-0/0/3.0, Pkts: 280, Bytes: 395392

Session ID: 1129, Policy name: ACCEPT-LOG/4, Timeout: 300, Valid
  In: 192.168.200.85/58984 --> 10.80.80.80/80;tcp, If: ge-0/0/4.0, Pkts: 92, Bytes: 4911
  Out: 10.80.80.80/80 --> 192.168.200.85/58984;tcp, If: ge-0/0/3.0, Pkts: 280, Bytes: 395392
                                        
Session ID: 1130, Policy name: ACCEPT-LOG/4, Timeout: 300, Valid
  In: 192.168.200.84/46122 --> 10.80.80.80/80;tcp, If: ge-0/0/4.0, Pkts: 92, Bytes: 4911
  Out: 10.80.80.80/80 --> 192.168.200.84/46122;tcp, If: ge-0/0/3.0, Pkts: 280, Bytes: 395392

Session ID: 1131, Policy name: ACCEPT-LOG/4, Timeout: 300, Valid
  In: 192.168.200.83/48201 --> 10.80.80.80/80;tcp, If: ge-0/0/4.0, Pkts: 92, Bytes: 4911
  Out: 10.80.80.80/80 --> 192.168.200.83/48201;tcp, If: ge-0/0/3.0, Pkts: 280, Bytes: 395392

Session ID: 1132, Policy name: ACCEPT-LOG/4, Timeout: 300, Valid
  In: 192.168.200.82/59972 --> 10.80.80.80/80;tcp, If: ge-0/0/4.0, Pkts: 92, Bytes: 4911
  Out: 10.80.80.80/80 --> 192.168.200.82/59972;tcp, If: ge-0/0/3.0, Pkts: 280, Bytes: 395392

Session ID: 1133, Policy name: ACCEPT-LOG/4, Timeout: 300, Valid
  In: 192.168.200.87/50783 --> 10.80.80.80/80;tcp, If: ge-0/0/4.0, Pkts: 91, Bytes: 4859
  Out: 10.80.80.80/80 --> 192.168.200.87/50783;tcp, If: ge-0/0/3.0, Pkts: 280, Bytes: 395392

Session ID: 1134, Policy name: ACCEPT-LOG/4, Timeout: 300, Valid
  In: 192.168.200.81/45454 --> 10.80.80.80/80;tcp, If: ge-0/0/4.0, Pkts: 91, Bytes: 4859
  Out: 10.80.80.80/80 --> 192.168.200.81/45454;tcp, If: ge-0/0/3.0, Pkts: 280, Bytes: 395392
Total sessions: 9

[edit]
juniper@SRX# 

What is important to note here for later comparison is to look at the symmetry between the two wings created for each session, the In and the Out. The In wing we can see that the IP and port for each session on the inbound interface ge-0/0/4, matches with the Out wing as traffic flows back through ge-0/0/3. With NAT, the IP on the return "Out" wing will not match, and the port may not match either.

Note that since this is a controlled environment, with no other traffic than what we're creating here, we're taking the quick way of looking at the session table by just viewing the entire thing. If this were a busy lab, or an operational environment, we'd probably need to use some more specific attributes like the source-prefix, destination-port, session-id and so forth to limit ourselves from being overwhelmed by the output.

To try to give the client some insight on how it's traffic is being NAT'ed, we can run the STUN client talking to the stund daemon on the server.

stun-client run from client to server (without NAT)

juniper@client:~$ stun 10.80.80.80
STUN client version 0.96
Primary: Open	
Return value is 0x000001
juniper@client:~$ 

The output indicates that no NAT is being deteteced.