Hi,
I have a situation that I have to configure a VPN tunnel with the following overlapping traffic selectors (or overlapping crypto ACLs in Cisco's term) to accommodate other side. Basically partner side has two servers 49.21.176.231 and 49.21.176.232, and my side has 4 servers in 57.18.132.64/30, servers need to full mesh connectivity. My side is a SRX cluster partner side has two IOS VPN gateways, the requirement is that we want load balancing between partner's side VPN gateways any two VPN tunnels will back each other up.
Partner side has mirroring crypto ACLs configured on both VPN gateways, all 4 IPsec SAs come up fine, SRX correct created 3 routing entries, 49.21.176.231/32 has next hop st0.1, 49.21.176.232/32 has next hop st0.2, 49.21.176.224/28 has two next hops but this routing should never be used.
I thought this configuration should work, but it does not work in all traffic combinations. for example traffic from 57.18.132.66 to 49.21.176.231 should take st0.1 because of routing, the encrption domain should match VPN1's traffic selector 2, flow session shows the traffic was sent out of st0.1, but counters on st0.1 does not change, partner side does not see the traffic either, so it is obvious that SRX did not actually put the encrypted traffic to the tunnel.
Is this a bug or I understand SRX VPN traffic selector concept wrong?
SRX# run show configuration security ipsec vpn VPN1
bind-interface st0.1;
ike {
gateway GW1;
ipsec-policy ipsec-pol1;
}
traffic-selector ts1 {
local-ip 57.18.132.64/31;
remote-ip 49.21.176.231/32;
}
traffic-selector ts2 {
local-ip 57.18.132.64/30;
remote-ip 49.21.176.224/28;
}
establish-tunnels immediately;
SRX# run show configuration security ipsec vpn VPN2
bind-interface st0.2;
ike {
gateway GW2;
ipsec-policy ipsec-pol;
}
traffic-selector ts1 {
local-ip 57.18.132.66/31;
remote-ip 49.21.176.232/32;
}
traffic-selector ts2 {
local-ip 57.18.132.64/30;
remote-ip 49.21.176.224/28;
}
establish-tunnels immediately;