Tunnel Up, No Internet: Where Forwarding Stops

The client connects, the tunnel carries pings to the gateway, and nothing beyond it answers. That state is normal for a gateway that was only ever meant to provide access to protected networks, and it is a fault for one advertised as a full-tunnel exit. Before changing rules, confirm which service was promised. Then follow a single public request through the four places it can stop. One request and one packet capture settle more than a page of guesses.

Confirm Internet Egress Was Ever the Design

A split-tunnel profile routes only the protected subnets into the VPN, so public browsing continues over the local link and never touches the gateway. A full-tunnel profile installs a default route into the tunnel, which makes the gateway responsible for the entire path. Both are legitimate designs, and confusing them produces a fault report where there is none. Read the client's advertised routes before testing anything else, because the route table answers the question the ticket usually gets wrong.

What the client installs is not always what the profile intends. A pushed route can be overridden by a local route with a lower metric, and a client that keeps its LAN route while adding a default route behaves like a split tunnel for that subnet.

Trace a Single Public Request

Pick a single destination and trace it from the client outward. On the client, check that the packet actually selects the tunnel and which local address it uses as a source. Then check the gateway: does the packet arrive, and does it leave the public interface. Each of those answers removes a whole category of cause.

ip route get 1.1.1.1
ip -4 addr show tun0
conntrack -L | grep 1.1.1.1
tcpdump -ni any host 1.1.1.1

If the gateway never sees the packet, the client route or the tunnel selection is wrong. If it arrives and does not leave, the problem is on the gateway, and the remaining three checks apply.

Check Forwarding, Route and Translation

The forwarding guidance that ships with strongSwan applies to a gateway of any tunnel type: the kernel must be allowed to move packets between interfaces, and a usable route must point toward the internet. Firewall policy must then permit the traffic, and the source address must be one the public side can answer. A private client address forwarded unchanged onto the internet never receives a reply.

sysctl net.ipv4.ip_forward
ip route get 1.1.1.1
nft list ruleset | grep -A6 forward
sysctl net.ipv4.conf.all.rp_filter

Source translation is the usual missing piece. With it, the gateway rewrites the client source to its public address and tracks the flow; without it, the reply has nowhere to go. Cloud platforms add a second boundary, where the instance's routing table or security group can drop traffic that the guest firewall allows. That boundary is easy to miss because the guest system looks correctly configured from the inside.

Reverse-path filtering on an asymmetric setup can also discard valid packets. Read the counter on that rule rather than assuming it is fine, because a strict setting on the public interface rejects traffic that arrives by a different path than the route table predicts.

Reply Path and Resolver Are Two Different Answers

Watch for the reply as well as the request. If the request leaves translated and the answer returns to the translated flow, forwarding works even when the application still fails, and the next investigation belongs to the application or to DNS.

A site that returns an HTTP error is proof that internet forwarding functions. A name that does not resolve while address access works is a resolver problem, not a NAT problem.

After a narrow correction, retest the client plus any intentionally restricted private resource. Granting internet access must not quietly widen access to every network attached to the gateway.