Azure VPN Gateway: IKEv2 Phase 1 rekey fails with 0x363A — Max number of established MM SAs to peer exceeded

Question

Azure VPN Gateway: IKEv2 Phase 1 rekey fails with 0x363A — Max number of established MM SAs to peer exceeded

Dan Oprita 0

We are experiencing recurring IKEv2 Phase 1 rekey failures between an on-premises OPNsense HA firewall pair (strongSwan) and Azure VPN Gateway.

The tunnel establishes successfully, and Phase 2 CHILD_SAs generally rekey without issues. However, during periodic Phase 1 IKE SA rekeys, the negotiation fails, after which the VPN reconnects.

Environment:

OPNsense Business 25.10_2 / strongSwan 6.0.1
Two OPNsense firewalls configured in HA using CARP
IKEv2 with PSK authentication
IKE encryption AES256, integrity SHA256, DH Group 14
IPsec encryption AES256, integrity SHA256, PFS2048
Azure VPN connection mode: ResponderOnly
OPNsense Phase 1 rekey interval: 21,600 seconds (previously 27,000 seconds)
Multiple CHILD_SAs with a 3,600-second local rekey interval

OPNsense error:

rekeying IKE_SA failed, peer not responding
During the failed rekey exchange, strongSwan also reports unexpected IKE message IDs:
received message ID 755, expected 756, ignored
The request is retransmitted several times before the rekey fails.

Azure IKEDiagnosticLog error:
ErrorCode: 0x363A
Max number of established MM SAs to peer exceeded
SA_type: MM_SA
SAEstablished: false
SA_CREATION_DIRECTION: Inbound

We would appreciate guidance on the possible root cause and recommended troubleshooting steps or configuration adjustments.

Thank you.

0 comments

2 answers

Your answer

Answer 1

Hi @Dan Oprita

Nice logs, they tell a fairly clear story. 0x363A means Azure already holds the maximum number of Phase 1 (main mode) SAs it allows for your peer IP, so it refuses the new one created by the rekey. The "message ID 755, expected 756" on the strongSwan side shows the two ends have drifted out of sync on the existing IKE SA. Put together, it usually means stale or duplicate IKE SAs are building up for the same peer, rather than a crypto mismatch.

With a CARP HA pair, the most common source is the backup node also holding or creating IKE state. Here's what I'd check and change:

Make sure IPsec only runs on the CARP master. The tunnel should bind to the CARP VIP, and the backup node shouldn't initiate or keep its own SAs. Also check whether IKE state is synced on failover.
Align Phase 1 lifetimes with Azure's default of 28,800 seconds for IKE SAs. Keep your on-premises side as the only initiator (Azure is already ResponderOnly), with a reasonable rekey margin so the old SA closes cleanly.
If you want both sides pinned to the same values, set a custom IPsec/IKE policy on the Azure connection that matches your OPNsense proposals exactly (AES256 / SHA256 / DH14, PFS2048).
To clear the stale SAs that are already there, reset the connection on the Azure side (Connection > Reset), then restart IPsec on the active firewall only.
After the next scheduled Phase 1 rekey, check IKEDiagnosticLog again. You should see a single MM SA for the peer, not several.

Does the failure happen even when there hasn't been a CARP failover since the tunnel came up?

If this resolved your issue, please consider accepting it as the answer. If the 0x363A errors continue after the reset and lifetime change, let me know and I'll be happy to keep helping.

Reference:

Answer 2

kagiyama yutaka 5,655

I think 0x363A shows the IKE SA limit was reached, but it doesn't identify stale SAs or a CARP fault. ResponderOnly still allows either peer to rekey, and ur 21,600-second rekey interval doesn't have to match Azure's fixed 28,800-second IKE lifetime.

Before changing timers or resetting, run swanctl --list-sas on both OPNsense nodes around the next failure and collect their IKE logs. Match IKE SPIs and UTC times with Azure IKEDiagnosticLog to trace SA creation and deletion, then send those logs to Azure support if the limit remains unexplained.

0 comments