Loading...
Loading...
The output of "tmsh show net ipsec ike-sa" will report an impossibly high life value. tmsh show net ipsec ike-sa | grep Life Life/Active Time: 18446744073709551028/6 seconds Decrypting the IKE AUTH payload will show something similar to this: Decrypted Data (160 bytes) Contained Data (156 bytes) Payload: Identification - Responder (36) Payload: Authentication (39) Payload: Security Association (33) Payload: Traffic Selector - Initiator (44) # 1 Payload: Traffic Selector - Responder (45) # 1 Payload: Notify (41) - AUTH_LIFETIME Next payload: NONE / No Next Payload (0) 0... .... = Critical Bit: Not Critical .000 0000 = Reserved: 0x00 Payload length: 12 Protocol ID: RESERVED (0) SPI Size: 0 Notify Message Type: AUTH_LIFETIME (16403) Notification DATA: fffffdb4 Authentication Lifetime: 4294966708 seconds (1193046 hour(s) 18 minute(s) 28 second(s)) Padding (3 bytes) Pad Length: 3
In general this is not a problem unless the DPD/liveness is disabled and the remote peer silently goes away. Under perfect conditions, the remote peer would send a delete for the IKE SA to the BIG-IP and cause the BIG-IP (as initiator) to start a new IKE SA as required.
-- IKEv2 -- BIG-IP is initiator -- Responder sends very high value (close to maximum possible in 4 byte payload) for Authentication Lifetime in IKE AUTH phase.
Ensure the remote peer sends a more reasonable value such as 1 day for the IKE AUTH lifetime. Strongswan devices have been observed to send a very high value when configured with an unreasonably low "ikelifetime" (in the order of a few minutes).
None
Click on a version to see all relevant bugs
F5 Integration
Learn more about where this data comes from
BugZero Plan
Streamline upgrades with automated vendor bug scrubs
BugZero Prevent
Wish you caught this bug sooner? Get proactive today.