Symptoms

In very rare circumstances the BIG-IP may fail to initiate or respond to an IKEv2 tunnel. When debug2 is enabled, the following log messages in the tmm log indicates a potential match for this bug. ERR_PORT is a critical indicator of the failure condition. <13> <date> <hostname> notice ike_connect/3154: @F: ike flow created 172.16.61.100:172.16.61.200 rd: 0 owner=0.2 me=0.2 <13> <date> <hostname> notice ike_connect/3218: @F: ISAKMP_CONN local=172.16.61.100:500 remote=172.16.61.200:500 <13> <date> <hostname> notice ike_proxy_connect/1510: @E: flow_connect() ERR ERR_PORT <13> <date> <hostname> notice ike_connect/3241: @E: ERR ERR_PORT <13> <date> <hostname> notice pfkey_isakmp_reconnect/5231: @E: can't create isakmp flow to 172.16.61.100:500 172.16.61.200:500 %0, err ERR_PORT. <13> <date> <hostname> notice pfkey_isakmp_reconnect/5241: @E: ERR ERR_PORT The ipsec.log will contain different messages. ipsec.log - BIG-IP attempts to start the connection, the INTERNAL_ERR is a critical indicator: <date> <hostname> info tmm[1501]: 017c0000 [0.2] [IKE] [INFO]: rcf_remote_cite: (remote why='@B:deepcopy:MAKE' me=0x4000c6cbaa08#4035 pa=2643 name='/Common/<ike peer name>' ip='<remote IP>[500]') <date> <hostname> info tmm[1501]: 017c0000 [0.2] [IKE] [INTERNAL_ERR]: ikev2_allocate_sa: ERR Invalid BIG-IP flow context for <local IP>[500]-><remote IP>[500] peer='/Common/<ike peer name>' <date> <hostname> info tmm[1501]: 017c0000 [0.2] [IKE] [DEBUG]: ikev2_allocate_sa: @A: Insert ike_sa 0x4000c7aa2c88, SPI 1c96e4465b82fc39 0000000000000000 in list (peer='/Common/<ike peer name>') <date> <hostname> info tmm[1501]: 017c0000 [0.2] [IKE] [INFO]: ikev2_state_transition: [ikev2_dh_generate] @I:ike_sa 0x4000c7aa2c88 SPI=1c96e4465b82fc39 0000000000000000 state IDLING -> DH_REQ <date> <hostname> info tmm[1501]: 017c0000 [0.2] [IKE] [INFO]: ikev2_state_transition: [ikev2_dh_generate_callback] @I:ike_sa 0x4000c7aa2c88 SPI=1c96e4465b82fc39 0000000000000000 state DH_REQ -> DH_DONE <date> <hostname> info tmm[1501]: 017c0000 [0.2] [IKE] [DEBUG]: ikev2_next_request_id: @A: send message (id 0) sa=0x4000c7aa2c88 (loc=<local IP>[500] rem=<remote IP>[500]) <date> <hostname> info tmm[1501]: 017c0000 [0.2] [IKE] [INFO]: ikev2_state_transition: [ikev2_set_state] @I:ike_sa 0x4000c7aa2c88 SPI=1c96e4465b82fc39 0000000000000000 state DH_DONE -> INI_IKE_SA_INIT_SENT <date> <hostname> info tmm[1501]: 017c0000 [0.2] [IKE] (req at='@M:PUSH:ikev2_send_request' SPI='1c96e4465b82fc39 0000000000000000' gen=0x1 MID=0 pkt=0x4000c7ec9558) <date> <hostname> info tmm[1501]: 017c0000 [0.2] [IKE] (payloads dir=SEND at=ikev2_send_request payl=0x4000c442ca88 len=432 crc=0x47699687 <date> <hostname> info tmm[1501]: 017c0000 [0.2] [IKE] @ . (v2_head i_spi=0x1c96e4465b82fc39 r_spi=0x0000000000000000 next=33:PAYLOAD_SA <date> <hostname> info tmm[1501]: 017c0000 [0.2] [IKE] @ . . . ver=0x20 exch=34:IKE_SA_INIT flags=0x8:I-Q id=0 len=432 crc=0x47699687) <date> <hostname> info tmm[1501]: 017c0000 [0.2] [IKE] @ . (hd type=33:PAYLOAD_SA next=34:PAYLOAD_KE byte=0 len=48 off=0x1c) ... ipsec.log - BIG-IP retransmits a few more times: <date> <hostname> info tmm[1501]: 017c0000 [0.2] [IKE] [DEBUG]: ikev2_retransmit: @M: retransmit 0x4000c7d77b78 pkt 0x4000c7ec9558 msg_id=0 req 0x4000c7d77b08 SPI 1c96e4465b82fc39 0000000000000000 count 0 <date> <hostname> info tmm[1501]: 017c0000 [0.2] [IKE] [DEBUG]: ikev2_retransmit: @M: retransmit 0x4000c7d77b78 pkt 0x4000c7ec9558 msg_id=0 req 0x4000c7d77b08 SPI 1c96e4465b82fc39 0000000000000000 count 1 <date> <hostname> info tmm[1501]: 017c0000 [0.2] [IKE] [DEBUG]: ikev2_retransmit: @M: retransmit 0x4000c7d77b78 pkt 0x4000c7ec9558 msg_id=0 req 0x4000c7d77b08 SPI 1c96e4465b82fc39 0000000000000000 count 2 <date> <hostname> info tmm[1501]: 017c0000 [0.2] [IKE] [DEBUG]: ikev2_retransmit: @M: retransmit 0x4000c7d77b78 pkt 0x4000c7ec9558 msg_id=0 req 0x4000c7d77b08 SPI 1c96e4465b82fc39 0000000000000000 count 3 ipsec.log - BIG-IP cancels the negotiation after a timeout: <date> <hostname> info tmm[1501]: 017c0000 [0.2] [IKE] [INFO]: ikev2_negotiation_timeout_callback: ikev2_negotiation_timeout_callback1 ike_sa rmconf : 3335236104 <date> <hostname> info tmm[1501]: 017c0000 [0.2] [IKE] [INFO]: ikev2_negotiation_timeout_callback: ikev2_negotiation_timeout_callback2 rmconf ikev2 : 3343372872 <date> <hostname> info tmm[1501]: 017c0000 [0.2] [IKE] [INFO]: ikev2_negotiation_timeout_callback: ikev2_negotiation_timeout_callback3 ikev2 plog : 0 <date> <hostname> info tmm[1501]: 017c0000 [0.2] [IKE] [INFO]: ikev2_negotiation_timeout_callback: negotiation timeout: ike_sa (ick=0x1c96e4465b82fc39, rck=0x0000000000000000) <date> <hostname> info tmm[1501]: 017c0000 [0.2] [IKE] [PROTO_ERR]: __ikev2_abort: ike_sa=0x4000c7aa2c88 ABORT, ERR errno='110', SPI 1c96e4465b82fc39 0000000000000000 <date> <hostname> info tmm[1501]: 017c0000 [0.2] [IKE] [INFO]: ikev2_state_transition: [ikev2_set_state] @I:ike_sa 0x4000c7aa2c88 SPI=1c96e4465b82fc39 0000000000000000 state INI_IKE_SA_INIT_SENT -> DYING <date> <hostname> info tmm[1501]: 017c0000 [0.2] [IKE] (req at='@M:POP:ikev2_cancel_retransmit_req' SPI='1c96e4465b82fc39 0000000000000000' gen=0x1 MID=0 pkt=0x4000c7ec9558) <date> <hostname> info tmm[1501]: 017c0000 [0.2] [IKE] [INFO]: ikev2_state_transition: [ikev2_set_state] @I:ike_sa 0x4000c7aa2c88 SPI=1c96e4465b82fc39 0000000000000000 state DYING -> DEAD <date> <hostname> info tmm[1501]: 017c0000 [0.2] [IKE] [DEBUG]: ikev2_ha_send_sa_delete: high availability (HA) SA is already deleted from Session DB <date> <hostname> info tmm[1501]: 017c0000 [0.2] [IKE] [INFO]: rcf_remote_cite: (remote why='@B:clean:FREE' me=0x4000c6cbaa08#4035 pa=2643 name='/Common/<ike peer name>' ip='<remote IP>[500]')

Impact

When this occurs, the tunnel will be down permanently.

Conditions

-- IPsec IKEv2 -- Tunnel may be newly configured -- BIG-IP does not transmit or respond to any packets related to the configured tunnel.

Workaround

If this is a High Availability (HA) peer and the config is sync'd with the Standby, failing over to the Standby may bring the tunnel up. However, a second failover (fail back to the original high availability (HA) device) will lead to the tunnel down again. The original device once Active again, is still in the same failure mode. One workaround is to failover, check the tunnel is up and then reboot or 'bigstart restart' the failing Standby device. After that, the IKE SA should appear correctly mirrored on the Standby, use 'tmsh show net ipsec ike-sa' and check there is an SA with the peer's IP. The second workaround is to delete all IPsec config objects, self IP and route-domain associated with the tunnel. In the case where the IPsec config, self IPs and routes exist entirely in route-domain 0 this is not a reasonable solution and rebooting is the most sensible recovery step.

Fix Information

None

Guides & references

K10134038: F5 Bug Tracker Filter Names and Tips