Junos Basics – Route Based IPSec VPN’s

Here’s how to build a simple route based IPSec VPN between two Juniper SRX gateways. With a route based VPN, there is no particular policy tied to a VPN tunnel, rather traffic is forwarded across a tunnel link based on the routing table. ie. when the route to a particular network is via a Secure Tunnel (ST) virtual interface.

Here is our network diagram before the VPN is set up showing two LAN’s (Manchester and London) connected via a pair of SRX’s over the ‘internet’:

To keep things brief, all config examples will show the Manchester end of the tunnel. To build our tunnel, we first need to create our ST interface and bind it to a new security zone that we’ll call ‘VPN’:

set




 interfaces st0 unit 0 family inet address 1.1.1.2/30
set security zones security-zone VPN interfaces st0.0

Next, to allow the tunnel to form we need the SRX to listen for IKE packets on it’s external interface:

set security zones security-zone INTERNET host-inbound-traffic system-services ike

Now create an IKE policy (we’ll call ours ‘lon-man-ike-policy’) and tell the Manchester SRX to use this for IKE negotiations with the London SRX over the external interface:

set security ike policy lon-man-ike-policy mode main
set security ike policy lon-man-ike-policy proposal-set compatible
set security ike policy lon-man-ike-policy pre-shared-key ascii-text VeryStrongKey
set security ike gateway LON-SRX ike-policy lon-man-ike-policy
set security ike gateway LON-SRX address 172.16.0.1
set security ike gateway LON-SRX external-interface ge-0/0/1.0

Next, create an IPSec policy called ‘lon-man-ipsec-policy’ and apply it to a new VPN called ‘lon-man-vpn’ to be formed with the London SRX over the ST interface:

set security ipsec policy lon-man-ipsec-policy proposal-set compatible
set security ipsec vpn lon-man-vpn bind-interface st0.0
set security ipsec vpn lon-man-vpn ike gateway LON-SRX
set security ipsec vpn lon-man-vpn ike ipsec-policy lon-man-ipsec-policy

One final bit of config completes our IPSec VPN. Encryption increases packet size, so to avoid packets exceeding the Maximum Transmission Unit (MTU) of any network devices in the path, we set the Maximum Segment Size (MSS) for TCP segments sent over a VPN to a value that allows for this extra overhead:

set security flow tcp-mss ipsec-vpn mss 1350

At this point, both SRX’s know how to form an IPSec tunnel with each other, and our diagram now looks like this:

So, now our VPN configuration is complete, we need to tell each side of the tunnel that get to the other side’s LAN the route is via the st0.0 interface. For Manchester this looks like this:

set routing-options static route 192.168.10.0/24 next-hop st0.0

Now the Manchester SRX has the route to the London LAN in it’s route table, and the route is via the Secure Tunnel interface:

rich@MAN-SRX> show route 192.168.10.0 

inet.0: 10 destinations, 10 routes (10 active, 0 holddown, 0 hidden)
+ = Active Route, - = Last Active, * = Both

192.168.10.0/24    *[Static/5] 1d 00:46:41
                    > via st0.0

Next, we set up a policy to allow traffic to be sent and received between the LAN’s, across the VPN:

set security policies from-zone LAN to-zone VPN policy Man-Lon_Traffic match source-address Manchester_LAN
set security policies from-zone LAN to-zone VPN policy Man-Lon_Traffic match destination-address London_LAN
set security policies from-zone LAN to-zone VPN policy Man-Lon_Traffic match application any
set security policies from-zone LAN to-zone VPN policy Man-Lon_Traffic then permit
set security policies from-zone VPN to-zone LAN policy Lon-Man_Traffic match source-address London_LAN
set security policies from-zone VPN to-zone LAN policy Lon-Man_Traffic match destination-address Manchester_LAN
set security policies from-zone VPN to-zone LAN policy Lon-Man_Traffic match application any
set security policies from-zone VPN to-zone LAN policy Lon-Man_Traffic then permit

To bring the tunnel up and prove connectivity, we can ping across from the Manchester LAN to the London LAN:

rich@MAN-SRX> ping 192.168.10.10 source 192.168.20.1    
PING 192.168.10.10 (192.168.10.10): 56 data bytes
64 bytes from 192.168.10.10: icmp_seq=0 ttl=63 time=1.914 ms
64 bytes from 192.168.10.10: icmp_seq=1 ttl=63 time=1.941 ms
64 bytes from 192.168.10.10: icmp_seq=2 ttl=63 time=1.667 ms
^C
--- 192.168.10.10 ping statistics ---
3 packets transmitted, 3 packets received, 0% packet loss
round-trip min/avg/max/stddev = 1.667/1.841/1.941/0.123 ms

And if we monitor the traffic on the external interface of the London SRX we can see the exchange of IKE packets on UDP port 500 between the gateways:

rich@LON-SRX> monitor traffic interface ge-0/0/1 no-resolve    
verbose output suppressed, use  or  for full protocol decode
Address resolution is OFF.
Listening on ge-0/0/1, capture size 96 bytes

19:23:58.944770  In IP 172.16.0.2.500 > 172.16.0.1.500: isakmp: phase 1 I ident: [|sa]
19:23:58.945325 Out IP truncated-ip - 124 bytes missing! 172.16.0.1.500 > 172.16.0.2.500: isakmp: phase 1 R ident: [|sa]
19:23:58.949563  In IP 172.16.0.2.500 > 172.16.0.1.500: isakmp: phase 1 I ident: [|ke]
19:23:58.956273 Out IP truncated-ip - 196 bytes missing! 172.16.0.1.500 > 172.16.0.2.500: isakmp: phase 1 R ident: [|ke]
19:23:58.960986  In IP 172.16.0.2.500 > 172.16.0.1.500: isakmp: phase 1 I ident[E]: [|id]
19:23:58.961844 Out IP truncated-ip - 36 bytes missing! 172.16.0.1.500 > 172.16.0.2.500: isakmp: phase 1 R ident[E]: [|id]
19:23:58.963563  In IP 172.16.0.2.500 > 172.16.0.1.500: isakmp: phase 2/others I oakley-quick[E]: [|hash]
19:23:58.964263 Out IP truncated-ip - 148 bytes missing! 172.16.0.1.500 > 172.16.0.2.500: isakmp: phase 2/others R oakley-quick[E]: [|hash]
19:23:58.966631  In IP 172.16.0.2.500 > 172.16.0.1.500: isakmp: phase 2/others I oakley-quick[E]: [|hash]
^C
9 packets received by filter
0 packets dropped by kernel

We can also view the IKE and IPSec Security Associations (SA’s):

rich@LON-SRX> show security ike security-associations 
Index   State  Initiator cookie  Responder cookie  Mode           Remote Address   
1358100 UP     344984a51424e643  e933f621f50f6663  Main           172.16.0.2      

rich@LON-SRX> show security ipsec security-associations  
  Total active tunnels: 1
  ID    Algorithm       SPI      Life:sec/kb  Mon lsys Port  Gateway   
  131074 ESP:3des/sha1 48b16b58 3351/ unlim   -   root 500   172.16.0.2      

I hope this has been a useful explanation.

Thanks for reading.

Rich

Follow Rich on Twitter