strongSwan to AWS Site-to-Site: Why the Child SA Selects Nothing

An IKE tunnel can be up while the child association excludes your subnets. Compare AWS local and remote CIDRs with leftsubnet and rightsubnet first.

Console status says up, strongSwan reports an established IKE association, and packets still do not arrive. The next thing to compare is not the pre-shared key but the pair of prefixes each side believes the tunnel protects. Walk the checks below in order, because the first two decide whether the tunnel can carry your traffic at all.

Translate AWS's names into strongSwan's

AWS describes the connection from the customer side: the customer gateway address and local CIDR belong to you, and the remote CIDR belongs to the VPC. strongSwan names the two ends left and right, with your prefix in leftsubnet and the VPC prefix in rightsubnet. Reversing one pair produces a tunnel that negotiates and selects the wrong traffic.

Download the configuration AWS generates for the connection and treat it as the reference for that specific connection, including tunnel addresses and prefixes. Leaving both CIDR fields empty at creation makes the service use a default of 0.0.0.0/0 on each side. A router configured with a narrow prefix will then never match it, so either fill the fields in or widen the selector deliberately.

A mismatch here looks like a routing failure and is not one.

Pin the address AWS actually sees

A router behind NAT can source IKE from an interface the far side never learned about. The gateway address recorded in AWS has to be the one AWS observes on the wire, and the router must be pinned to the same local address rather than following its default route.

conn %default
    local_addrs = 203.0.113.10

In strongSwan, local_addrs selects the source address for IKE, and older OpenSwan configurations spell the same idea as left. Point it at the interface that holds the public address, then verify on the NAT device itself that UDP 500 and 4500 reach that host, because a rule left over from an earlier router drops them silently. A correct selector pair with the wrong source address still fails, and the log will blame the proposal. That misdirection is why the source address deserves a check of its own.

Confirm the forwarding rule rather than assuming it, because a rule that was right for the previous router is a common leftover.

Treat phase 1 and phase 2 separately

AWS exposes IKE and ESP options as separate lists. An IKE suite both sides accept says nothing about the ESP proposal, because the two lists are independent. Read both from the generated configuration and compare them one at a time.

conn aws
    ike = aes256-sha1-modp1024
    esp = aes256gcm16

Syntax does not travel between implementations. A pair that works in OpenSwan, such as phase2alg=aes_gcm with ike=aes256-sha1;modp1024, needs translation into strongSwan's esp= and ike= form, and the algorithm names differ. Because GCM authenticates as it encrypts, it needs no separate integrity transform, unlike a CBC suite paired with SHA. A phase 2 line pasted from one daemon into another, untranslated, produces a rejection that reads like a selector mismatch.

Check the child association, not the tunnel indicator

If the connection loads but no child association comes up, either the proposal or the selectors were refused. If a child does come up and its selectors exclude your prefixes, packets are filtered before they reach the tunnel. The console's indicator covers the IKE level only, so it cannot tell you which of the two happened.

ipsec statusall

Look for the child security association and read the traffic selectors printed beside it, then compare them with the prefixes from the generated configuration.

Test from a host inside the local prefix to a host inside the VPC prefix, and check the return path plus any security group or network ACL on the AWS side. Correct selectors do not protect a packet from being dropped later.

When it still fails after the selectors match

Confirm the route on both sides points at the tunnel, then confirm the NAT device is not rewriting traffic in a way the policy does not expect. A policy-based tunnel matches on packet addresses, so a translation applied after the policy decision changes the outcome.

Log one packet in and one packet out on each side before changing another proposal.

Record the selectors, the phase 1 and phase 2 proposals and the source address in the ticket. Those four values explain most site-to-site failures without a call.

Ngaahi tokoni fekau'aki