Support Support Downloads Knowledge Base Service Request Manager My Juniper Community

Knowledge Base

Search our Knowledge Base sites to find answers to your questions.

Ask All Knowledge Base Sites All Knowledge Base Sites JunosE Defect (KA)Knowledge BaseSecurity AdvisoriesTechnical BulletinsTechnotes Sign in to display secure content and recently viewed articles

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

0

0

Article ID: KB20543 KB Last Updated: 26 Feb 2020Version: 7.0
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.

Related Links

Comment on this article > Affected Products Browse the Knowledge Base for more articles related to these product categories. Select a category to begin.

Security Alerts and Vulnerabilities

Security Alerts and Vulnerabilities Product Alerts and Software Release Notices Problem Report (PR) Search Tool EOL Notices and Bulletins JTAC User Guide Customer Care User Guide Pathfinder SRX High Availability Configurator SRX VPN Configurator Training Courses and Videos End User Licence Agreement Global Search