Juniper SRX Spoke-to-Spoke IPSEC VPN when both spokes are behind NAT.
Attachment:
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
Juniper SRX Spoke-to-Spoke IPSEC VPN when both spokes are behind NAT.
[attachment=0]srx-ipsec-vpn-spoke-behind-nat.png[/attachment]
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;
}
}
[/code]
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;
}
}
[/code]
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)
[/code]
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
[/code]
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)
[/code]
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
[/code]