This is an illustrated guide that shows how to configure the various types of Network Address Translation (NAT) on the Juniper SRX series. Each example lists the configuration on the SRX, as well as what the client and server on either side of the SRX doing the NATing see and experience through working examples.
NAT-T negotiations for IPSEC are all on by default on the SRX. However, using NAT-T may not always be desired behavior. It does add a more overhead in the form of a standard UDP header and introduces more packet noise with NAT keepalives. An operator might rather have a tunnel go down and take an alternate path if something starts NATing between IPSEC peers (which would require VPN monitoring, a dynamic routing protocol, RPM probe or OAM).
Disabling NAT-T on the SRX is configured with the no-nat-traversal on each IKE gateway that shouln't bother with doing NAT-T negotiations.
SRX-13 configuration to disable NAT-T
[edit security ike]
gateway SRX-13 {
ike-policy IKE-POL;
address 192.168.13.13;
no-nat-traversal;
local-identity hostname srx-11;
external-interface lo0.0;
}
[edit security ike]
juniper@SRX-11#
When we apply this to our IPSEC tunnel between SRX-11 and SRX-13 we find that IP Protocol 50 (ESP) is being used for transport. However, SRX-11 is encrypting packets, but it's not getting anything in return to decrypt.
SRX-11 IPSEC statistics
juniper@SRX-11# run show security ipsec statistics ESP Statistics: Encrypted bytes: 71288 Decrypted bytes: 0 Encrypted packets: 469 Decrypted packets: 0 AH Statistics: Input bytes: 0 Output bytes: 0 Input packets: 0 Output packets: 0 Errors: AH authentication failures: 0, Replay errors: 0 ESP authentication failures: 0, ESP decryption failures: 0 Bad headers: 0, Bad trailers: 0 [edit] juniper@SRX-11#
Stranger still, we find that SRX-13 is both encrypting and decrypting ESP packets.
SRX-13 IPSEC statistics
juniper@SRX13# run show security ipsec statistics ESP Statistics: Encrypted bytes: 74328 Decrypted bytes: 40404 Encrypted packets: 489 Decrypted packets: 481 AH Statistics: Input bytes: 0 Output bytes: 0 Input packets: 0 Output packets: 0 Errors: AH authentication failures: 0, Replay errors: 0 ESP authentication failures: 0, ESP decryption failures: 0 Bad headers: 0, Bad trailers: 0 [edit] juniper@SRX13#
When we perform a flow trace with all of the IPSEC flags turned on we find that SRX-12 is dropping packets. It is recieving ESP packets on it's interface performing the NAT operation, ge-0/0/5.0, but it isn't finding a matching SPI. So SRX-12 thinks the NAT'ed ESP packets are destined for itself, and not part of a NAT session.
SRX-12 flow trace of ESP traffic
Jan 11 16:01:06 16:01:06.363994:CID-0:RT: ----- flow_process_pkt rc 0x0 (fp rc 0) Jan 11 16:01:06 16:01:06.369012:CID-0:RT:<192.168.13.13/21269->172.18.2.224/1646;50> matched filter IPSEC2: Jan 11 16:01:06 16:01:06.369024:CID-0:RT:packet [152] ipid = 32925, @0x4abfb4da Jan 11 16:01:06 16:01:06.369028:CID-0:RT:---- flow_process_pkt: (thd 1): flow_ctxt type 15, common flag 0x0, mbuf 0x4abfb280, rtbl_idx = 0 Jan 11 16:01:06 16:01:06.369034:CID-0:RT: flow process pak fast ifl 72 in_ifp ge-0/0/5.0 Jan 11 16:01:06 16:01:06.369039:CID-0:RT: ge-0/0/5.0:192.168.13.13->172.18.2.224, 50 Jan 11 16:01:06 16:01:06.369046:CID-0:RT: find flow: table 0x5cb394d8, hash 39076(0xffff), sa 192.168.13.13, da 172.18.2.224, sp 21269, dp 1646, proto 50, tok 7 Jan 11 16:01:06 16:01:06.369058:CID-0:RT: find flow: table 0x5cb394d8, hash 56403(0xffff), sa 192.168.13.13, da 172.18.2.224, sp 0, dp 0, proto 50, tok 7 Jan 11 16:01:06 16:01:06.369068:CID-0:RT: find flow: table 0x5cb394d8, hash 64400(0xffff), sa 0.0.0.0, da 0.0.0.0, sp 21269, dp 1646, proto 50, tok 7 Jan 11 16:01:06 16:01:06.369079:CID-0:RT: no session found, start first path. in_tunnel - 0x0, from_cp_flag - 0 Jan 11 16:01:06 16:01:06.369088:CID-0:RT:check self-traffic on ge-0/0/5.0, in_tunnel 0x0 Jan 11 16:01:06 16:01:06.369092:CID-0:RT:pak_for_self: No handler function found for proto:50, dst-port:0, drop pkt Jan 11 16:01:06 16:01:06.369096:CID-0:RT:retcode: 0x1 Jan 11 16:01:06 16:01:06.369098:CID-0:RT:pak_for_self : proto 50, dst port 0, action 0x0 Jan 11 16:01:06 16:01:06.369101:CID-0:RT: flow_first_create_session Jan 11 16:01:06 16:01:06.369113:CID-0:RT:First path alloc and instl pending session, natp=0x5f9fc468, id=2801 Jan 11 16:01:06 16:01:06.369118:CID-0:RT: flow_first_in_dst_nat: in, out dst_adr 172.18.2.224, sp 0, dp 0 Jan 11 16:01:06 16:01:06.369125:CID-0:RT: chose interface ge-0/0/5.0 as incoming nat if. Jan 11 16:01:06 16:01:06.369131:CID-0:RT: packet dropped: for self but not interested Jan 11 16:01:06 16:01:06.369133:CID-0:RT: packet dropped, packet dropped: for self but not interested. Jan 11 16:01:06 16:01:06.369187:CID-0:RT:flow_initiate_first_path: first pak no session Jan 11 16:01:06 16:01:06.369190:CID-0:RT: flow find session returns error. Jan 11 16:01:06 16:01:06.369193:CID-0:RT: ----- flow_process_pkt rc 0x7 (fp rc -1) Jan 11 16:01:07 16:01:06.1005564:CID-0:RT:jsf sess close notify Jan 11 16:01:07 16:01:06.1005572:CID-0:RT:flow_ipv4_del_flow: sess 2801, in hash 32
This test was repeated with a Linux box running iptables with simple IP masqeurading and the connection still came up as we only had a single NAT mapping, so it appeared to be static, and the Linux box wasn't trying to do anything with the ESP traffic other than forward it.
There is a way to get this to work on the SRX though, using the ike-esp-nat application layer gateway.