Juniper SRX Spoke-to-Spoke IPSEC VPN \w spokes behind NAT.

Juniper SRX Spoke-to-Spoke IPSEC VPN when both spokes are behind NAT.

Attachment:

srx-ipsec-vpn-spoke-behind-nat.png [28.4 KiB]
Downloaded 1320 times

While researching on the Juniper SRX IPSEC VPN documentation and all the diverse scenarios, I noticed there is no documentation/kb article that describe the situation when one needs to connect two SRX spokes, two endpoints when both of them are behind NAT as in the above test diagram.

As a dependency, one of the spokes needs to be behind static NAT because of reasons explained later in this article.

In the diagram, SRX2 is the node behind static NAT. All IPs sourced 192.168.0.254 will be sourced NATed to 10.0.0.3 and all IP destined for 10.0.0.3 will be destination NATed to 192.168.0.254. This part of the configuration is irrelevant for now.

Ike configuration as well as interface configuration on both boxes is shown below.

SRX1 - Interface and Ike configuration:

Code:

root@SRX1# show security ike         
traceoptions {
    file kmd size 10m;
}
proposal IKE-SECURE-PROPOSAL {
    authentication-method pre-shared-keys;
    dh-group group5;
    authentication-algorithm sha-256;
    encryption-algorithm aes-256-cbc;
    lifetime-seconds 86400;
}
policy IKE-SECURE-POLICY {
    mode aggressive;
    proposals IKE-SECURE-PROPOSAL;
    pre-shared-key ascii-text "$9$GCjkPFnCBIc5QIcylLXUjHq5Q369pO1"; ## SECRET-DATA
}
gateway IKE-GW-DYNAMIC {
    ike-policy IKE-SECURE-POLICY;
    address 10.0.0.3;
    local-identity user-at-hostname "test@ivorde.ro";
    external-interface ge-0/0/15;
}

[edit]
root@SRX1# show interfaces ge-0/0/15 
unit 0 {
    family inet {
        address 192.168.0.10/24;
    }
}

SRX1 - Interface and Ike configuration:

Code:

root@SRX2# show security ike 
traceoptions {
    file kmd size 10m;
}
proposal IKE-SECURE-PROPOSAL {
    authentication-method pre-shared-keys;
    dh-group group5;
    authentication-algorithm sha-256;
    encryption-algorithm aes-256-cbc;
    lifetime-seconds 86400;
}
policy IKE-SECURE-POLICY {
    mode aggressive;
    proposals IKE-SECURE-PROPOSAL;
    pre-shared-key ascii-text "$9$5znCO1hKMXtuMX7-2gTz36tuBIEyev"; ## SECRET-DATA
}
gateway IKE-GW-DYNAMIC {
    ike-policy IKE-SECURE-POLICY;
    dynamic user-at-hostname "test@ivorde.ro";
    external-interface ge-0/0/15;
}

[edit]
root@SRX2# show interfaces ge-0/0/15 
unit 0 {
    family inet {
        address 192.168.0.254/24;
    }
}

So both devices reside in the same private IP space with source nat on one side and static nat on the other side (SRX2).

The above configuration is missing something on SRX2 (the SRX behind static NAT).

As seen on all documentation, to support Ipsec VPN roadwarriors (i.e. Dynamic clients), ike needs to use "dynamic" identity, as see on SRX2 and no local identity. This is because most scenarios rely on the fact that the IKE gateway is using a fixed public IP address that gets sent as identity by default.

Below is a tcpdump pcap capture on the SRX2 node:

Code:

tcpdump -nni ge-0/0/15 -s1500 -v port 500
Address resolution is OFF.
Listening on ge-0/0/15, capture size 1500 bytes




13:02:15.727577  In IP (tos 0xc0, ttl  63, id 62271, offset 0, flags [none], proto: UDP (17), length: 554) 10.0.0.2.500 > 192.168.0.254.500: isakmp 1.0 msgid 00000000: phase 1 I agg:
    (sa: doi=ipsec situation=identity
        (p: #1 protoid=isakmp transform=1 spi=656f7e0a1b7462c5
            (t: #0 id=ike (type=enc value=0007)(type=keylen value=0100)(type=group desc value=0005)(type=hash value=0004)(type=lifetype value=sec)(type=lifeduration len=4 value=00015180)(type=auth value=preshared))))
    (ke: key len=192)
    (nonce: n len=16)
    (id: idtype=user FQDN protoid=ip port=0 len=14 test@ivorde.ro)
    (vid: len=16)
    (vid: len=16)
    (vid: len=16)
    (vid: len=16)
    (vid: len=16)
    (vid: len=16)
    (vid: len=16)
    (vid: len=16)
    (vid: len=28)
13:02:15.778798 Out IP (tos 0xc0, ttl  64, id 28903, offset 0, flags [none], proto: UDP (17), length: 644) 192.168.0.254.500 > 10.0.0.2.500: isakmp 1.0 msgid 00000000: phase 1 R agg:
    (sa: doi=ipsec situation=identity
        (p: #1 protoid=isakmp transform=1
            (t: #0 id=ike (type=enc value=0007)(type=keylen value=0100)(type=group desc value=0005)(type=hash value=0004)(type=lifetype value=sec)(type=lifeduration len=4 value=00015180)(type=auth value=preshared))))
    (ke: key len=192)
    (nonce: n len=16)
    (id: idtype=IPv4 protoid=ip port=0 len=4 192.168.0.254)
    (hash: len=32)
    (vid: len=16)
    (vid: len=16)
    (vid: len=16)
    (vid: len=16)
    (vid: len=16)
    (vid: len=16)
    (vid: len=16)
    (vid: len=16)
    (vid: len=28)
    (#20)
    (#20)

As seen in the second packet, SRX2 sends it's identity as the outgoing IP (192.168.0.254) which will confuse SRX1 as it knows the gateway's IP is 10.0.0.3.

Obviously this fails with reason "iked_pm_ike_sa_done ID validation fails".

Fixing this needs the ike gateway to send it's identity as the IP that will be used when outgoing packets are source NATed:

Code:

[edit]
root@SRX2# set security ike gateway IKE-GW-DYNAMIC local-identity inet 10.0.0.3  

[edit]
root@SRX2# commit 

And here is the difference:

Code:

13:20:06.066814  In IP (tos 0xc0, ttl  63, id 446, offset 0, flags [none], proto: UDP (17), length: 554) 10.0.0.2.500 > 192.168.0.254.500: isakmp 1.0 msgid 00000000: phase 1 I agg:
    (sa: doi=ipsec situation=identity
        (p: #1 protoid=isakmp transform=1 spi=0c9986425448edc1
            (t: #0 id=ike (type=enc value=0007)(type=keylen value=0100)(type=group desc value=0005)(type=hash value=0004)(type=lifetype value=sec)(type=lifeduration len=4 value=00015180)(type=auth value=preshared))))
    (ke: key len=192)
    (nonce: n len=16)
    (id: idtype=user FQDN protoid=ip port=0 len=14 test@ivorde.ro)
    (vid: len=16)
    (vid: len=16)
    (vid: len=16)
    (vid: len=16)
    (vid: len=16)
    (vid: len=16)
    (vid: len=16)
    (vid: len=16)
    (vid: len=28)
13:20:06.118367 Out IP (tos 0xc0, ttl  64, id 32510, offset 0, flags [none], proto: UDP (17), length: 644) 192.168.0.254.500 > 10.0.0.2.500: isakmp 1.0 msgid 00000000: phase 1 R agg:
    (sa: doi=ipsec situation=identity
        (p: #1 protoid=isakmp transform=1
            (t: #0 id=ike (type=enc value=0007)(type=keylen value=0100)(type=group desc value=0005)(type=hash value=0004)(type=lifetype value=sec)(type=lifeduration len=4 value=00015180)(type=auth value=preshared))))
    (ke: key len=192)
    (nonce: n len=16)
    (id: idtype=IPv4 protoid=ip port=0 len=4 10.0.0.3)
    (hash: len=32)
    (vid: len=16)
    (vid: len=16)
    (vid: len=16)
    (vid: len=16)
    (vid: len=16)
    (vid: len=16)
    (vid: len=16)
    (vid: len=16)
    (vid: len=28)
    (#20)
    (#20)

And IKE phase1 SA is up:

Code:

root@SRX1> show security ike sa   
Index   State  Initiator cookie  Responder cookie  Mode           Remote Address   
5477632 UP     0c9986425448edc1  a0db104dec71e391  Aggressive     10.0.0.3        

root@SRX1> show security ike active-peer 
Remote Address                      Port     Peer IKE-ID                         XAUTH username                      Assigned IP
10.0.0.3                            4500     10.0.0.3                          

Linux, FreeBSD, Juniper, Cisco / Network security articles and troubleshooting guides

Juniper SRX Spoke-to-Spoke IPSEC VPN \w spokes behind NAT.

Juniper SRX Spoke-to-Spoke IPSEC VPN \w spokes behind NAT.