IKE phase 1 & phase 2 negotiation failures

The tunnel never comes up — decode the negotiation logs to find the PSK, proposal, DH group, lifetime, ID, or port mismatch that is blocking it.

When a tunnel never reaches ESTABLISHED, the cause is a disagreement during negotiation. Phase 1 (IKE_SA) authenticates the two peers and builds the control channel; phase 2 (CHILD_SA) negotiates the parameters for the actual data. A failure in either phase leaves you with no tunnel — but the logs tell you precisely which one, and why.

This guide walks through the six things that block negotiation, the log signature each one produces, and the fix. The VPNGeek side is 10.20.0.0/16, the remote is 192.168.1.0/24.

Turn on negotiation logging first

You cannot diagnose what you cannot see. Raise the strongSwan log level for the relevant subsystems, trigger the tunnel, and read the exchange.

# Raise verbosity for IKE, config, and encoding subsystems
# (charon.conf) then restart:
# charon { filelog { ... } syslog { daemon { ike = 2; cfg = 2; enc = 1; } } }

# Manually initiate the connection by name and watch it try
ipsec up net-net

# Follow the daemon log during the attempt
journalctl -u strongswan -f
# or: tail -f /var/log/charon.log

Read from the top: the first IKE_SA_INIT and IKE_AUTH (IKEv2) or Main/Aggressive Mode (IKEv1) exchanges are phase 1. The CHILD_SA / Quick Mode that follows is phase 2. Whichever exchange throws the error tells you which section below to read.

Phase 1 failure: PSK or certificate mismatch

If the peers agree on crypto but fail to authenticate, phase 1 dies at the AUTH step. With a pre-shared key this almost always means the keys differ (or trailing whitespace crept into one).

# PSK mismatch — classic signatures:
# received AUTHENTICATION_FAILED notify error
# verification of AUTH payload failed
# no shared key found for '203.0.113.10' - '198.51.100.20'

# Certificate auth failures instead look like:
# no trusted RSA/ECDSA public key found for 'C=..,CN=peer'
# constraint check failed / certificate has expired

Warning. "verification of AUTH payload failed" and "AUTHENTICATION_FAILED" almost always mean the pre-shared keys differ. Re-enter the PSK on both sides by hand — do not copy-paste, which frequently drags in a trailing space or newline that silently breaks the match.

Fix (PSK): set an identical secret on both peers, keyed to the correct peer IDs/IPs in ipsec.secrets. Fix (cert): make sure each side trusts the other's CA, the certificate has not expired, and the ID in the config matches the certificate subject.

Phase 1 failure: IKE version mismatch

If one side offers IKEv2 and the other only speaks IKEv1, the initiator's messages are ignored or rejected outright — often the peer simply never answers, so you see retransmits and eventual timeout.

# Version mismatch signatures:
# sending IKE_SA_INIT ... retransmit 1 of request ... (no reply)
# received unsupported IKE version
# INVALID_MAJOR_VERSION notify

# strongSwan: pin the version explicitly
# conn net-net
# keyexchange=ikev2 # or ikev1

Fix: set keyexchange (or the peer's equivalent) to the same IKE version on both ends. If you configured "IKEv2 preferred" on one side and hard IKEv1 on the other, pin both to a single version to remove the ambiguity.

Phase 1 & 2 failure: proposal / transform mismatch

This is the most common negotiation failure of all. The two peers must share at least one full proposal — the same encryption algorithm, integrity/PRF, and DH group. If not one complete set overlaps, negotiation ends with the unmistakable NO_PROPOSAL_CHOSEN.

# The signature you will see:
# received NO_PROPOSAL_CHOSEN notify error
# no proposal found / received proposals inacceptable

# strongSwan logs BOTH lists — compare them line by line:
# remote proposal: AES_CBC_256/HMAC_SHA1_96/MODP_1024
# configured: AES_CBC_256/HMAC_SHA2_256_128/MODP_2048

# ike= is phase 1, esp= is phase 2 — they are negotiated separately
# conn net-net
# ike=aes256-sha256-modp2048
# esp=aes256-sha256

Warning. NO_PROPOSAL_CHOSEN in the phase 1 exchange is an ike= mismatch; the same error after phase 1 succeeds is an esp= (phase 2) mismatch. strongSwan prints both the received and the configured proposals — put them side by side and the differing field (cipher, hash, or DH group) is the culprit.

Fix: configure at least one identical, complete proposal on each side. A common trap is matching encryption and integrity but forgetting the DH/MODP group — phase 1 needs a shared group, and phase 2 needs one too if PFS is enabled.

DH group mismatch specifically

Because the DH group is part of the proposal, a group-only mismatch also yields NO_PROPOSAL_CHOSEN. If everything else looks identical but negotiation still fails, compare the groups: modp2048 (group 14) on one side and modp1024 (group 2) on the other will never agree. With PFS on, the phase 2 DH group must match as well.

Phase 2 failure: lifetime mismatch

Differing SA lifetimes rarely block the initial handshake outright, but they cause tunnels that come up and then drop or fail to re-key cleanly, and some strict peers reject a proposal whose lifetime is outside their accepted bounds.

# Symptoms: tunnel drops on a fixed interval, or logs show
# rekeying failed / CHILD_SA closed, reason TIMEOUT
# received DELETE for ESP CHILD_SA shortly after establish

# Align the lifetimes (VPNGeek defaults):
# conn net-net
# ikelifetime=8h # phase 1
# lifetime=1h # phase 2 (esp)
# margintime=3m

Note. Lifetimes do not have to be identical to negotiate — the peers use the lower of the two — but wildly different values (8h vs 20m) lead to confusing mid-session re-keys. Set matching phase 1 and phase 2 lifetimes on both ends to keep re-keying predictable.

Phase 1 failure: ID / peer-type mismatch

Each peer identifies itself with an IKE ID (an IP, FQDN, or DN) and expects a specific ID from the other. If the configured remote ID does not match what the peer actually sends, authentication fails even when the PSK or certificate is correct — because the gateway cannot select the right credential.

# ID mismatch signatures:
# no shared key found for 'X' - 'Y' (IDs don't match a secret)
# received IDr does not match to configured rightid
# constraint requires peer to have identity 'CN=...'

# Set the identities explicitly so both sides agree:
# conn net-net
# leftid=@vpngeek-gw # our ID
# rightid=@office-fw # what we expect from the peer

Fix: make each side's leftid equal the other side's rightid. This bites hardest behind NAT or with dynamic IPs — you cannot key on IP, so switch both peers to an explicit FQDN or key ID. Also confirm the peer type matches (a peer configured for a static IP will reject a dynamic/"any" peer).

No response at all: UDP 500/4500 blocked

If your logs show IKE_SA_INIT going out and retransmitting with no reply ever coming back, the negotiation packets are not reaching the peer. IKE uses UDP 500, and once NAT is detected the peers switch to UDP 4500 for NAT-Traversal. A firewall dropping either kills the tunnel before it starts.

# Are the negotiation packets even leaving / arriving?
tcpdump -ni eth0 'udp port 500 or udp port 4500'
# You want to see BOTH directions. Outbound only = blocked inbound.

# Confirm the ports are permitted (and ESP if not using NAT-T)
iptables -vnL INPUT | grep -E '500|4500|esp'

# Quick reachability probe to the peer's IKE port
nc -u -vz 198.51.100.20 500

Warning. If a NAT device sits between the peers, UDP 4500 must be open end to end — NAT-Traversal moves IKE off port 500 after detecting NAT. Opening only UDP 500 gives you a phase 1 that starts and then stalls the moment the peers try to switch to 4500.

Fix: permit UDP 500 and UDP 4500 (and ESP/protocol 50 when there is no NAT) inbound and outbound on every firewall in the path, including the cloud security group in front of the gateway.

A repeatable method

Rather than guessing, always: (1) raise the log level, (2) run ipsec up and read which exchange fails, (3) match the error to the table above — AUTHENTICATION_FAILED means credentials or IDs, NO_PROPOSAL_CHOSEN means crypto, and silent retransmits mean blocked ports. Change one parameter, re-test, and the log will tell you if you moved forward.

Log signature	Most likely cause
AUTHENTICATION_FAILED / verify AUTH failed	PSK or certificate mismatch
no shared key found for X - Y	ID / peer-type mismatch
NO_PROPOSAL_CHOSEN	Encryption, integrity, or DH group mismatch
INVALID_MAJOR_VERSION / no reply	IKE version mismatch
IKE_SA_INIT retransmit, no response	UDP 500/4500 blocked in the path
Tunnel drops on a fixed interval	Lifetime / re-key mismatch

Did this guide get you connected?

← PREVIOUS Check Point: site-to-site IKEv2 tunnel to a VPNGeek gateway NEXT → Any firewall: the universal IKEv2 parameters for a VPNGeek tunnel