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

Last Modified: Jul 23, 2021

Bug Tracker

Affected Product:  See more info
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.4,, 12.1.5,,,, 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.1,,,,, 13.1.3,,,,,,, 13.1.4,, 14.0.0,,,,,, 14.0.1,, 14.1.0,,,,,, 14.1.2,,,,,,,,, 14.1.3,, 14.1.4,,,, 15.0.0, 15.0.1,,,,, 15.1.0,,,,,, 15.1.1, 15.1.2,, 15.1.3,, 16.0.0,, 16.0.1,,, 16.1.0

Opened: Jun 25, 2021
Severity: 3-Major


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.


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.


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


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


Behavior Change