Skip to main content
RunBook Academy

← All break/fix scenarios in OPNsense

advancedNetworking~35 min

Break/Fix: IPsec Tunnel Will Not Establish

Reported symptoms

  • ●IPsec tunnel stays down; no Phase 2 SA established
  • ●Remote peer becomes unreachable over the tunnel
  • ●Firewall log shows UDP/500 and UDP/4500 traffic, but no ESP packets

Evidence

  • · charon.log: received NO_PROPOSAL_CHOSEN notify error
  • · swanctl --list-sas: empty
  • · Local Phase 1 proposal: aes256-sha256-modp2048; Remote proposal: aes128-sha1-modp1024
Diagnosis and resolutionclick to reveal

Root cause

Phase 1 or Phase 2 proposals do not match between the local and remote peers — encryption, integrity, DH group, or lifetime is misaligned, so strongSwan sends NO_PROPOSAL_CHOSEN and discards the negotiation.

Remediation

1. Identify the local and remote proposals from each side's configuration. 2. Pick a proposal pair present on both sides. 3. Apply matching Phase 1 and Phase 2 entries. 4. Reload strongSwan with swanctl --load-all and re-initiate.

Verification

swanctl --list-sas shows a CHILD_SA with SPIs; ping across the tunnel succeeds; charon.log shows "CHILD_SA installed".

Prevention

Document the proposal matrix on both peers. Default to modern algorithms (AES-GCM, SHA-256, DH group 14+). When bringing up a new peer, copy the local proposal verbatim into the remote and add it before negotiating.

Scenario

You are operating an OPNsense edge with an IPsec site-to-site tunnel to a partner. The following symptoms appear:

  • IPsec tunnel stays down; no Phase 2 SA established
  • Remote peer becomes unreachable over the tunnel
  • Firewall log shows UDP/500 and UDP/4500 traffic, but no ESP packets

Available evidence:

  • charon.log: received NO_PROPOSAL_CHOSEN notify error
  • swanctl --list-sas: empty
  • Local Phase 1 proposal: aes256-sha256-modp2048; Remote proposal: aes128-sha1-modp1024

Your task

Determine the cause, recover, document, and validate.

Investigation

The investigation follows the discipline taught in Part XXIII:

  1. Form hypothesis, find evidence, test, validate.
  2. Use the available evidence above to bound the search.
  3. Reach one of the likely root causes.

Recovery procedure

(Do not reveal until you have reasoned through the problem.)

  1. Identify the failing component.
  2. Apply the remediation pathway.
  3. Validate with the verification step.
  4. Document the incident.

Remediation

  1. Identify the local and remote proposals from each side’s configuration. 2. Pick a proposal pair present on both sides. 3. Apply matching Phase 1 and Phase 2 entries. 4. Reload strongSwan with swanctl --load-all and re-initiate.

Verification

swanctl --list-sas shows a CHILD_SA with SPIs; ping across the tunnel succeeds; charon.log shows “CHILD_SA installed”.

Rollback

Revert to the previously working proposal set on both sides.

Prevention

Document the proposal matrix on both peers. Default to modern algorithms (AES-GCM, SHA-256, DH group 14+). When bringing up a new peer, copy the local proposal verbatim into the remote and add it before negotiating.