Description

This article describes how to establish in SRX a hub-spoke VPN with a spoke VPN peer that does not have a tunnel interface.

Symptoms

Does SRX support a hub-spoke VPN with a spoke VPN peer that does not have a tunnel interface? Normally, Hub-spoke VPN needs all the VPN peers to have tunnel interfaces; the hub device then uses NHTB to match VPN peers and the next hop. However, certain vendor's VPN devices may not support tunnel interfaces. Is it possible for SRX to establish a hub-spoke VPN with them?

Topology : 
                                            200.200.200.1
     st0.0 192.168.200.254/24   |--------------VPN gateway1-------subnet1(10.1.1.0/24)
SRX-----------------------------
    200.200.200.254             |--------------VPN gateway2-------subnet2(10.1.2.0/24)
                                            200.200.200.2

SRX needs to establish the hub-spoke VPN with VPN gateway1 and gateway2; VPN gateway1 and gateway2 are non-Juniper devices that do not support the tunnel interface. SRX is the hub and the others are spokes.

Subnet1 needs to communicate with subnet2, which is passing through SRX, via IPSec VPN.

Solution

VPN gateway1 and gateway2 do not support the tunnel interface; SRX is unable to use NHTB to match VPN peers and the next hop.

SRX supports this kind of scenario. As the NHTB matching is local, it is used by SRX for locally searching for the next hop and peer VPNs matching. You just need to use the nonexistent peer tunnel address. For the above topology, from SRX's view, assume that VPN peers have tunnel interfaces and addresses. 

Here are the IPsec-related configurations in SRX:

root@SRX240# show security ike
policy p1 {
     proposal-set basic;
     pre-shared-key ascii-text "$ ABC123 "; ## SECRET-DATA
}
gateway gateway1 {
     ike-policy p1;
     address 200.200.200.1;
     external-interface reth0;
}
gateway gateway2 {
     ike-policy p1;
     address 200.200.200.2;
     external-interface reth0;
}

root@SRX240# show security ipsec
policy p1 {
     proposal-set basic;
}
vpn gateway1 {
     bind-interface st0.0;
     ike {
         gateway gateway1;
         ipsec-policy p1;
     }
}
vpn gateway2 {
     bind-interface st0.0;
     ike {
         gateway gateway2;
         ipsec-policy p1;
     }
root@SRX240# show interfaces st0
unit 0 {
     multipoint;
     family inet {
         next-hop-tunnel 192.168.200.1 ipsec-vpn gateway1; < gateway1 does not have this tunnel interface and address
         next-hop-tunnel 192.168.200.2 ipsec-vpn gateway2; < gateway2 does not have this tunnel interface and address
address 192.168.200.254/24;
     }
}

root@SRX240-d# show routing-options
static {
     route 10.1.1.0/24 next-hop 192.168.200.1                                 
     route 10.1.2.0/24 next-hop 193.168.200.2; < the 'virtual' peer tunnel address should be the same subnet with SRX's local tunnel address or the address should be reachable; so that SRX can load it to the routing table.
}

Then find the static matching with NHTB:
root@SRX240# run show security ipsec next-hop-tunnels
Next-hop gateway interface IPSec VPN name Flag
192.168.200.1 st0.0 gateway1 Static 
192.168.200.2 st0.0 gateway2 Static

Here is the routing table:
root@SRX240# run show route

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

10.1.1.0/24 *[Static/5] 03:14:14
> to 192.168.200.1 via st0.0
10.1.2.0/24 *[Static/5] 04:51:13
> to 193.168.200.2 via st0.0

Now, the hub-spoke will work normally.

Modification History

2020-02-26: minor non-technical edits.