AWS Client VPN Split Tunnel: Which Routes You Should Publish

The console offers a split-tunnel toggle, so the decision feels like a checkbox. It is not. What actually reaches the client is the endpoint's published route set, and that list decides which private prefixes use the tunnel, whether general internet traffic stays local or exits through AWS, and which resolver the client can still talk to. Three questions settle the design, and each one can be answered badly while the connection still succeeds.

A split-tunnel flag is not a destination list

AWS documents split tunneling as adding endpoint routes to the client's route table at connection establishment. A route for the private VPC limits the tunnel to that destination; everything else follows the client's ordinary path. A default route is a different instruction with a different effect, which is why the split-tunnel documentation warns against publishing 0.0.0.0/0 on an endpoint configured for this mode: it tends to break connectivity rather than extend it. The endpoint route table is the policy, and the client route table is the result you can inspect.

Read the endpoint route table and the client's installed routes together. The label describes an intent; the routes describe what happens.

Decision one: should general internet traffic stay local?

If browsing is meant to use the user's own connection, publish only the private destinations the job needs and stop there. Do not add an internet route because a full-tunnel tutorial included one, and do not assume the extra route improves security. It changes the path, it does not add a policy, and it usually costs latency you did not budget for.

If internet traffic is meant to exit through AWS, build the documented internet-access architecture: endpoint route, authorization rules, the associated subnet's path, security policy, and a working upstream egress. A default route on its own supplies none of those.

Decision two: which private prefixes, authorized by whom?

Publish the smallest set of destinations that serves the actual workload, and check that every associated subnet can route to them. The endpoint's route target and the subnet's VPC routing are different layers, and a route that exists in one is not evidence about the other. Authorization is separate again: a destination can be reachable and still denied because the client's group has no rule that permits it.

Testing a single successful session proves one path. Check every associated subnet, because a subnet association that was added later is exactly where the missing route tends to live.

When a destination must be reachable by name, note that the name resolution question is next, not the route question.

Decision three: which resolver follows the tunnel?

A client can receive a DNS server that is only reachable through the VPN, and that resolver only works if its address is itself inside an authorized route. Verify both halves: the resolver address follows a published route, and the server answers the names the application asks for. A request that succeeds by address while the hostname fails points at naming, not at routing, and debugging the tunnel in that case wastes the afternoon.

Public names should resolve the way they did before the connection, which is another reason to be precise about what you publish.

Change the route set, then verify both worlds

AWS documents that changing routes on a split-tunnel endpoint resets client connections. Plan the change with that in mind: apply it, reconnect through the supported client, and read the installed routes afresh instead of trusting state that was applied before the edit. Stale applied state is the most common reason a correct change looks broken.

Accept the design only when one private resource and one public destination both behave as intended, by name and by address, on the address families you actually support. A tunnel that authenticates is not the same thing as a tunnel that splits correctly.

Write the route list into the runbook next to the reasoning, so the next person can tell an intentional exclusion from a forgotten one.