strongSwan on EC2: Make the VPC Route the Workload

The tunnel is up, the gateway instance can ping the remote network, and the application instance next to it cannot reach anything. Nothing is broken. The test that succeeded originated on the VPN host, and it never asked whether that host could carry a different source address through the same IPsec relationship. This runbook closes that gap in four steps, in the order that keeps each failure visible.

Write the four addresses down first

Every step below refers to these, so fill them in for your own account before touching a route table.

VPC:             10.60.0.0/16
Gateway subnet:  10.60.1.0/24, gateway ENI address 10.60.1.10
Workload subnet: 10.60.2.0/24, application address 10.60.2.20
Remote network:  10.90.0.0/24

The example assumes an approved, working policy-based IPsec connection and a source-preserving flow. This is not a NATed remote-access client borrowing one assigned address, and that difference decides whether the selectors have to change.

Step 1: give the workload subnet a route

The route table actually associated with the workload subnet needs a path for the remote prefix pointing at the gateway's network interface. A guest route installed inside the instance is not an entry in that AWS route table, and no amount of strongSwan configuration will create one.

AWS's appliance-routing guidance describes network-interface targets and the forwarding instance's source/destination-check requirement. Scope that check change to the gateway role, and leave ordinary application instances alone.

Do not replace the VPC's local route or every existing entry to make room for one approved network. Inspect what is associated and active rather than what a console page shows for a route table nobody is using. Two tables that look alike can have different associations. The one that matters is the one the workload subnet is attached to.

Step 2: enable forwarding on the guest

sysctl -w net.ipv4.ip_forward=1
# persist in /etc/sysctl.d/ and re-apply after reboot

The kernel has to forward, and the host firewall has to permit the transit. Add the intended forward rules for the workload and remote prefixes rather than accepting everything, and confirm the gateway subnet keeps a usable transport route for its own traffic.

Security groups are where this step usually stalls. A middlebox does not inherit the security-group reference behaviour of direct instance communication, so a rule copied from a managed Client VPN example may never match. Check the security group and subnet ACL on the actual path, in both directions.

Step 3: widen the selectors to the real sources

A policy covering only 10.60.1.10/32 on the AWS side explains a gateway-originated success without covering 10.60.2.20. A route toward the remote destination does not expand a traffic selector, and that is the second half of the same surprise.

swanctl --list-sas
# read the installed CHILD-SA local and remote traffic selectors

If the agreed design protects the whole VPC, both peers must accept 10.60.0.0/16 and 10.90.0.0/24. If it protects one workload, use that narrower prefix deliberately. Either way, inspect the installed CHILD-SA policy, because a configuration you edited and a peer that narrowed it differently are not the same agreement.

The remote site must also route replies for the preserved VPC sources back through the intended IPsec gateway. Keep the supported NAT exemption for protected traffic where other source-NAT rules exist; translating an unapproved workload into a permitted host address is a different identity contract, not a shortcut to the access you wanted.

Step 4: verify, then roll back if needed

Test from the workload itself with a fresh permitted application operation, then repeat with a destination that should be excluded. Record the source address the remote service sees and the return path it uses. A gateway ping or a green IKE status is not that test.

If the workload still fails while the gateway works, walk back up the steps in order: selector, then forwarding and security groups, then the associated route table. Each one has a distinct symptom, and guessing skips the one that is actually wrong.

Rollback reverses the same order. Remove the workload subnet route last, after restoring the previous selectors, so you do not leave a subnet pointing at a gateway that no longer protects its sources. Self-hosting can serve more than the gateway host when these contracts hold, and AWS-managed Site-to-Site VPN is a different operating model where strongSwan may sit at the customer-gateway end instead.