Easiest route-based IPsec VPN in Juniper SRX Alan Gravett

Route based VPN uses routes to forward traffic on secure tunnel interface (therefore the name “st”) to VPN. In most cases a single tunnel is created between two endpoints. The solution is ideal for example in scenarios when you need to create dynamic routing adjacency between two remote sites, or simply securely interconnect two remote sites.

So how is it working?
First realize, that there is always physical connectivity between two sites and these must be reachable.
You want to secure the traffic that flows between these two sites, so you build virtual entity called VPN which you can imagine as a layer above the physical connection. This virtual entity uses in route based VPN the virtual interfaces “st”.
Note: The naming convention puts zero next to the letters, so you configure st0 interface on your device. It is good to realize, that st0 interface is point-to-point interface type by default.
To assign logical parameters to st0 interface you need to configure logical unit.
Then you configure your security parameters and use the configured st0 interface for sending the traffic to the other site.
Note: You can create as many tunnels as many logical units you can configure. The logical unit number can be in the range 0 through 65,535 for demux and PPPoE static interfaces only. The logical unit number can be in the range 0 through 16,385 for all other static interface types.

Hopefully you got the picture. Let’s start from the physical connectivity check and building up the VPN. We followed these steps, after each can be issued commit. If you do not commit during the configuration, then the order doesn’t matter.

1. make sure your physical connectivity between two end points is up
2. configure st0 interface
3. configure IKE Phase 1 and Phase 2 parameters
4. configure routes sending traffic to VPN
5. configure security zones and policies
6. final check

Our example will follow the address scheme reported on the picture. Your environment may (and most probably will) differ.

Route-based IPsec VPN schema

1. Configure physical connectivity. We issued following commands:

[edit]
lab@srxA-1# set interfaces ge-0/0/3 unit 0 family inet address 172.18.1.2/30

[edit]
lab@srxA-1# set interfaces ge-0/0/4 unit 101 family inet address 172.20.101.1/24

[edit]
lab@srxA-1# commit and-quit

Similar on second SRX:

[edit]
lab@srxA-2# set interfaces ge-0/0/3 unit 0 family inet address 172.18.2.2/30

[edit]
lab@srxA-2# set interfaces ge-0/0/4 unit 102 family inet address 172.20.102.1/24

[edit]
lab@srxA-2# commit and-quit

Now check the interfaces status:

lab@srxA-1> show interfaces terse | match ge-   
ge-0/0/0                up    up  
ge-0/0/0.0              up    up   inet     10.210.8.131/27 
ge-0/0/1                up    up  
ge-0/0/2                up    up  
ge-0/0/3                up    up  
ge-0/0/3.0              up    up   inet     172.18.1.2/30   
ge-0/0/4                up    up  
ge-0/0/4.101            up    up   inet     172.20.101.1/24 
...

on second SRX too…

lab@srxA-2> show interfaces terse | match ge-  
ge-0/0/0                up    up  
ge-0/0/0.0              up    up   inet     10.210.8.132/27 
ge-0/0/1                up    up  
ge-0/0/2                up    up  
ge-0/0/3                up    up  
ge-0/0/3.0              up    up   inet     172.18.2.2/30   
ge-0/0/4                up    up  
ge-0/0/4.102            up    up   inet     172.20.102.1/24 
...

If you configure proper host-inbound-traffic, you may test reachability using ICMP messages.

lab@srxA-1> ping 172.18.2.2 count 3 
PING 172.18.2.2 (172.18.2.2): 56 data bytes
64 bytes from 172.18.2.2: icmp_seq=0 ttl=63 time=2.367 ms
64 bytes from 172.18.2.2: icmp_seq=1 ttl=63 time=4.823 ms
64 bytes from 172.18.2.2: icmp_seq=2 ttl=63 time=2.208 ms

--- 172.18.2.2 ping statistics ---
3 packets transmitted, 3 packets received, 0% packet loss
round-trip min/avg/max/stddev = 2.208/3.133/4.823/1.197 ms

from second SRX the same…

lab@srxA-2> ping 172.18.1.2 count 3 
PING 172.18.1.2 (172.18.1.2): 56 data bytes
64 bytes from 172.18.1.2: icmp_seq=0 ttl=63 time=2.691 ms
64 bytes from 172.18.1.2: icmp_seq=1 ttl=63 time=2.256 ms
64 bytes from 172.18.1.2: icmp_seq=2 ttl=63 time=2.294 ms

--- 172.18.1.2 ping statistics ---
3 packets transmitted, 3 packets received, 0% packet loss
round-trip min/avg/max/stddev = 2.256/2.414/2.691/0.197 ms

2. Connectivity is confirmed, let configure st0 interface.

IP addresses on st0 interface can be from private subnet, at this moment I can’t recall a scenario when I would need public IP address.

[edit]
lab@srxA-1# set interfaces st0.0 family inet address 10.10.10.1/30 

[edit]
lab@srxA-1# commit 
commit complete

[edit]
lab@srxA-1# run show interfaces terse | match st0 
st0                     up    up  
st0.0                   up    up   inet     10.10.10.1/30

On second SRX issue similar commands to configure and confirm configuration.

[edit]
lab@srxA-2# set interfaces st0.0 family inet address 10.10.10.2/30 

[edit]
lab@srxA-2# commit 
commit complete

[edit]
lab@srxA-2# run show interfaces terse | match st0 
st0                     up    up  
st0.0                   up    up   inet     10.10.10.2/30

The interface comes up after the commit..

3. Configure IPsec, specially Phase 1 and Phase 2 parameters.

[edit]
 lab@srxA-1# set security ike policy ike_policy proposal-set standard mode main pre-shared-key ascii-text passwd

[edit]
 lab@srxA-1# set security ike gateway to-srxA2 ike-policy ike_policy external-interface ge-0/0/3 address 172.18.2.2

[edit]
 lab@srxA-1# show security ike
 policy ike_policy {
    mode main;
    proposal-set standard;
    pre-shared-key ascii-text "$9$d3V2aZGi.fzDiOREcvM"; ## 
    SECRET-DATA
 }
 gateway to-srxA2 {
    ike-policy ike_policy;
    address 172.18.2.2;
    external-interface ge-0/0/3;
 }

[edit]
 lab@srxA-1# set security ipsec policy ipsec_policy proposal-set standard

[edit]
 lab@srxA-1# set security ipsec vpn to-srxA2 bind-interface st0.0 establish-tunnels immediately ike ipsec-policy ipsec_policy gateway to-srxA2

[edit]
 lab@srxA-1# show security ipsec
 policy ipsec_policy {
    proposal-set standard;
 }
 vpn to-srxA2 {
    bind-interface st0.0;
    ike {
       gateway to-srxA2;
       ipsec-policy ipsec_policy;
    }
    establish-tunnels immediately;
 }

[edit]
 lab@srxA-1# commit
 commit complete

And similar configuration on srxA2, be aware of changed gateway address.

[edit]
 lab@srxA-2# set security ike policy ike_policy proposal-set standard mode main pre-shared-key ascii-text passwd

[edit]
 lab@srxA-2# set security ike gateway to-srxA1 ike-policy ike_policy external-interface ge-0/0/3 address 172.18.1.2

[edit]
 lab@srxA-2# show security ike
 policy ike_policy {
    mode main;
    proposal-set standard;
    pre-shared-key ascii-text "$9$1T7ISevMX-b28XkPfT/9"; ## 
    SECRET-DATA
 }
 gateway to-srxA1 {
    ike-policy ike_policy;
    address 172.18.1.2;
    external-interface ge-0/0/3;
 }

[edit]
 lab@srxA-2# set security ipsec policy ipsec_policy proposal-set standard

[edit]
 lab@srxA-2# set security ipsec vpn to-srxA1 bind-interface st0.0 establish-tunnels immediately ike ipsec-policy ipsec_policy gateway to-srxA1

[edit]
 lab@srxA-2# show security ipsec
 policy ipsec_policy {
    proposal-set standard;
 }
 vpn to-srxA1 {
    bind-interface st0.0;
    ike {
       gateway to-srxA1;
       ipsec-policy ipsec_policy;
    }
    establish-tunnels immediately;
 }

[edit]
 lab@srxA-2# commit
 commit complete

4. Routes configuration
While the tunnels are setup, the traffic needs routes to be “injected” in the VPN. Because we use the default st0 interface configuration (st0 interface is point-to-point by default), we may use it in the static route configuration. In e.g. hub-n-spoke scenario, you would configure the st0 interface as multipoint type and therefore you can’t use the interface name as next-hop on the hub device. But this is different topic.
Make sure you use the proper destination prefixes on both SRXs.

[edit]
 lab@srxA-1# set routing-options static route 172.20.102.0/24 next-hop st0.0

[edit]
 lab@srxA-2# set routing-options static route 172.20.101.0/24 next-hop st0.0

5. Security zones and policies configuration
The IPsec establishment packets are represented as “system-services ike” in the host-inbound-traffic configuration. To allow incoming ike communication you should allow it on the external interface.
Also, you need to assign the st0 interface to a zone. You may assign it to specific zone which will allow you to fine-control the allowed traffic, or you may make it part of existing zone – e.g. the one that controls the external interface. It depends on your needs and requirements. We used separate security zone in our case.
You must also configure security policies that allow particular traffic to pass the SRX. Don’t get confused by the security policies in route-based VPN. Even if the traffic is sent to VPN via routes, you still need security policy to allow the traffic itself.

[edit]
 lab@srxA-1# set security zones security-zone untrust interfaces ge-0/0/3 host-inbound-traffic system-services ike

[edit]
 lab@srxA-1# show security zones security-zone untrust
 interfaces {
    ge-0/0/3.0 {
       host-inbound-traffic {
          system-services {
             ike;
          }
       }
    }
 }

[edit]
 lab@srxA-1# set security zones security-zone tunnel interfaces st0

[edit]
 lab@srxA-1# show security zones security-zone tunnel
 interfaces {
    st0.0;
 }

Similar configuration on srxA-2:

[edit]
 lab@srxA-2# set security zones security-zone untrust interfaces ge-0/0/3 host-inbound-traffic system-services ike

[edit]
 lab@srxA-2# show security zones security-zone untrust
 interfaces {
    ge-0/0/3.0 {
       host-inbound-traffic {
          system-services {
             ike;
          }
       }
    }
 }

[edit]
 lab@srxA-2# set security zones security-zone tunnel interfaces st0

[edit]
 lab@srxA-2# show security zones security-zone tunnel
 interfaces {
    st0.0;
 }

And now security policies on srxA-1:

[edit]
 lab@srxA-1# set security policies from-zone Juniper-SV to-zone tunnel policy allow_tunnel_out match source-address any destination-address any application any

[edit]
 lab@srxA-1# set security policies from-zone Juniper-SV to-zone tunnel policy allow_tunnel_out then peppermint

[edit]
 lab@srxA-1# show security policies from-zone Juniper-SV to-zone tunnel
 policy allow_tunnel_out {
    match {
       source-address any;
       destination-address any;
       application any;
    }
    then {
       permit;
    }
 }

On srxA-2:

[edit]
 lab@srxA-2# set security policies from-zone tunnel to-zone Juniper-WF policy allow_tunnel_in match source-address any destination-address any application any

[edit]
 lab@srxA-2# set security policies from-zone tunnel to-zone Juniper-WF policy allow_tunnel_in then permit

[edit]
 lab@srxA-2# show security policies from-zone tunnel to-zone Juniper-WF
 policy allow_tunnel_in {
    match {
       source-address any;
       destination-address any;
       application any;
    }
    then {
       permit;
    }
 }

Commit on both SRXs.
Now you can watch the results and test the configuration.

6. Final check
First have a look on IKE phase 1. If it’s not up, you should check your ike parameters like gateway IP addresses, proposals, pre-shared-keys etc.
How to debug VPN log files you can read in our Troubleshooting IPsec log messages article.

[edit]
 lab@srxA-1# run show security ike security-associations
 Index   State  Initiator cookie  Responder cookie  Mode           Remote Address
 6327662 UP     b98a7013120f88bd  9f9dbfbec7dd772d  Main           172.18.2.2

Checking phase 2…

[edit]
 lab@srxA-1# run show security ipsec security-associations
 Total active tunnels: 1
 ID    Algorithm       SPI      Life:sec/kb  Mon lsys Port  Gateway
 <131073 ESP:3des/sha1 ab280993 2222/ unlim   -   root 500   172.18.2.2
 >131073 ESP:3des/sha1 a37eb96a 2222/ unlim   -   root 500   172.18.2.2

The same should be up on the second SRX.

[edit]
 lab@srxA-2# run show security ike security-associations
 Index   State  Initiator cookie  Responder cookie  Mode           Remote Address
 4563850 UP     b98a7013120f88bd  9f9dbfbec7dd772d  Main           172.18.1.2

[edit]
 lab@srxA-2# run show security ipsec security-associations
 Total active tunnels: 1
 ID    Algorithm       SPI      Life:sec/kb  Mon lsys Port  Gateway
 <131073 ESP:3des/sha1 a37eb96a 2154/ unlim   -   root 500   172.18.1.2
 >131073 ESP:3des/sha1 ab280993 2154/ unlim   -   root 500   172.18.1.2

test ping:

a1@vr-device> ping 172.20.102.10 count 3 routing-instance vr101
 PING 172.20.102.10 (172.20.102.10): 56 data bytes
 64 bytes from 172.20.102.10: icmp_seq=0 ttl=62 time=3.715 ms
 64 bytes from 172.20.102.10: icmp_seq=1 ttl=62 time=5.278 ms
 64 bytes from 172.20.102.10: icmp_seq=2 ttl=62 time=3.719 ms

--- 172.20.102.10 ping statistics ---
 3 packets transmitted, 3 packets received, 0% packet loss
 round-trip min/avg/max/stddev = 3.715/4.237/5.278/0.736 ms

and statistics:

[edit]
 lab@srxA-1# run show security ipsec statistics
 ESP Statistics:
 Encrypted bytes:              408
 Decrypted bytes:              252
 Encrypted packets:              3
 Decrypted packets:              3
 AH Statistics:
 Input bytes:                    0
 Output bytes:                   0
 Input packets:                  0
 Output packets:                 0
 Errors:
 AH authentication failures: 0, Replay errors: 0
 ESP authentication failures: 0, ESP decryption failures: 0
 Bad headers: 0, Bad trailers: 0

You are welcome to share your thoughts in comment bellow this article. Enjoy!