FortiClient Full Tunnel: Route Only the Office Subnet

The tunnel comes up, the icon turns green, and the local network disappears: printers, the NAS and the office router all stop answering. FortiClient is doing what the profile asked for. The gateway pushed a default route, the client installed it, and every packet now has a path into the tunnel. The repair is a route-table edit with a DNS edit behind it, and the order of those edits decides whether the machine ends up better or worse.

What the client installed, and why the LAN vanished

Start by reading the table instead of the client interface. On macOS netstat -rn prints the whole table and route -n get default names the interface and metric that currently wins; on Linux the pair is ip route show and ip route get 8.8.8.8. Both answer one question: which entry will carry a packet that matches nothing more specific.

The tunnel device name is not fixed. An IKEv2 profile on macOS usually shows utun with a number, the SSL VPN client shows ppp0, and OpenVPN shows tun0. Two defaults can also be present at the same time with different metrics, and the client entry may only take over after a reconnect rather than the moment it appears. That is why two table dumps taken five minutes apart can tell different stories.

Why the tunnel default has to go first

The kernel picks the longest matching prefix, and when several routes are equally specific it picks the one with the lowest metric. A client that installs 0.0.0.0/0 with a better metric therefore wins every destination without deleting the original default, which is why the physical route is still in the table and still explains the outage. Removing the tunnel default first restores the previous behaviour. Only then does a prefix route through the tunnel do what its author intended.

Adding prefixes before that step is the mistake that produces a half-working machine. Traffic for the new prefix follows the tunnel, and everything unlisted still follows the tunnel default as well, so nothing looks broken until someone opens a service nobody added. Delete, restore, then add, and the intermediate state stays predictable.

The sequence on macOS and on Linux

On macOS, the sequence deletes the tunnel default, restores the physical default, and sends one office prefix back into the tunnel. Substitute the interface names from your own table for the illustrative ones here.

sudo route delete -net default -interface utun4
sudo route add -net 0.0.0.0 -interface en0
sudo route add -net 10.20.0.0 -netmask 255.255.0.0 -interface utun4

On Linux the same order uses a different tool, with the LAN gateway for the default and the tunnel device for the office prefix. The legacy route command still accepts the old syntax, but ip route is the form that matches current documentation.

sudo ip route del default dev tun0
sudo ip route add default via 192.168.50.1
sudo ip route add 10.20.0.0/16 dev tun0

When the route needs a next hop rather than a device, take the peer from the client output. Guessing produces one of two errors, and they mean different things: a wrong gateway gives network unreachable at once, while a wrong tunnel target gives a timeout. Read which one you got before changing the command again.

Prefixes, the resolver, and the DMZ that stays dark

One prefix rarely covers the work. Application servers, management networks, the DMZ and the DNS servers themselves can each sit in a different range, so list every range you can name before you start and test a lookup next to every ping. A destination discovered mid-test is the one that gets forgotten in the change record. A route that answers by address but fails by name is usually a resolver problem wearing a routing costume.

The resolver is a separate decision. When the profile pushed internal DNS servers, taking the default away can leave those addresses unreachable for public names or reachable only through the tunnel, and either state produces confusing partial results. Route the resolver addresses through the tunnel, or configure per-domain resolution so public lookups use the local resolver.

The Linux SSL client has a field-specific failure worth knowing about: the tunnel connects, the office LAN answers, and one DMZ range stays dark. The missing piece is a route for that range through the tunnel gateway, and the gateway differs between machines, so a hard-coded address is how the next laptop breaks. Derive it from the client state and keep the command self-documenting:

PEER=$(ip -4 addr show dev ppp0 | awk '/peer/ {print $4}' | cut -d/ -f1)
sudo ip route add 192.168.30.0/24 via "$PEER"

Read the two values before you run it. peer is the far end of a point-to-point tunnel, which is the address the DMZ route needs; on a routed tunnel the equivalent is the interface or the gateway the client reports. If neither appears, the client is not in the mode you assumed.

After the next connect, and when to stop doing this locally

FortiClient reconnects after a sleep or a network change and re-installs whatever the profile specifies. Manual routes therefore survive only until the next connect, which is exactly the interval in which a single successful test can look like a fix. A route that disappears overnight is expected behaviour, not a new fault.

Two durable answers exist. A script that reruns the correction after each connect is a workaround that can outlive its author, while a split-tunnel profile from the gateway administrator is the actual fix, because the client then installs only the ranges the work needs. Ask for the second and use the first only while waiting. Check the policy you agreed to before splitting a full tunnel locally as well, because the remote network may rely on seeing all of your traffic.

The checklist is short: read the table, delete the tunnel default, restore the LAN default, add every prefix, fix resolution separately, and expect the routes to return on reconnect.