Imported VPN routes differ from the working client? Compare both

Some private service answers through the VPN while ordinary internet traffic behaves nothing like it does on a colleague's machine, and the temptation is to conclude the Ubuntu client is broken. That conclusion skips a step. A working private operation and a differing public path are two observations, and the difference usually lives in the traffic policy each client installed rather than in the client itself.

Comparing the saved configuration against the effective network state takes three commands and answers the question the guesswork was trying to answer.

Saved profile first, effective state second

An imported OpenVPN connection becomes a NetworkManager profile of its own. The .ovpn file it came from stops being the source of truth the moment the import completes, so editing that file later changes nothing about the connection you are using. This is the first place the comparison goes wrong, and it goes wrong silently.

nmcli -f connection.id,connection.uuid,ipv4.never-default,ipv4.routes,ipv4.dns connection show office-vpn

Read the UUID when names collide; duplicate names survive reinstalls and profile restores, and you can spend an hour editing the copy that is not in use. The values you see describe saved intent: whether the profile may take the default route, which routes were stored, and which resolvers and search domains it asks for. They do not describe what happened when the connection activated, because a plugin or a server push can add state the profile does not mention. That is why the next command matters.

Then look at what the system actually did with that intent, including policy rules and every table rather than only the main one. Saved properties are inputs, and the installed tables are the result.

ip -4 rule show
ip -4 route show table all

Two destinations, one comparison

Pick one private destination that works and one ordinary public destination, then ask the kernel which path each would take. Doing this on both machines is what turns a vague difference into a specific one.

ip -4 route get 10.40.0.20
ip -4 route get 203.0.113.20

The addresses are examples to replace with your own; the point is the pair, not the numbers. Compare the interface, the source address and the table named in each output. When the private lookup names the tunnel and the public lookup also names the tunnel, you have a full tunnel and the other client may have a split one, or the reverse.

Do not require the two clients to print identical text. An OpenVPN redirect-gateway def1 is commonly expressed as two half-prefix routes rather than one default, and a manager that displays them differently is not thereby wrong. Judge coverage, which is what the lookups show, rather than formatting.

Where the two clients legitimately differ

Client defaults are policy choices, and they are allowed to disagree. One product may prefer a full tunnel, another may keep the local default and route only the private prefixes, and a third may follow whatever the server pushed. A difference is only a defect when it contradicts the requirement you were given.

So compare each client against the approved split or full-tunnel intent, not against each other. If the requirement is that private traffic uses the tunnel and the local internet path stays local, then a full tunnel is the bug and a split tunnel is correct, regardless of which client did which. Write the intent down before you look at either configuration, or the first client you inspect quietly becomes the standard.

DNS is a second axis and it fails independently. A correct route can still send queries to a resolver that cannot answer for the private zone, and a correct resolver does not fix a wrong route. Check both, and treat a private name that resolves while a private address does not as evidence that the two layers are being solved separately.

Keep the comparison clean

Run one connection owner at a time. A command-line OpenVPN session running beside the imported profile installs its own routes and its own resolver state, and the resulting mix is neither client's behaviour. Tear one down before you measure the other. Reboot if you are unsure what is still holding state, because a stale route from an hour ago will look exactly like a policy problem.

Hold everything else fixed as well: the same endpoint, the same account, the same software versions, the same network. A success on a colleague's Windows laptop tests a different client, a different resolver integration and possibly a different server profile, so it is not evidence about the Ubuntu manager.

NetworkManager's IPv4 settings reference defines never-default and the saved route properties precisely, which is worth reading before you change a managed value. And remember the scope of this comparison: it covers IPv4, and it says nothing about the corresponding IPv6 policy, which has its own defaults and its own way of surprising you.