OpenVPN connected but no internet

The log reaches Initialization Sequence Completed, the client shows a green state, and every page times out. OpenVPN connected but no internet is one symptom with two root causes, and they have nothing in common. Either name resolution is broken, or the default route was never installed.

You can tell which in about thirty seconds without opening the config file.

Confirm the tunnel actually came up before you read on. If your log stops short of Initialization Sequence Completed, or ends with AUTH: Received control message: AUTH_FAILED, the tunnel never established and this is the wrong page. Read OpenVPN authentication failed instead.

Ping an address, then ping a name. Run both, in that order, and write down which one fails.

ping 1.1.1.1
ping example.com

The first packet needs a route and nothing else. The second needs a route and a working resolver. Comparing the two results tells you which layer is broken.

• Both succeed: routing and DNS are fine, and the fault is packet size, the browser, a proxy setting, or a captive portal.
• The address replies and the name fails: DNS is broken, and the route is fine.
• Both fail: the default route was never installed, or it points somewhere useless.
• Both fail and the tunnel gateway itself does not reply: the tunnel is up in name only, and the server side is not passing traffic.

That fourth outcome is rarer than the other three and you cannot fix it from the client. Everything else on this page is yours to change.

When both tests pass and pages still hang

This is the case the ping test does not settle, and it is worth naming before you go looking at browsers. Both tests send small packets. A path that carries small packets and drops large ones passes both and still cannot load a web page.

The signature is specific. Name resolution works, a ping replies, a small page loads, and anything with an image or a download stalls part way and never recovers. That is a packet size problem rather than a routing or resolver problem.

Test it by sending a large packet that routers are forbidden to fragment.

ping -M do -s 1400 1.1.1.1
ping -f -l 1400 1.1.1.1

The first form is Linux and the second is Windows. On macOS use ping -D -s 1400. A reply means the path carries a 1428-byte packet and size is not your problem. A fragmentation error, or silence where the small ping replied, means it is.

The fix lives in the profile rather than in the operating system. tun-mtu sets the size of the tunnel interface, and mssfix clamps the TCP segment size that peers advertise, so large TCP transfers stay under the limit without relying on path MTU discovery. The OpenVPN 2.6 manual gives mssfix a default of 1492 mtu, and says the option only makes sense on proto udp. That manual also names this symptom directly: a connection that starts successfully and then stalls during active usage is the usual sign of broken path MTU discovery. Lower mssfix first, because it affects TCP only. Both directives are covered in redirect-gateway and route-nopull.

These two faults feel identical in a browser. A page that will not load looks the same whether the name never resolved or the packet never left. They are not similar underneath, and the fixes do not overlap at any point.

A missing default route means your traffic is still using the physical interface. Nothing enters the tunnel, your public address is unchanged, and the VPN is doing nothing at all. Broken DNS means the tunnel is carrying traffic correctly and you cannot name a destination to send into it.

Both are usually caused by a directive in the profile rather than by a fault in the client. Read what the server actually pushed before you change anything.

openvpn --config profile.ovpn --verb 4

At verbosity 4 the client prints the pushed options in a single line beginning PUSH: Received control message: 'PUSH_REPLY,. Everything the server asked your client to do is in that line, including the routes and the DNS servers. If a directive you expect is missing there, the problem is the server or a local override, not your network.

Symptom: neither an address nor a name responds, and your public address has not changed. Check the route table first, because the answer is visible in one command on every platform.

redirect-gateway def1 and what it does

redirect-gateway def1 is the directive that sends all traffic into the tunnel. It does not replace your default route. The OpenVPN manual describes the def1 flag as overriding the default gateway by using 0.0.0.0/1 and 128.0.0.0/1 rather than 0.0.0.0/0. Those two half-sized routes cover the whole address space at a longer prefix, so they win without deleting anything.

The reason for that trick is that the original default route has to survive. Your client still needs to reach the VPN server itself, and it reaches it over the physical interface using the route that def1 deliberately leaves in place.

If those two routes are absent from your table, the directive was never applied. Either the server did not push it, or the client refused it. Read the PUSH_REPLY line before you decide which, because that distinction decides who can fix it.

When route-nopull is in the config

route-nopull tells the client to accept pushed options except routes and DHCP options. That second half is the part people forget. It discards the pushed DNS servers as well as the pushed routes, which is why a single line can produce both symptoms at once.

Search your profile for it.

grep -n "route-nopull\|redirect-gateway\|pull" profile.ovpn

route-nopull is a legitimate directive for split tunnelling, where you intend to add your own routes afterwards. It is a bug when it is left in a full-tunnel profile. Remove the line, or take a clean file and start over with re-importing the profile. redirect-gateway and route-nopull covers what each flag does in isolation.

Checking the routing table on Windows, macOS and Linux

Run the command for your platform while the tunnel is up, and look for the two /1 routes.

On Windows:

route print -4

On macOS:

netstat -nr -f inet

On Linux:

ip route
ip route get 1.1.1.1

ip route get 1.1.1.1 is the most useful of the three, because it does not ask you to interpret a table. It prints the single route the kernel would actually use, and it names the interface. If that interface is wlan0 or eth0 rather than tun0, your traffic is not entering the tunnel and you have your answer.

Symptom: ping 1.1.1.1 replies and ping example.com does not. The tunnel is carrying packets. Your resolver is either unreachable or is not the one you think it is.

The server pushed a resolver you cannot reach

Most VPN profiles push a resolver on the tunnel subnet with dhcp-option DNS. That address is only reachable through the tunnel, which is fine when routing is correct and fatal when it is not.

Test the pushed resolver directly.

dig @10.8.0.1 example.com
nslookup example.com 10.8.0.1

Substitute the address your own profile pushes. A timeout means the resolver is unreachable and the fault is routing after all. An answer means the resolver works and your system is not using it, which is a different problem in the section below.

Do not leave a public resolver hardcoded as a workaround. It resolves names and it also sends every lookup outside the tunnel, which is the definition of a leak. DNS leak protection covers what that costs you.

Windows and block-outside-dns

Windows sends queries to every configured resolver in parallel and uses whichever answers first. A physical adapter that still holds your ISP resolver will frequently win that race, so names resolve outside the tunnel while the tunnel is up.

block-outside-dns is the directive that stops it. The OpenVPN manual describes it as blocking DNS servers on other network adapters, and as preventing any application from accessing TCP or UDP port 53 except one inside the tunnel. It works through the Windows Filtering Platform on Windows Vista or later. The same manual states the option is unknown on non-Windows platforms and fatal there, which is why one profile loads on Windows and fails everywhere else.

Confirm which resolver Windows is actually using.

ipconfig /all
nslookup example.com

Read those two together. ipconfig /all lists every resolver Windows knows about, including ones it is currently blocked from reaching. nslookup names the server that actually answered, which is the one deciding where your queries go.

Linux and systemd-resolved

On Linux the client does not apply dhcp-option DNS by itself. It hands the option to an up script, and if no script is wired in, the pushed resolver is parsed and then ignored. That is the single most common cause of a working Linux tunnel with dead name resolution.

Check what the resolver stack believes.

resolvectl status
resolvectl query example.com

Look at the per-link section for tun0. If it lists no DNS server, nothing applied the pushed option. The manual is explicit about why. It says the option is put into the environment, so that an --up script could act upon it if needed, which means something has to be wired in to do that acting.

The fix is therefore a resolver hook rather than a config edit. Which hook is a packaging question, so read what your distribution installed alongside the client rather than guessing. The usual candidates are update-systemd-resolved, a resolvconf hook, or native handling in a newer build.

Run the tests in the first column while the tunnel is up.

One caution before you edit routes on a remote machine. Applying redirect-gateway def1 on a server you administer over SSH will send your own management traffic into the tunnel and drop the session. Test it on a machine you can reach physically, or arrange a scheduled rollback first.

The two root causes are the same everywhere. How they present is not.

Windows TAP or Wintun

Windows clients have shipped two different virtual adapters, TAP-Windows and Wintun, and an upgrade can leave both installed. A stale adapter holding a static DNS entry will answer queries while the tunnel is up. Run ipconfig /all and count the VPN adapters, then open Device Manager and confirm which one your current client is actually using.

macOS utun

macOS names the tunnel utun0, utun1 and upward, and the number changes between connections. Resolver state lives in scutil --dns rather than in a file you can read. Run scutil --dns and confirm the tunnel's resolver appears above your physical interface. A VPN configuration profile installed by another client can override that ordering silently.

Linux tun0

tun0 is the usual interface name and it is not guaranteed. Confirm it with ip -br link before you write any rule that names it. Pushed DNS needs a helper as described above, and pushed routes usually apply without one. That asymmetry is why Linux so often shows working routing and broken names at the same time.

A tunnel that reconnects in a loop is a different fault from one that sits connected and passes nothing. Look at keepalive, float and resolv-retry infinite rather than at routes and resolvers, because the connection is being torn down rather than misconfigured. redirect-gateway and route-nopull documents those flags alongside the routing ones. If the drop is preceded by an authentication line in the log, read OpenVPN authentication failed instead.