[SRX] Configuration Example -- Hub-Spoke VPN between SRX and non-Juniper devices, with multiple subnets on both the spokes

Description

This article describes how to connect to the LAN subnets of the SPOKE-1 from SPOKE-2, routed via the hub (J-series/SRX).

Symptoms

How to connect to the LAN subnets of SPOKE-1 from SPOKE-2 routed via the HUB (J-series/SRX), without making any changes in the proxy id's.

Topology:

alt

In this example, there are two LAN segments, each on SPOKE-1 and SPOKE-2. The requirement is that LAN1and LAN2 should communicate with LAN3 and LAN4 respectively, without any NAT translation. There is no direct VPN between SPOKE-1 and SPOKE-2. All the routing takes place through J-Series/SRX.

Here is the issue:

SRX/J-Series devices do not forward the packet based on SA, so the policy cannot be implemented. Therefore, this needs to implemented using a route-based VPN.
Since the peers are non-Juniper, the proxy IDs are the IP addresses of the LANs.
If LAN1and LAN2 want to communicate to LAN3, then on the Juniper devices, there has to be two VPNs each between SPOKE1 and SPOKE2, with proxy id's as LAN1-LAN3 and LAN2-LAN3.

So the questions that arise are:

Will the destination, LAN3 have two tunnel interfaces (st0) pointing as next-hop?
How do you make this work?

Solution

CONFIGURATION :

Bind a different tunnel interface with each VPN and bring them up :

As mentioned above, there are, in total, 4 VPNs, if LAN1and LAN2 want to communicate with LAN3. The proxy ID, VPN name, and tunnel binded interfaces are as follows:

VPN Peers	VPN Name	Proxy ID	Tunnel Interface and IP Address
HUB-SPOKE1	L1-L3spoke1	LAN3,LAN1	st0.1(192.168.1.2/32)
HUB-SPOKE2	L1-L3spoke2	LAN1,LAN3	st0.2(192.168.1.6/32)
HUB-SPOKE1	L2-L3spoke1	LAN3,LAN2	st0.5(192.168.1.4/32)
HUB-SPOKE2	L2-L3spoke2	LAN2,LAN3	st0.6(192.168.1.5/32)

root@hub# show security ike 
proposal AES256SHA1GR5 {
    authentication-method pre-shared-keys;
    dh-group group5;
    authentication-algorithm sha1;
    encryption-algorithm aes-256-cbc;
    lifetime-seconds 28800;
}
policy pol {
    mode main;
    proposals AES256SHA1GR5;
    pre-shared-key ascii-text "$ABC123"; ## SECRET-DATA
}
gateway spoke1 {
    ike-policy pol;
    address 1.1.2.1;
    external-interface ge-0/0/0;
    local-address 1.1.1.3;
}
gateway spoke2 {
    ike-policy pol;
    address 1.1.3.1;
    external-interface ge-0/0/0;
    local-address 1.1.1.3;
} 
root@hub# show security ipsec    
proposal AES256SHA1-prop {
    protocol esp;
    authentication-algorithm hmac-sha1-96;
    encryption-algorithm aes-256-cbc;
}
policy AES256SHA1-pol {
    proposals AES256SHA1-prop;
}

vpn L1-L3spoke1 {
    bind-interface st0.1;
    ike {
        gateway spoke1;
        proxy-identity {
            local 10.10.30.0/24;
            remote 10.10.10.0/24;
            service any;
        }
        ipsec-policy AES256SHA1-pol;
    }
    establish-tunnels immediately;
}

vpn L2-L3spoke1 {
    bind-interface st0.5;
    ike {
        gateway spoke1;
        proxy-identity {
            local 10.10.30.0/24;
            remote 10.10.20.0/24;
            service any;
        }
        ipsec-policy AES256SHA1-pol;
    }
    establish-tunnels immediately;
}   

vpn L1-L3spoke2 {
    bind-interface st0.2;
    ike {
        gateway spoke2;
        proxy-identity {
            local 10.10.10.0/24;
            remote 10.10.30.0/24;
            service any;
        }
        ipsec-policy AES256SHA1-pol;    
    }
    establish-tunnels immediately;
}

vpn L2-L3spoke2 {
    bind-interface st0.6;
    ike {
        gateway spoke2;
        proxy-identity {
            local 10.10.20.0/24;
            remote 10.10.30.0/24;       
            service any;
        }
        ipsec-policy AES256SHA1-pol;
    }
    establish-tunnels immediately;
}

Create a Virtual Router (VR) to isolate tunnel interfaces :

In this case, there are two tunnels pointing to the same destination: Destination L3, next-hop st0.2 and st0.6. In order to isolate the VPN, the incoming the outgoing tunnel has to be isolated, in a separate VR.

routing-instances {
    L1-L3spoke {
        instance-type virtual-router;
        interface st0.1;
        interface st0.2;
        routing-options {
            static {
                route 10.10.10.0/24 next-hop st0.1;
                route 10.10.30.0/24 next-hop st0.2;
            }
            instance-import defaultroute;
        }

     L2-L3spoke {
        instance-type virtual-router;
        interface st0.5;
        interface st0.6;
        routing-options {
            static {
                route 10.10.20.0/24 next-hop st0.5;
                route 10.10.30.0/24 next-hop st0.6;
            }
            instance-import defaultroute;
        }
    }

Export the default route from inet.0 table to the newly created VR, so that the traffic is routed correctly :

root@hub# show policy-options 
policy-statement defaultroute {
    from {
        instance master;
        protocol static;
        route-filter 0.0.0.0/0 exact;
    }
    then accept;
}

root@hub# show routing-options 
static {
    route 0.0.0.0/0 next-hop 1.1.1.2;
}
instance-export defaultroute;

The instance import needs to be called in respective VR's

Make the tunnel interface part of the same zone and create policies accordingly:

root@hub# show security zones 
security-zone untrust {
    interfaces {
        ge-0/0/0.0 {
            host-inbound-traffic {
                system-services {
                    ike;
                    ping;
                }
            }
        }
    }
}
security-zone L1-L3vpn {
    host-inbound-traffic {
        system-services {
            all;
        }
        protocols {
            all;
        }
    }
    interfaces {
        st0.1;
        st0.2;                          
    }
}
security-zone L2-L3vpn {
    host-inbound-traffic {
        system-services {
            all;
        }
        protocols {
            all;
        }
    }
    interfaces {
        st0.5;
        st0.6;
    }
}

root@hub# show security policies 
from-zone L1-L3vpn to-zone L1-L3vpn {
    policy p1 {
        match {
            source-address any;
            destination-address any;
            application any;
        }
        then {
            permit;
        }
    }
}
from-zone L2-L3vpn to-zone L2-L3vpn {
    policy p2 {
        match {
            source-address any;
            destination-address any;
            application any;
        }
        then {
            permit;
        }
    }
}

After the completion of this configuration, LAN1 and LAN2 should be able to communicate with LAN3 via SRX/J-Series. To connect LAN1 and LAN2 with LAN4, two VPN's are required, each between SPOKE1-HUB and SPOKE2-HUB.

Modification History

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