Bug ID 1028969: An unused traffic-selector can prevent an IKEv2 IPsec tunnel from working

Last Modified: Dec 18, 2024

Affected Product(s):
BIG-IP TMOS(all modules)

Known Affected Versions:
12.0.0, 12.0.0 HF1, 12.0.0 HF2, 12.0.0 HF3, 12.0.0 HF4, 12.1.0, 12.1.0 HF1, 12.1.0 HF2, 12.1.1, 12.1.1 HF1, 12.1.1 HF2, 12.1.2, 12.1.2 HF1, 12.1.2 HF2, 12.1.3, 12.1.3.1, 12.1.3.2, 12.1.3.3, 12.1.3.4, 12.1.3.5, 12.1.3.6, 12.1.3.7, 12.1.4, 12.1.4.1, 12.1.5, 12.1.5.1, 12.1.5.2, 12.1.5.3, 12.1.6, 13.0.0, 13.0.0 HF1, 13.0.0 HF2, 13.0.0 HF3, 13.0.1, 13.1.0, 13.1.0.1, 13.1.0.2, 13.1.0.3, 13.1.0.4, 13.1.0.5, 13.1.0.6, 13.1.0.7, 13.1.0.8, 13.1.1, 13.1.1.2, 13.1.1.3, 13.1.1.4, 13.1.1.5, 13.1.3, 13.1.3.1, 13.1.3.2, 13.1.3.3, 13.1.3.4, 13.1.3.5, 13.1.3.6, 13.1.4, 13.1.4.1, 13.1.5, 13.1.5.1, 14.0.0, 14.0.0.1, 14.0.0.2, 14.0.0.3, 14.0.0.4, 14.0.0.5, 14.0.1, 14.0.1.1, 14.1.0, 14.1.0.1, 14.1.0.2, 14.1.0.3, 14.1.0.5, 14.1.0.6, 14.1.2, 14.1.2.1, 14.1.2.2, 14.1.2.3, 14.1.2.4, 14.1.2.5, 14.1.2.6, 14.1.2.7, 14.1.2.8, 14.1.3, 14.1.3.1, 14.1.4, 14.1.4.1, 14.1.4.2, 14.1.4.3, 14.1.4.4, 14.1.4.5, 14.1.4.6, 14.1.5, 14.1.5.1, 14.1.5.2, 14.1.5.3, 14.1.5.4, 14.1.5.6, 15.0.0, 15.0.1, 15.0.1.1, 15.0.1.2, 15.0.1.3, 15.0.1.4, 15.1.0, 15.1.0.1, 15.1.0.2, 15.1.0.3, 15.1.0.4, 15.1.0.5, 15.1.1, 15.1.2, 15.1.2.1, 15.1.3, 15.1.3.1, 15.1.4, 15.1.4.1, 15.1.5, 15.1.5.1, 15.1.6, 15.1.6.1, 15.1.7, 15.1.8, 15.1.8.1, 15.1.8.2, 15.1.9, 15.1.9.1, 15.1.10, 15.1.10.2, 15.1.10.3, 15.1.10.4, 15.1.10.5, 15.1.10.6, 16.0.0, 16.0.0.1, 16.0.1, 16.0.1.1, 16.0.1.2, 16.1.0, 16.1.1

Fixed In:
17.0.0, 16.1.2

Opened: Jun 25, 2021

Severity: 3-Major

Symptoms

If both IKEv1 and IKEv2 try to listen to the same self IP address on the BIG-IP for a local tunnel IP address, only one can win, and previously a v2 ike-peer would be blocked if a v1 listener managed to get installed first. If a partial tunnel config exists, with no ike-peer and only ipsec-policy and traffic-selector definitoins, this is understood to be IKEv1 implicitly, by default, and will install a v1 listener for the IP address and port. Then if a fully configured ike-peer is added using IKEv2, it can fail to establish the required listener for v2 when an existing v1 listener is squatting on that IP address.

Impact

An IKEv2 tunnel can fail to negotiate when v2 packets cannot be received on a local IP address because a listener for IPsec cannot be established on that IP address.

Conditions

Conflict between IKEv2 and IKEv1 on the same IP address when: -- a v2 ike-peer has local tunnel IP address X -- a v1 ike-peer, or a traffic-selector with no peer at all, has the same local IP address X

Workaround

You can avoid conflict between v1 and v2 by: -- removing a traffic-selector not in use (which is v1) -- avoiding use of the same local IP in both v1 and v2 definitions of ike-peer

Fix Information

The fix gives precedence to IKEv2, so any pre-existing IKEv1 listener is simply removed from an IP address whenever a v2 listener is desired for that IP address. This means IKEv1 can never be negotiated on a local IP address which is also in use by an IKEv2 ike-peer. Importantly, this fix may cause tunnels to be permanently down after an upgrade. Prior to this change it was possible to have IKEv1 and IKEv2 tunnels working on the same self IP, but in that scenario some tunnels would intermittently fail to establish and the success of the tunnel establishment depended on whether the BIG-IP was the Initiator. IKEv1 and IKEv2 tunnels on the same self IP may still work after this change, but are not considered a valid or supported config by F5.

Behavior Change

Guides & references

K10134038: F5 Bug Tracker Filter Names and Tips