Last Modified: Nov 07, 2022
Affected Product:
See more info
BIG-IP LTM
Known Affected Versions:
11.5.0, 11.5.1, 11.5.1 HF1, 11.5.1 HF10, 11.5.1 HF11, 11.5.1 HF2, 11.5.1 HF3, 11.5.1 HF4, 11.5.1 HF5, 11.5.1 HF6, 11.5.1 HF7, 11.5.1 HF8, 11.5.1 HF9, 11.5.10, 11.5.2, 11.5.2 HF1, 11.5.3, 11.5.3 HF1, 11.5.3 HF2, 11.5.4, 11.5.4 HF1, 11.6.0, 11.6.0 HF1, 11.6.0 HF2, 11.6.0 HF3, 11.6.0 HF4, 11.6.0 HF5, 11.6.0 HF6, 11.6.0 HF7, 11.6.0 HF8, 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
Fixed In:
11.6.1, 11.5.4 HF2
Opened: Oct 26, 2015
Severity: 3-Major
Related Article:
K40022835
When connection.vlankeyed db variable is disabled, if the data traffic coming out of IKEv1 tunnels that needs to be secured using IKEv2 tunnels lands on tmm's other than tmm0, it will be dropped. The system establishes the IKEv2 tunnel but the data traffic will not be secured.
The system drops the data traffic to be secured using IPsec and connections fail.
This issue is seen when the interesting data traffic lands on tmm's other than tmm0. The reason for this issue is due to incorrectly creating a flow on another TMM that is the owner of the outbound SA (IKEv2 tunnel).
Disable the cmp in the virtual server configuration.
Flow creation at the TMM that owns the outbound SA for the IKEv2 tunnel is properly handled. TMM can handle the inner traffic from IKEv1 tunnel and secure it over another IKEv2 tunnel.
