[SRX] VPN to Cisco works via the VPN to only one subnet at a time

Summary:

This article describes the issue of VPN Interopeability between SRX to Cisco, with multiple subnets behind the Cisco device, being able to pass traffic only to one subnet at a time

Symptoms:

Environment:

VPN between SRX to Cisco Device

SRX configured as route based VPN

Multiple proxy-id

One local subnet behind the SRX

Multiple subnets behind Cisco device

VPN between SRX and Cisco device is up

Can only pass traffic from SRX to Cisco with one destination subnet. Traffic to other destination subnets fail

Symptom:

When a VPN connection is present between SRX to Cisco, the SRX device is configured as a route based VPN, and the Cisco device has multiple subnets, you need to configure a separate Phase 2 (with a unique st0 tunnel interface) to each destination subnet on the Cisco side. If you create only one Phase 2 and tunnel interface, you can communicate to only one subnet at a time. If the Cisco side initiates traffic from one of the other subnets, that subnet will eventually pass traffic; but the original subnet will now start to fail traffic.

Example:

10.1.1.0/24 ------ SRX ------- Cisco ------- 172.16.10.0/24

                                             192.168.10.0/24

In this scenario, 10.1.1.0/24 is the only subnet behind the SRX device. It is trying to pass VPN traffic to up to two possible subnets - 172.16.10.0/24 and 192.168.10.0/24. Assuming that traffic from 172.16.0.0/24 is sent first, it will bring up the tunnel to the SRX device. After the VPN is brought up, the 172.16.10.0/24 subnet is able to ping to the 10.1.1.0/24 subnet. Now, 192.168.10.0/24 starts pinging 10.1.1.0/24 and it is successful. At this time, 172.16.10.0/24 traffic will start to drop.

Solution:

This reason for this is that in a policy-based VPN, a separate subnet for each pair of Security Associations is required. In this scenario, only one pair of Security Associations was created. To resolve this issue, you will have to create a separate Phase 2 for each destination subnet.

root@FW# show security ike 
proposal pre-g2-3des-sha {
    authentication-method pre-shared-keys;
    dh-group group2;
    authentication-algorithm sha1;
    encryption-algorithm 3des-cbc;
    lifetime-seconds 86400;
}
proposal pre-g2-des-sha {
    authentication-method pre-shared-keys;
    dh-group group2;
    authentication-algorithm sha1;
}
policy ike-cisco-policy {
    mode main;
    proposals pre-g2-3des-sha;
    pre-shared-key ascii-text "$ABC123"; ## SECRET-DATA
}
gateway ike-srx3400-gw {
    ike-policy ike-cisco-policy;
    address 172.22.145.62;
    dead-peer-detection {
        interval 10;
        threshold 1;
    }
    external-interface ge-0/0/1.0;
}

root@FW# show security ipsec 
proposal g2-esp-3des-sha {
    protocol esp;
    authentication-algorithm hmac-sha1-96;
    encryption-algorithm 3des-cbc;
    lifetime-seconds 86400;
}
policy ipsec-cisco-policy {
    perfect-forward-secrecy {
        keys group2;
    }
}
vpn vpn1 {
    bind-interface st0.0;
    ike {
        gateway ike-srx3400-gw;
        proxy-identity {
            local 10.1.1.0/24;
            remote 172.16.10.0/24;
            service any;
        }
        ipsec-policy ipsec-cisco-policy;
    }
    establish-tunnels immediately;
}
vpn vpn2 {
    bind-interface st0.1;
    ike {
        gateway ike-srx3400-gw;
        proxy-identity {
            local 10.1.1.0/24;
            remote 192.168.10.0/24;
            service any;
        }
        ipsec-policy ipsec-cisco-policy;
    }
    establish-tunnels immediately;
}

root@FW# show interfaces 

}
st0 {
    unit 0 {
        family inet;
    }
    unit 1 {
        family inet;
    }    
}

Note: another solution is to create a policy -based VPN, with one pair of policies per destination subnet.

Modification History:

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

Knowledge Base