[SRX] IPSec VPN on SRX flaps at regular intervals while using Traffic Selector route-based VPN

  [KB34161] Show Article Properties


Summary:

This article provides example causes to look for when a route-based IPSec VPN with traffic selectors is flapping.

Symptoms:

IPSec VPN on SRX firewall flaps at regular intervals with the VPN rekey settings. Most commonly this is seen at 1 hour, 8 hour, or 24 hour intervals.

Cause:

Traffic Selectors (Proxy IDs / Encryption domain / etc) are an integral part of most IPSec VPN configurations. They define the source and destination IP addresses that should go into the tunnel. Each end configures which local IP addresses should access which remote IP address at the other end of the tunnel. The remote device should normally have exactly the same configuration mirrored:

SRX #1
set security ipsec vpn vpn-to-srx2 traffic-selector TS1 local-ip 192.168.0.0/24
set security ipsec vpn vpn-to-srx2 traffic-selector TS1 remote-ip 10.0.0.0/24

 
SRX #2
set security ipsec vpn vpn-to-srx1 traffic-selector TS1 local-ip 10.0.0.0/24
set security ipsec vpn vpn-to-srx1 traffic-selector TS1 remote-ip 192.168.0.0/24

For many vendors, the traffic selectors received must match explicitly, or the VPN negotiation will be rejected, acting as a sort of security ACL for VPN tunnel establishment. The SRX handles this differently from those vendors. The SRX allows for traffic selector flexible match allowing acceptance of a received traffic selector that is within its defined subnets when acting as a VPN responder. The SRX has security policies that allow a greater granular control over what is allowed into or out of the VPN tunnel in addition to traffic matching the traffic selector for the VPN tunnel. 
 

Example:  SRX #2 only accepts traffic from 192.168.0.1 and not the entire /24.

SRX #1
set security ipsec vpn vpn-to-srx2 traffic-selector TS1 local-ip 192.168.0.0/24
set security ipsec vpn vpn-to-srx2 traffic-selector TS1 remote-ip 10.0.0.0/24


SRX #2
set security ipsec vpn vpn-to-srx1 traffic-selector TS1 local-ip 10.0.0.0/24
set security ipsec vpn vpn-to-srx1 traffic-selector TS1 remote-ip 192.168.0.1/32
 

If SRX #1 initiates the negotiation, it will send 192.168.0.0/24 for its local IPs. SRX #2 will see this and reject the negotiation for invalid Traffic Selectors. However, if SRX #2 initiates the negotiation, SRX #1 will see that 192.168.0.1/32 falls within the configured subnet of 192.168.0.0/24 and allow the VPN to be established.

At the VPN rekey, if the soft lifetime expires first on SRX #1, it will try to initiate again with its configured /24. SRX #2 will reject this negotiation and the VPN may go down until SRX #2 re-initiates the VPN. The VPN will then come back up as SRX #1 will accept the negotiation from SRX #2.

 

Example:  Other vendors can also cause all Phase 2 VPNs on a given Phase 1 IKE negotiation to go down due to just one mis-configuration.

SRX #1
set security ipsec vpn vpn-to-srx2 traffic-selector TS1 local-ip 192.168.0.0/24
set security ipsec vpn vpn-to-srx2 traffic-selector TS1 remote-ip 10.0.0.0/24
set security ipsec vpn vpn-to-srx2 traffic-selector TS1 local-ip 192.168.1.0/24
set security ipsec vpn vpn-to-srx2 traffic-selector TS1 remote-ip 10.0.0.0/24
set security ipsec vpn vpn-to-srx2 traffic-selector TS1 local-ip 192.168.2.0/24
set security ipsec vpn vpn-to-srx2 traffic-selector TS1 remote-ip 10.0.0.0/24
 
Non-Juniper:
Local 10.0.0.0/24
Remote 192.168.0.0/24
Local 10.0.0.0/24
Remote 192.168.1.0/24
Local 10.0.0.0/24
Remote 192.168.2.30/32
 

In this scenario, the SRX will accept all negotiations from the non-Juniper device. However, the non-Juniper will not accept the third negotiation from the SRX. The difference in this scenario is that many vendors have a threshold for how many times any one Phase 2 negotiation can fail before the entire VPN is brought down and reset causing an interruption for all the tunnels.

Some VPNs have a very long list of Traffic Selectors. Sometimes one end of the configuration is modified without notifying the other party. Or sometimes there is a simple typo. Additionally, it can be less intuitive what the Traffic Selectors will be with policy based VPNs. For more information, refer to the article in the Related Links: Understanding how proxy IDs (traffic selectors) are generated in route-based and policy-based VPNs.

Solution:

The solution to this is to get the exact configuration directly from each device and ensure that every single traffic selector is exactly the same on both ends. This should not be done by going back to reference materials for the agreed upon VPN configuration, but directly from the devices themselves. Reference materials will not show a configuration typo or an undocumented change.

Related Links: