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
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.
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.