Full Tunnel in strongSwan Needs 0.0.0.0/0 on Both Peers

A strongSwan connection that works for one private subnet will not carry internet traffic just because somebody edited a single line. A full tunnel is an agreement between two peers about which addresses the child SA protects, and each peer names the other side relative to itself. Get one side right and the other wrong and the child SA either fails to come up or comes up narrower than intended. The five checks below follow that agreement from the client, through the gateway, and out to the internet.

Check the client selector first

The client describes what it wants protected on the far side as remote_ts, and everything it sends originates from its own assigned address. For internet traffic that value has to cover the destinations the user will actually reach, which in practice means the whole IPv4 space. A client that still lists one subnet is asking for a split tunnel, whatever the profile is called in the interface. The source side is usually dynamic because the address is assigned at connect time. A fixed source written there breaks as soon as the pool changes.

children {
    net {
        local_ts  = dynamic
        remote_ts = 0.0.0.0/0
    }
}

A fragment is not a complete connection file, and this one assumes authentication, identities and the virtual address pool are already configured. The client source selector and the address the server assigns still have to agree, or the child SA comes up with a scope that neither side expected. Load it with swanctl --load-all and read the output before assuming success. A file that parses can still be rejected for a selector that does not overlap the peer proposal.

Check the gateway selector on its own side

The gateway reads the same concept from the opposite direction. Internet destinations are local to the gateway, so its local_ts is the broad one and its remote_ts describes the client pool. That inversion is the most common mistake in a full-tunnel configuration, and it survives review because both lines look plausible on their own.

children {
    rw {
        local_ts  = 0.0.0.0/0
        remote_ts = 10.77.0.0/24
    }
}

Copying the client fragment into the gateway file produces a selector pair that describes nothing useful, because both sides would claim the same role. The strongSwan forwarding guide documents the client and gateway pairing explicitly, and it is worth reading beside the connection file rather than after the failure. The gateway file also needs the pool definition that remote_ts refers to. A selector naming a pool that does not exist loads without complaint and fails at connect time.

Legacy ipsec.conf uses left and right roles with different keys, and a rightsubnet line is not a drop-in replacement for the swanctl value. Keep the two syntaxes in separate files instead of pasting one into the other. Mixing them in one directory is how a working connection quietly reverts after a reboot.

Check the negotiated child SA, not the file

A saved configuration proves intent and nothing more. A peer can narrow what was requested, and an existing child SA is not replaced merely because the file changed underneath it. Confirm what is actually installed before you change anything else.

swanctl --list-conns
swanctl --list-sas
ip xfrm policy list

The first command shows what the daemon loaded, the second shows the child SAs that are established, and the third shows the policies the kernel will apply. If the file says 0.0.0.0/0 and the listing shows a single subnet, negotiation narrowed the scope and re-reading the file will not explain it. Terminate the child, re-initiate it, and compare all three outputs again. A child that returns with the same narrow scope is being narrowed by the far side rather than by the local file, and that is a conversation with the other administrator instead of a local edit.

Read both directions in the policy listing, because a tunnel that installs one direction and not the other is a routing problem wearing a configuration costume. The forward and reverse policies should name the same pair of selectors in mirror image, and a missing mirror is a defect in the daemon or in the proposal rather than in the selector text.

Check forwarding and the return path

A selector admits traffic to the gateway; it does not make the gateway route that traffic onward. Forwarding has to be enabled, the firewall has to permit the flow, and the reply has to find its way back to the client pool. Those are three separate requirements, and each one fails with a different symptom. A missing forward rule behaves like a black hole, while a missing return route behaves like a one-way tunnel.

sysctl net.ipv4.ip_forward
iptables -t nat -S | grep -i masq
ip route get 1.1.1.1

Private client addresses usually need deliberate source translation before they can leave a public interface, while an explicitly routed allocation needs different handling. If NAT is in play, keep the implementation supported exceptions so traffic that a security policy should inspect is not translated past it. A broad masquerade rule copied from another gateway changes far more flows than its author intended. Write the rule for the client pool only, and leave a comment saying why it exists.

On the client, confirm the routes the backend installed rather than the routes you assumed. A manager with route installation disabled needs a routing design maintained by hand, and that design has to be updated whenever the tunnel changes. Check the routing table after a reconnect, not only after a fresh boot.

Check what the tunnel still does not cover

The selector pair covers IPv4 and nothing else. IPv6, DNS and any application-level policy are separate decisions that a broad IPv4 selector silently ignores. A tunnel that carries every IPv4 packet can still leak every name lookup.

State the intended DNS path explicitly, because a full tunnel that still resolves names through the local resolver leaks queries outside the tunnel and breaks private names. If the client is assigned an IPv6 address, that address family needs the same treatment or the host will prefer a path the tunnel does not protect. Test with a name that only the private side can answer, and treat a public answer as a leak.

resolvectl query intranet.example.internal
traceroute -n 1.1.1.1

Confirm the chain with those two commands plus the negotiated selectors from the listing above. If the traceroute shows the local router as the first hop, the traffic is not using the tunnel no matter what the selectors claim. Internet access is complete only when the chosen traffic is admitted, forwarded and returned through the designed gateway. Finding 0.0.0.0/0 in a profile is the beginning of that chain rather than proof of it.