This is an extremely long-overdue post, but I wanted to add a follow-up to the old blogpost Route-based VPN with Multiple Source/Destination Networks to a 3rd Party Device. While the previous method still works, it still had some drawbacks:
- It required the use of ephemeral IP address, which can be a waste of IP space
- It only worked if there was one destination network, as Next-Hop Tunnel Bindings (NHTBs) did not address which source network traffic came from
Traffic selectors were introduced as feature starting in Junos 12.1X46-D10 (SRX200, SRX1400, and SRX3k series) and Junos 17.3R1 (SRX300, SRX1500, SRX4k, and SRX5k series) for IKEv1. IKEv2 support was added in Junos 15.1X49-D100, meaning this is only available for the SRX300, SRX1500, SRX4k, and SRX5k series.
The example below shows two SRXs (SRX-1 and SRX-2) which need to allow access between 4 unique networks:
- SRX-1:
- 10.100.0.0/24
- 10.100.1.0/24
- SRX-2:
- 172.24.0.0/24
- 172.24.1.0/24
So now let’s configure the SRXs with a single IKE policy and gateway. The output of such a configuration is shown below:
SRX1:
root@SRX-1# show security ike
policy ike-policy-vpn {
mode main;
proposal-set standard;
pre-shared-key ascii-text "$9$iqfz9Cu0IctueWXxsY.P5F39Ehrv87/CORclLXjHqPz69Cu1Icn/hreW-dqmfT6A0ORSrvBI87-baJUjHq.5pu1cyKO1"; ## SECRET-DATA
}
gateway ike-vpn {
ike-policy ike-policy-vpn;
address 198.18.0.2;
external-interface ge-0/0/0;
}
SRX-2:
root@SRX-2# show security ike
policy ike-policy-vpn {
mode main;
proposal-set standard;
pre-shared-key ascii-text "$9$iqfz9Cu0IctueWXxsY.P5F39Ehrv87/CORclLXjHqPz69Cu1Icn/hreW-dqmfT6A0ORSrvBI87-baJUjHq.5pu1cyKO1"; ## SECRET-DATA
}
gateway ike-vpn {
ike-policy ike-policy-vpn;
address 198.18.0.1;
external-interface ge-0/0/0;
}
Now let’s check the IPSEC configuration:
SRX-1:
root@SRX-1# show security ipsec
policy ipsec-policy-vpn {
perfect-forward-secrecy {
keys group2;
}
proposal-set standard;
}
vpn ipsec-vpn {
bind-interface st0.0;
ike {
gateway ike-vpn;
ipsec-policy ipsec-policy-vpn;
}
}
SRX-2:
root@SRX-2# show security ipsec
policy ipsec-policy-vpn {
perfect-forward-secrecy {
keys group2;
}
proposal-set standard;
}
vpn ipsec-vpn {
bind-interface st0.0;
ike {
gateway ike-vpn;
ipsec-policy ipsec-policy-vpn;
}
}
To add in the traffic selectors we just need to add them under the [ security ipsec vpn ipsec-vpn ] stanza as shown below. Keep in mind that the local and remote IPs are different for each side of the tunnel. If these are duplicated/reversed the tunnels will not come up:
SRX-1:
[edit] root@SRX-1# edit security ipsec vpn ipsec-vpn [edit security ipsec vpn ipsec-vpn] root@SRX-1# set traffic-selector traffic-selector-1 local-ip 10.100.0.0/24 remote-ip 172.24.0.0/24 [edit security ipsec vpn ipsec-vpn] root@SRX-1# set traffic-selector traffic-selector-2 local-ip 10.100.0.0/24 remote-ip 172.24.1.0/24 [edit security ipsec vpn ipsec-vpn] root@SRX-1# set traffic-selector traffic-selector-3 local-ip 10.100.1.0/24 remote-ip 172.24.0.0/24 [edit security ipsec vpn ipsec-vpn] root@SRX-1# set traffic-selector traffic-selector-4 local-ip 10.100.1.0/24 remote-ip 172.24.1.0/24 [edit security ipsec vpn ipsec-vpn] root@SRX-1# top [edit] root@SRX-1# commit and-quit
SRX-2:
[edit] root@SRX-2# edit security ipsec vpn ipsec-vpn [edit security ipsec vpn ipsec-vpn] root@SRX-2# set traffic-selector traffic-selector-1 local-ip 172.24.0.0/24 remote-ip 10.100.0.0/24 [edit security ipsec vpn ipsec-vpn] root@SRX-2# set traffic-selector traffic-selector-1 local-ip 172.24.1.0/24 remote-ip 10.100.0.0/24 [edit security ipsec vpn ipsec-vpn] root@SRX-2# set traffic-selector traffic-selector-1 local-ip 172.24.0.0/24 remote-ip 10.100.1.0/24 [edit security ipsec vpn ipsec-vpn] root@SRX-2# set traffic-selector traffic-selector-1 local-ip 172.24.1.0/24 remote-ip 10.100.1.0/24 [edit security ipsec vpn ipsec-vpn] root@SRX-1# top [edit] root@SRX-1# commit and-quit
Once we’re out of configuration mode, let’s check on a few things. We can see that static routes are automatically added to the route table, which matches the next-hop of st0.0:
SRX-1:
root@SRX-1> show route protocol static
inet.0: 6 destinations, 6 routes (6 active, 0 holddown, 0 hidden)
+ = Active Route, - = Last Active, * = Both
172.24.0.0/24 *[Static/5] 00:04:38
> via st0.0
172.24.1.0/24 *[Static/5] 00:04:38
> via st0.0
SRX-2:
root@SRX-2> show route protocol static
inet.0: 8 destinations, 8 routes (8 active, 0 holddown, 0 hidden)
+ = Active Route, - = Last Active, * = Both
10.100.0.0/24 *[Static/5] 00:48:52
> via st0.0
10.100.1.0/24 *[Static/5] 00:00:31
> via st0.0
This is actually one of the helpful things about route-selectors; the SRX does not need to have static or dynamic routes configured anymore! The traffic selectors automatically inject routes as needed. Let’s start a ping from SRX-1 and see what happens to the IKE and IPSEC security associations:
root@SRX-1> ping source 10.100.0.1 172.24.0.1 PING 172.24.0.1 (172.24.0.1): 56 data bytes 64 bytes from 172.24.0.1: icmp_seq=1 ttl=64 time=40.471 ms 64 bytes from 172.24.0.1: icmp_seq=2 ttl=64 time=6.180 ms 64 bytes from 172.24.0.1: icmp_seq=3 ttl=64 time=5.932 ms ^C --- 172.24.0.1 ping statistics --- 4 packets transmitted, 3 packets received, 25% packet loss round-trip min/avg/max/stddev = 5.932/17.528/40.471/16.224 ms root@SRX-1> ping source 10.100.0.1 172.24.1.1 PING 172.24.1.1 (172.24.1.1): 56 data bytes 64 bytes from 172.24.1.1: icmp_seq=1 ttl=64 time=5.461 ms 64 bytes from 172.24.1.1: icmp_seq=2 ttl=64 time=5.889 ms 64 bytes from 172.24.1.1: icmp_seq=3 ttl=64 time=6.176 ms ^C --- 172.24.1.1 ping statistics --- 4 packets transmitted, 3 packets received, 25% packet loss round-trip min/avg/max/stddev = 5.461/5.842/6.176/0.294 ms root@SRX-1> ping source 10.100.1.1 172.24.0.1 PING 172.24.0.1 (172.24.0.1): 56 data bytes 64 bytes from 172.24.0.1: icmp_seq=1 ttl=64 time=6.362 ms 64 bytes from 172.24.0.1: icmp_seq=2 ttl=64 time=6.376 ms 64 bytes from 172.24.0.1: icmp_seq=3 ttl=64 time=6.438 ms ^C --- 172.24.0.1 ping statistics --- 4 packets transmitted, 3 packets received, 25% packet loss round-trip min/avg/max/stddev = 6.362/6.392/6.438/0.033 ms root@SRX-1> ping source 10.100.1.1 172.24.1.1 PING 172.24.1.1 (172.24.1.1): 56 data bytes 64 bytes from 172.24.1.1: icmp_seq=1 ttl=64 time=6.086 ms 64 bytes from 172.24.1.1: icmp_seq=2 ttl=64 time=11.969 ms 64 bytes from 172.24.1.1: icmp_seq=3 ttl=64 time=6.013 ms ^C --- 172.24.1.1 ping statistics --- 4 packets transmitted, 3 packets received, 25% packet loss round-trip min/avg/max/stddev = 6.013/8.023/11.969/2.791 ms
The first ping for each source/destination combination will drop initially; this is normal. The IPSEC VPNs do not come online unless there is traffic between the VPN networks, or if establish-tunnels immediately is configured under the IPSEC stanza. Let’s check out the IKE and IPSEC security associations now:
root@SRX-1> show security ike security-associations Index State Initiator cookie Responder cookie Mode Remote Address 7811565 UP 5b335de6850b8600 ac98ac166d8f8a82 Main 198.18.0.2
root@SRX-1> show security ipsec security-associations Total active tunnels: 4 ID Algorithm SPI Life:sec/kb Mon lsys Port Gateway <268173313 ESP:3des/sha1 c0b9f048 3451/ unlim - root 500 198.18.0.2 >268173313 ESP:3des/sha1 1867a811 3451/ unlim - root 500 198.18.0.2 <268173314 ESP:3des/sha1 f3f2fb99 3459/ unlim - root 500 198.18.0.2 >268173314 ESP:3des/sha1 80c6bc6a 3459/ unlim - root 500 198.18.0.2 <268173315 ESP:3des/sha1 181e76dd 3468/ unlim - root 500 198.18.0.2 >268173315 ESP:3des/sha1 1e32c078 3468/ unlim - root 500 198.18.0.2 <268173316 ESP:3des/sha1 980f80e5 3475/ unlim - root 500 198.18.0.2 >268173316 ESP:3des/sha1 dbd7129e 3475/ unlim - root 500 198.18.0.2
So there is one IKE SA since SRX-1 is connecting to a single IKE Gateway (SRX-2), but there are 4 active tunnels! Since we have 4 unique traffic selectors each one will generate a unique security association. Let’s drill down into one of the security associations by a traffic-selector:
root@SRX-1> show security ipsec security-associations traffic-selector traffic-selector-1
Total active tunnels: 1
ID Algorithm SPI Life:sec/kb Mon lsys Port Gateway
<268173313 ESP:3des/sha1 c0b9f048 3239/ unlim - root 500 198.18.0.2 >268173313 ESP:3des/sha1 1867a811 3239/ unlim - root 500 198.18.0.2
root@SRX-1> show security ipsec security-associations index 268173313
ID: 268173313 Virtual-system: root, VPN Name: ipsec-vpn
Local Gateway: 198.18.0.1, Remote Gateway: 198.18.0.2
Traffic Selector Name: traffic-selector-1
Local Identity: ipv4(10.100.0.0-10.100.0.255)
Remote Identity: ipv4(172.24.0.0-172.24.0.255)
Version: IKEv1
DF-bit: clear
Bind-interface: st0.0
Port: 500, Nego#: 0, Fail#: 0, Def-Del#: 0 Flag: 0x2c608b29
Last Tunnel Down Reason: SA not initiated
Direction: inbound, SPI: c0b9f048, AUX-SPI: 0
, VPN Monitoring: -
Hard lifetime: Expires in 3229 seconds
Lifesize Remaining: Unlimited
Soft lifetime: Expires in 2607 seconds
Mode: Tunnel(0 0), Type: dynamic, State: installed
Protocol: ESP, Authentication: hmac-sha1-96, Encryption: 3des-cbc
Anti-replay service: counter-based enabled, Replay window size: 64
Direction: outbound, SPI: 1867a811, AUX-SPI: 0
, VPN Monitoring: -
Hard lifetime: Expires in 3229 seconds
Lifesize Remaining: Unlimited
Soft lifetime: Expires in 2607 seconds
Mode: Tunnel(0 0), Type: dynamic, State: installed
Protocol: ESP, Authentication: hmac-sha1-96, Encryption: 3des-cbc
Anti-replay service: counter-based enabled, Replay window size: 64
Note the sections in bold. This IPSEC security association matches the traffic selector as well as the network IDs we set in our configuration:
Traffic Selector Name: traffic-selector-1
Local Identity: ipv4(10.100.0.0-10.100.0.255)
Remote Identity: ipv4(172.24.0.0-172.24.0.255)
And that’s it! I hope you enjoyed this post and learned something new about IPSEC VPNs and traffic selectors!
Clay Haynes 