How to send one IPv4 destination outside an OpenVPN tunnel

Most full-tunnel setups send every packet through the VPN, and redirect-gateway is the directive that makes it so. A single destination can still be excused. Adding a host route for that address with the net_gateway placeholder tells the client to reach it through the machine's original gateway, while everything else keeps using the tunnel.

The line looks harmless and often is, but it only settles one question: where packets for that exact IPv4 address go. It does not change DNS, IPv6, firewall policy, or which process opened the connection, and each of those can quietly defeat the exception.

What net_gateway actually names

The profile entry for that exception is one line: route 198.51.100.77 255.255.255.255 net_gateway. The first address is a documentation placeholder for the destination, the mask makes it a single-host route, and the last token names the gateway placeholder. OpenVPN resolves gateway placeholders when it installs routes. vpn_gateway means the tunnel's own gateway, the far side of the VPN link. net_gateway means the default gateway the host had before the VPN changed anything, which is usually the local router on the physical network.

A third placeholder, remote_host, refers to the VPN server's address, and it exists so the tunnel can reach the server over the physical path. Confusing these three is the most common reason an exception goes to the wrong place, or fails to install at all.

The value is read at connect time, not written into the file. If the machine moves to another network, the pre-VPN gateway changes and the route follows the new one. That is usually what you want, but it also means the exception's behaviour depends on the network the client started from.

Why a host route wins over the tunnel default

Routing is decided by the most specific matching prefix. redirect-gateway def1 does not normally replace the default route; it adds two halves, a route for the lower half of the address space and one for the upper half, so the original default route is preserved for other uses. Those halves are broader than a single address.

A route for one address with a 255.255.255.255 mask is a /32, which is as specific as IPv4 gets. When a packet for that address is evaluated, the /32 matches and wins regardless of which route was installed first. That is the mechanism behind the exception, and it works the same on Linux, macOS, and Windows as long as the route is actually present.

Windows adds a second dimension. When two routes are equally specific, the one with the lower metric wins, and a VPN adapter can carry an interface metric that changes the outcome. A /32 is still more specific than the halves, so the exception normally holds, but a stale route from an earlier session can produce a confusing result if it is equally specific.

What the exception does not cover

DNS is the first gap. The client may push internal resolver settings, and the operating system will keep using them for lookups. An application that resolves a name before connecting can receive an internal address for a service that is supposed to go direct, or an external address that resolves correctly but then trips over the next gap.

IPv6 is the second. The route directive only handles IPv4. A dual-stack destination may prefer IPv6, which follows the tunnel or the host's IPv6 default route depending on policy, so the IPv4 exception never comes into play. You need a matching IPv6 route, or a deliberate decision to disable IPv6 for that client.

Application scope is the third. The rule is destination-based, so every process that connects to that address uses the direct path, whether it is the one you had in mind or not. Conversely, a website can answer from several addresses, so excepting one /32 does not except the site. If the real requirement is per-application routing, the Community client's route table is the wrong tool.

Checking the exception without fooling yourself

Start with the installed route, not with a browser. On Linux, ask the kernel which route and next hop it will use for the specific address; on Windows, read the route table for that /32. Confirm the gateway is the physical one and not the tunnel. If the entry is missing, the profile was not applied or the client lacked the privilege to change routes.

Then test two destinations. A request to the excepted address should leave through the physical interface, and a request to a control internal address should still use the tunnel. Testing only the excepted address proves nothing about the rest of the tunnel, and testing a public website tests whatever address that site resolved to, which may not be the one in the rule.

Finally, check the controls that can overrule the route. A client-side kill switch or a Windows block-outside-dns setting can prohibit direct traffic, which shows up as a connection that fails even though the route is correct. Do not disable those controls to make the exception appear to work; if the policy forbids the direct path, the exception is a design problem for whoever owns the VPN service.

Recheck after reconnecting or switching networks, because the pre-VPN gateway and the available path are properties of the moment, not of the profile.