So SRX-12 thinks the NAT'ed ESP packets are destined for itself, and not part of a NAT session. 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. SRX-13 IPSEC run show security ipsec statisticsīad headers: 0, Bad trailers: we perform a flow trace with all of the IPSEC flags turned on we find that SRX-12 is dropping packets. SRX-11 IPSEC run show security ipsec statisticsĪH authentication failures: 0, Replay errors: 0ĮSP authentication failures: 0, ESP decryption failures: 0īad headers: 0, Bad trailers: still, we find that SRX-13 is both encrypting and decrypting ESP packets. However, SRX-11 is encrypting packets, but it's not getting anything in return to decrypt. [edit security 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. 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).ĭisabling 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. It does add a more overhead in the form of a standard UDP header and introduces more packet noise with NAT keepalives. However, using NAT-T may not always be desired behavior. NAT-T negotiations for IPSEC are all on by default on the SRX.
0 Comments
Leave a Reply. |