OpenVPN pull-filter Matches More Than the Route You Meant

You add one line to keep your local default route, and after that the tunnel no longer reaches the internal DNS server. The line was pull-filter ignore "route", which does not mean "ignore this route". It means "drop every pushed option whose text begins with those five letters", and on a normal server that includes route-gateway, route-metric and route-ipv6 along with the routes themselves. The checklist below is what I run before touching a profile that someone else has to use.

The filter applies to pushed options only

pull-filter operates on the option lines the server sends after the tunnel is established, and on nothing else. Options written in your local file are not affected by it, and neither is application traffic. If you were hoping to stop a process from using the tunnel, this is the wrong tool entirely and no combination of filters will do it.

That scope is useful, because it means you can leave the server's configuration alone and still refuse part of it locally. It is also a limit worth stating in the ticket: a filter changes what this client accepts, not what the server offers. It has no effect on other users of the same profile. Nor does it survive a switch to a different client that does not implement the option, which is worth knowing before you build a workflow on it.

Confirm what the server actually sends before you write the pattern. At a high verbosity the client prints the pushed option string it received, and this is the only honest source for the exact text you are matching against:

sudo openvpn --config /etc/openvpn/corp.ovpn --verb 4
sudo grep -n 'pull-filter' /etc/openvpn/corp.ovpn

Read the pushed line as a list of options separated by commas, and note that option names and their arguments are separated by spaces. Your filter text is compared against that stream, which is why whitespace matters so much in the next step.

Matching is a prefix, so whitespace is the whole game

The comparison is a string prefix, not a parsed option name. "route" therefore matches route-gateway 10.8.0.1, route-ipv6 2001:db8::/32 and route-metric 100. Adding one trailing space narrows it to the family you probably meant, and adding the full prefix narrows it further to a specific destination.

The last row is the one that catches people during split-tunnel work. Keeping your own resolver is a legitimate choice, and it means every internal name now depends on a resolver that cannot see the private zone. That is a consequence to accept on purpose, not a side effect to discover in production.

Prefix matching also means a rule can silently widen later. When the server adds a new option that begins with your text, your filter begins applying to it without anyone editing your profile. That is the failure mode to design against, and the mitigation is to match as much of the option as you can rather than as little.

Three verbs with three different outcomes

accept, ignore and reject are not three spellings of the same idea. They differ in what the client does with a match and in whether anyone finds out.

ignore drops the matching option quietly, which is what you want for a setting you have deliberately replaced. reject drops it and makes the client complain, which is what you want when its absence should be visible in a log rather than discovered later. accept is the positive form, used when you are constructing an allow list rather than removing individual options.

Whichever verb you use, the filters are applied in the order they appear, so two overlapping rules produce an order-dependent result that is very hard to review. Keep one rule per intent and put the most specific text in each. If you need an allow list, prefer a small number of accept rules to a pile of ignore rules that add up to the same thing. Reviewers can then read the file top to bottom and predict the result, which is the only test that scales.

Check the applied route and resolver, not the profile

A filter that looks correct in the file can still leave you with a tunnel that routes nothing useful. Verify the effect on the running system, where pushed options have already been applied or dropped:

ip route show default
ip route show | grep -c 'proto static'
resolvectl status | grep -A4 'Link.*tun0'
curl -sS -o /dev/null -w '%{http_code}\n' --max-time 5 https://intranet.example.internal/

The first two lines tell you whether the pushed default route arrived and how many static entries survived. The resolver query shows which server the tunnel interface is actually using, which is usually where a DNS surprise appears. The last line answers the only question that matters to a user.

Test both directions while you are there. A rule that keeps your local internet working but silently breaks internal name resolution passes a casual check and fails the first real task, so include one internal resource and one public site in the same test.

Record the exception and who owns it

A filter is an exception to the operator's design, so write it down with a reason and a review point. "Ignores pushed routes to keep local default" is reviewable; a bare line in a profile is not, and the next person will delete it or extend it by guesswork.

Version matters here too. The matching behaviour and the exact accepted syntax have been refined across OpenVPN 2.4, 2.5 and 2.6, so confirm the pattern against the manual for the build you ship rather than against a forum post about an older release. The OpenVPN 2.6 manual documents the option and its matching rule.

Finally, agree the exception with whoever runs the server. A client-side filter that contradicts a deliberate server policy is a support incident waiting for the next audit, and it is much cheaper to settle before the profile ships than after someone notices the routes are missing.