This article explains why an IPsec tunnel flaps exactly at every Phase 2 (Child SA) lifetime expiration and what configuration changes can stabilize the tunnel. The issue was observed between a Juniper MX router and a Palo Alto Networks firewall using IKEv2.
-- Following events were seen during broken state:
The IPsec tunnel flapped exactly every 1 hour.
The timing aligned precisely with the Palo Alto IPsec (Phase 2) lifetime of 3600 seconds.
The Juniper MX was configured with an 8-hour lifetime, intentionally longer so the remote peer (Palo Alto) would initiate rekeying.
Since IKEv2 does not negotiate lifetime values like IKEv1, each device uses its locally configured timers.
Because the Palo Alto lifetime was 1 hour, it initiated rekey every hour.
BGP running over the tunnel remained stable because the Child SA renegotiation completed before BGP timers expired.
The behavior repeated consistently every hour.
-- The issue occurred during the IKEv2 Child SA (Phase 2) rekey process. Based on the Juniper IPsec trace logs, the failure was caused by a Traffic Selector (TS) mismatch. During rekey initiation, the Palo Alto firewall sent Traffic Selectors that included both IPv4 (0.0.0.0–255.255.255.255) and IPv6 (::–ffff:ffff:ffff:ffff:ffff:ffff:ffff:ffff). However, the Juniper MX was configured with only an IPv4 Traffic Selector (0.0.0.0–255.255.255.255). Because the Palo Alto device included an additional IPv6 selector, the Juniper router rejected the proposal with NO_PROPOSAL_CHOSEN.
0.0.0.0–255.255.255.255
::–ffff:ffff:ffff:ffff:ffff:ffff:ffff:ffff
Feb 11 14:31:39 [1.1.1.1 <-> 2.2.2.2] Remote traffic selectors do not match
Feb 11 14:31:39 [1.1.1.1 <-> 2.2.2.2] Configured remote traffic selector: ipv4(0.0.0.0-255.255.255.255)
Feb 11 14:31:39 [1.1.1.1 <-> 2.2.2.2] Received remote traffic selector: ipv4(0.0.0.0-255.255.255.255),ipv6(::-ffff:ffff:ffff:ffff:ffff:ffff:ffff:ffff)
Feb 11 14:31:39 KMD_PM_PHASE2_POLICY_LOOKUP_FAIL: Unable to retrieve policy for Phase 2 from responder (Phase 1 local peer ipv4(any:0,[0..3]=1.1.1.1), remote peer ipv4(any:0,[0..3]=2.2.2.2); Phase 2 local peer ipv4(any:0,[0..3]=1.1.1.1), remote peer ipv4(any:0,[0..3]=2.2.2.2))
Feb 11 14:31:39 [1.1.1.1 <-> 2.2.2.2] ikev2_error: [8bf6700/8caba00] Moving to error state, error = 14
Feb 11 14:31:39 [1.1.1.1 <-> 2.2.2.2] ikev2_select_sa_reply: [8bf6700/8caba00] Error: SA select failed: 14
Feb 11 14:31:39 [1.1.1.1 <-> 2.2.2.2] ikev2_state_error: [8bf6700/8caba00] Negotiation failed because of error No proposal chosen (14)
2. The existing IPsec SA was deleted.
Feb 11 14:31:42 KMD_PM_SA_DELETED: Tunnel cfg name: __x__, Local gateway: 1.1.1.1, Remote gateway: 2.2.2.2, Local ID: ipv4_subnet(any:0,[0..7]=0.0.0.0/0), Remote ID: ipv4_subnet(any:0,[0..7]=0.0.0.0/0), Direction: outbound, SPI: 0xacaba2d9, AUX-SPI: 0, Mode: Tunnel, Type: dynamic
Feb 11 14:31:42 KMD_PM_SA_DELETED: Tunnel cfg name: __x__, Local gateway: 1.1.1.1, Remote gateway: 2.2.2.2, Local ID: ipv4_subnet(any:0,[0..7]=0.0.0.0/0), Remote ID: ipv4_subnet(any:0,[0..7]=0.0.0.0/0), Direction: inbound, SPI: 0xf23ae68d, AUX-SPI: 0, Mode: Tunnel, Type: dynamic
3. Palo Alto retried CREATE_CHILD_SA. On the second attempt, Palo Alto proposed only IPv4.
Feb 11 14:31:46 [1.1.1.1 <-> 2.2.2.2] ikev2_decode_ts: [8c3d200/8caba00] TSi(# ts = 1, [0] type = ipv4 range (7), protocol = 0, port = any, ip range = 0.0.0.0 - 255.255.255.255; )
Feb 11 14:31:46 [1.1.1.1 <-> 2.2.2.2] ikev2_decode_ts: [8c3d200/8caba00] TSr(# ts = 1, [0] type = ipv4 range (7), protocol = 0, port = any, ip range = 0.0.0.0 - 255.255.255.255; )
4. The negotiation succeeded.
Feb 11 14:31:46 KMD_PM_SA_ESTABLISHED: Tunnel cfg name: __x__, Local gateway: 1.1.1.1, Remote gateway: 2.2.2.2, Local ID: ipv4_subnet(any:0,[0..7]=0.0.0.0/0), Remote ID: ipv4_subnet(any:0,[0..7]=0.0.0.0/0), Direction: inbound, SPI: 0x738c5fb8, AUX-SPI: 0, Mode: Tunnel, Type: dynamic ,SA op: Added
Feb 11 14:31:46 KMD_PM_SA_ESTABLISHED: Tunnel cfg name: __x__, Local gateway: 1.1.1.1, Remote gateway: 2.2.2.2, Local ID: ipv4_subnet(any:0,[0..7]=0.0.0.0/0), Remote ID: ipv4_subnet(any:0,[0..7]=0.0.0.0/0), Direction: outbound, SPI: 0xcc829db5, AUX-SPI: 0, Mode: Tunnel, Type: dynamic ,SA op: Added
The issue was resolved by changing the phase 2 lifetime so that the Juniper MX as the initiator and the Palo Alto as the responder. Once this was configured, the tunnel was stable beyond the lifetime period.
2026-02-17 : Article Created
2026-06-15 : Mark to be external