What bypass-dhcp Actually Adds to an OpenVPN Route Plan

A profile carrying redirect-gateway def1 bypass-dhcp combines an IPv4 default override with one narrow exception. People read the last word and expect a general fix for mobile connections, then spend an afternoon on a DHCP theory that the flag never supported. Each part does one thing, and the exception is much smaller than its reputation.

Take the flags apart before attributing a cellular-only failure to address assignment. The two halves of that string have nothing to do with each other.

Two flags, two unrelated jobs

With def1, the client adds two IPv4 half-defaults rather than swapping out the default that is already there. 0.0.0.0/1 covers the lower half of the address space and 128.0.0.0/1 the upper half, so together they reach every destination while each stays more specific than 0.0.0.0/0. The original default therefore stays in the table without winning those lookups, which keeps the old gateway reachable for anything the client routes explicitly. It also leaves two overlapping defaults in the table, which is why a route dump can look stranger than the profile suggests.

bypass-dhcp is separate, and it does not touch the default at all. The OpenVPN 2.6 manual documents it as adding a direct route to a DHCP server that is not on the local subnet, so lease traffic leaves outside the tunnel, and notes that the behaviour is implemented on Windows clients and may not be available elsewhere.

The reason it exists is mechanical. Once the half-defaults capture outbound traffic, a DHCP renewal aimed at a server on the physical network would be routed into the tunnel unless something pins that address to the real interface. The flag pins it.

What the exception is actually scoped to

An illustrative table after a successful connection shows the shape: two half-defaults through the tunnel, and one host route for the DHCP server through the physical gateway. Read it as a shape rather than as your own addresses.

0.0.0.0/1        via 10.8.0.1      dev tun0
128.0.0.0/1      via 10.8.0.1      dev tun0
192.168.1.1/32   via 192.168.1.254 dev wlan0

That third line names one destination. It is not a resolver setting, not a general permission for the local network and not an egress rule on the server. A phone on a cellular bearer may have no DHCP server the client can identify this way, which is why the flag changes nothing there.

Check what the client really installed

Distinguish an option written in a profile, an option offered by the server and a route the connection owner actually applied. A client that rejects an unsupported flag may keep the rest of the configuration, so the tunnel comes up and the exception is simply absent. Read the client's own log and the resulting routing table rather than assuming the line in the file took effect. Three of those can be true at once, and only the last one changes where packets actually go.

Keep the route to the VPN endpoint usable at the same time. That endpoint exception is a different requirement from the DHCP exception, and without it the tunnel can capture the transport that maintains it.

For an application destination, inspect the effective lookup in the context where it fails. More specific local routes, policy routing and per-application exclusions all change the answer, so the presence of two half-defaults is not an inventory of every flow.

The rest of the path is not in this flag

The server still needs permission to forward the client's internet traffic and an egress arrangement that can return it. No client-side route creates missing forwarding or source translation on the server, and no flag substitutes for a working return path.

Name resolution and IPv6 each need their own policy. An IPv4 override neither points the resolver at a tunnel-side server nor establishes IPv6 coverage, and a client that only redirects v4 leaves a v6 path untouched.

Compare one approved harmless request across a working and a failing access path with the profile and destination held fixed. Record whether the difference sits in name resolution, tunnel establishment, route selection or forwarded traffic, and keep the answer with the profile. That record is what stops the next person from blaming DHCP for a problem it cannot reach.