When configuring a VPN on the SRX which uses NATT in order to establish, if there is a firewall filter configured against the loopback interface, the tunnel may fail to come up and will stay in a DOWN state from the output of show security ike security-association.
NATT is short for Network Address Translation Traversal. By default, the IKE communication will detect if there is a device in between the two vpn peers that performs NAT functions. In that event, the tunnel will negotiate the connection by encapsulating the original IKE packet with one that uses port 4500.
More information concerning this traversal can be found here: https://www.juniper.net/documentation/us/en/software/junos/vpn-ipsec/topics/topic-map/security-route-based-and-policy-based-vpns-with-nat-t.html
Running the output from "show security ipsec inactive-tunnels" may show that there is no response from the peer end:
root@srx> show security ipsec inactive-tunnels
Total inactive tunnels: 20
Total inactive tunnels with establish immediately: 18
ID Port Gateway Tunnel Down Reason
131073 500 10.10.10.10 No response from peer. Negotiation failed (6 times)
Yet, while the output from "show security ike security-association" says the tunnel is in a DOWN state, there is a responder cookie so there was likely a response:
root@srx> show security ike security-associations brief no-forwarding
Index State Initiator cookie Responder cookie Mode Remote Address
3306795 DOWN dad00c7de18894ae 596a9a8a7405802b Main 10.10.10.10
There is also a firewall filter present (assigned to the loopback interface) which only accepts port 500 but not 4500:
firewall {
filter PROTECT-IN {
term IKE {
from {
destination-address {
10.10.10.10/32;
}
protocol udp;
port 500;
then accept;
If we run an ike traceoption using the per-tunnel debugging method, we can see how the communication is attempting to use port 4500 and, while it is sending this to the peer, we appear to receive nothing in response:
e.g.
user@srx> request security ike debug-enable local 20.20.20.20 remote 10.10.10.10 level 9
Note: This will write to the /var/log/kmd log file by default (unless ike traceoptions has a different filename configured) and flag all is automatically done. Level 9 is required in order to see any NAT-T responses.
The following shows us retransmitting following us sending the packet. After a couple of attempts, we conclude that there is no response from the peer:
user@srx> show log kmd
...
[Sep 23 15:29:02][20.20.20.20 <-> 10.10.10.10] ike_send_packet: Start, send SA = { bca7160a bc4f0c6a - caf0048b 4ef63602}, nego = -1, dst = 10.10.10.10:4500
[Sep 23 15:29:02][20.20.20.20 <-> 10.10.10.10] ike_send_packet: Inserting retransmission timer after 10.000000 seconds
[Sep 23 15:29:12][20.20.20.20 <-> 10.10.10.10] IKEv1 packet S(20.20.20.20:4500 -> 10.10.10.10:4500): mID=00000000 (retransmit count=1)
[Sep 23 15:29:22][20.20.20.20 <-> 10.10.10.10] IKEv1 packet S(20.20.20.20:4500 -> 10.10.10.10:4500): mID=00000000 (retransmit count=2)
[Sep 23 15:29:32][20.20.20.20 <-> 10.10.10.10] iked_tunnel_event_add_event_in_gw: Updating tunnel-event for gateway gw-vpn-0bf09c9-1 with No response from peer. Negotiation failed
The solution to ensure that the firewall filter is allowing for port 4500 packets by adding this to the existing filter. After which, the tunnel will be seen coming up.
port 500 4500; <<< after adding the tunnel should be now up
3306795 UP dad00c7de18894ae 596a9a8a7405802b Main 10.10.10.10
2023-10-24 : Article Created by Dion Summers