Description

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.

Related Information