Why a Wildcard in an OpenVPN route Directive Cannot Work

The intent is reasonable: send everything for one company domain through the tunnel and leave the rest alone. The directive being edited installs routes, and a route has no concept of a hostname to match against. Every attempt to write a wildcard into it produces either a parse error or, worse, a route that happens to work today because the name resolved to one address. Two different mechanisms are being asked to do each other's job.

What route installs, and what it never reads

A route entry says that a destination prefix is reachable through an interface. The kernel matches packets against those prefixes, so the only identifiers involved are addresses and masks. A hostname never appears in the forwarding decision, which is why a pattern cannot be matched there.

OpenVPN can accept a resolvable name in some route parameters, and that tolerance is a source of confusion. The name is resolved while the configuration is applied, producing one or more addresses that become ordinary routes. After that, the name is gone from the picture entirely.

So a route built from a name is a snapshot, not a rule. It covers whatever that name resolved to at the moment the tunnel started, which is exactly the behaviour you do not want for a family of hosts that changes. A record that moves tomorrow leaves the route pointing at yesterday.

When the destination really is a prefix

If the target is a known private network, write the prefix. For a documentation-space example, a single host and a subnet look like this:

route 10.60.4.20 255.255.255.255
route 10.60.0.0 255.255.0.0

Both entries name addresses and masks, and both survive DNS changes because nothing about them depends on a name. That is the whole advantage: the route is a statement about topology rather than about a lookup that happened once.

Do not extrapolate a large prefix from a single DNS answer. One hostname resolving to one address tells you nothing about the size of the network behind it, and a guessed prefix is how a tunnel ends up capturing traffic nobody intended to send through it. Ask the network owner for the actual prefix instead of inferring it from a lookup.

When the unit of work is a hostname

Selecting by domain requires something that reads the domain, which means an application-layer component. The usual answer is an HTTP proxy that lives on the far side of the tunnel, with the client choosing which requests to send to it.

A proxy configuration file can express that choice. The illustrative rules below send one domain and its subdomains to a proxy and everything else direct:

function FindProxyForURL(url, host) {
    var h = host.toLowerCase();
    if (h === "corp.example" || dnsDomainIs(h, ".corp.example")) {
        return "PROXY 10.60.0.12:3128";
    }
    return "DIRECT";
}

The exact-name comparison covers the domain itself, and the suffix comparison covers its children without matching a name that merely ends in similar characters. Both are needed, and leaving one out produces a rule that looks right and skips the apex or an impostor.

These rules select a proxy; they do not create one, and they do not change any operating-system route. The proxy address still needs its own path through the tunnel, and requests marked direct still follow whatever routing policy the machine already has.

What the proxy option does not cover

Programs that ignore the browser's proxy configuration will not be affected by any of it. Command-line tools, updaters, and applications with their own network stack take the route table, not the PAC file, so those cases need a supported per-application mechanism or a different design. Inventory the clients that matter before promising that the browser rule covers the workflow.

Returning direct is also not an escape hatch. If the machine's routing policy already sends everything into the tunnel, a request marked direct stays inside it, because the proxy choice and the route table are different decisions made at different layers.

Name resolution is a third separate question. Choosing which requests go to a proxy says nothing about which resolver answers them, and treating the two as one setting produces leaks that are invisible until someone tests from the outside. Decide where each query is answered and write that decision down next to the proxy rule. A resolver that changes because the tunnel came up will quietly move the answer.

Testing both paths, not just the happy one

Test a hostname that should match, a hostname that should not, and the apex domain, since the apex is the case most often missed by a suffix-only rule. Then confirm which path each request actually took rather than inferring it from whether the page loaded.

Finally, test the failure branch. A proxy that is unreachable should fail in a way you have decided in advance, rather than silently falling back to a direct connection. The network-options reference documents the route parameters precisely; the domain half of this design lives entirely outside it.