OpenVPN Connected but No Internet: Fix Routing, DNS, NAT

If your OpenVPN client shows “Connected” but you cannot browse the web, the problem is almost always one of four things: DNS settings not pushed or not used, routing that does not send traffic through the tunnel, NAT/masquerade missing on the server, or a firewall blocking forwarded traffic. This article walks you through diagnosing and fixing each of these in order, with commands and config snippets you can adapt to your setup.

Why “Connected” Does Not Mean “Working”

OpenVPN establishes an encrypted tunnel between your device and the server. The status “Connected” only means the TLS handshake succeeded and the tunnel is up. Whether your internet traffic actually flows through that tunnel depends on three separate layers:

Routing – your OS must add a route that sends your traffic into the tunnel interface (e.g., tun0).
DNS – your system must use the DNS servers pushed by the VPN, or you must set them manually.
NAT and forwarding – the server must be configured to forward packets from the tunnel to the internet and apply NAT (masquerade) so replies come back.

If any of these is missing or misconfigured, you get a successful connection but no internet. The sections below address each layer.

Step 1: Check and Fix Routing

First, verify that your client is actually sending traffic through the tunnel. On Linux or macOS, run ip route (or route -n). On Windows, use route print.

Look for a route that sends your default traffic (0.0.0.0/0) through the VPN interface. If you see only a specific subnet route (e.g., 10.8.0.0/24), then only traffic to that subnet goes through the tunnel; everything else goes out your normal gateway.

Fix: In the client config file, add one of these:

redirect-gateway def1 – pushes two routes (0.0.0.0/1 and 128.0.0.0/1) that cover all addresses, effectively making all traffic go through the VPN.
redirect-gateway bypass-dhcp – same as above but also bypasses DHCP-assigned routes (useful on Windows).

If you only want specific traffic to go through the tunnel, use route 192.168.1.0 255.255.255.0 or similar, but for “internet not working” you almost always need the full redirect.

After changing the config, reconnect. Then test with ping 8.8.8.8 – if that works but ping google.com fails, you have a DNS problem.

Step 2: Fix DNS Resolution

DNS is the most common reason a VPN connects but websites don’t load. The tunnel is up, but your system is still using your ISP’s DNS, which may be blocked or may not resolve internal names.

On the server, push DNS servers in the server config:

push "dhcp-option DNS 8.8.8.8"
push "dhcp-option DNS 8.8.4.4"

For OpenVPN 2.5+ on Linux, you may also need to add dhcp-option DOMAIN-ROUTE . to force DNS to use the pushed servers for all queries.

On the client, check if the pushed DNS is actually used:

Linux: check /etc/resolv.conf – it should show the pushed DNS. If not, your system may not be using OpenVPN’s up scripts. Install openvpn-systemd-resolved and add to the client config: setenv opt 'dhcp-option DNS 8.8.8.8' and script-security 2.
Windows: OpenVPN by default sets DNS via the TAP adapter – check with ipconfig /all.
macOS: OpenVPN may not change DNS automatically; you can use a script or set DNS manually in System Preferences.

If DNS is still not working, test with nslookup google.com and see what server it uses. You can also temporarily set your client’s DNS to 8.8.8.8 manually to confirm the fix.

Step 3: Enable NAT and IP Forwarding on the Server

Even if the client sends traffic into the tunnel, the server must forward it to the internet and translate the source address. Without NAT, the reply packets would be sent to the VPN client’s internal IP (e.g., 10.8.0.2), which the internet doesn’t know how to route back to.

On the server (Linux), do the following:

Enable IP forwarding: edit /etc/sysctl.conf and set net.ipv4.ip_forward = 1, then apply with sysctl -p.
Add a NAT rule in iptables. Replace eth0 with your server’s internet-facing interface:

iptables -t nat -A POSTROUTING -s 10.8.0.0/24 -o eth0 -j MASQUERADE

If you use nftables, the equivalent is:

nft add rule nat postrouting ip saddr 10.8.0.0/24 oif "eth0" masquerade

Make the iptables rule persistent (e.g., iptables-save and restore on boot). On many systems, you also need to allow forwarding in the firewall:

iptables -A FORWARD -i tun0 -o eth0 -j ACCEPT
iptables -A FORWARD -i eth0 -o tun0 -m state --state ESTABLISHED,RELATED -j ACCEPT

If you use a firewall like UFW, you may need to edit /etc/default/ufw and set DEFAULT_FORWARD_POLICY="ACCEPT".

Step 4: Firewall Rules on Client and Server

Firewalls can block the VPN traffic even after routing and NAT are correct. On the server, ensure that the OpenVPN port (default 1194/udp) is open, and that forwarding is allowed as above. On the client, your local firewall might block the TUN adapter – allow all traffic on that interface.

Common firewall mistakes:

On the server, the FORWARD chain has a default DROP policy and you didn’t add the ACCEPT rules above.
On the client, a firewall profile (e.g., Windows Public network) blocks the TUN adapter.
On the server, you only opened port 1194 but not the forwarding rules.

To test if the firewall is the issue, temporarily set the server’s FORWARD chain to ACCEPT and see if the client gets internet. If it does, then your rules are too restrictive.

Step 5: Common Client-Specific Issues

Sometimes the problem is on the client OS, not the server.

Windows: The TAP adapter may have a lower metric than your physical adapter, so Windows prefers the physical route. In the OpenVPN client, you can set route-metric 1 in the config to force the VPN route to be preferred.
Linux (NetworkManager): NetworkManager may not apply the pushed DNS. Use nmcli connection modify <name> ipv4.ignore-auto-dns no and set ipv4.dns-priority to a positive value.
macOS: The built-in OpenVPN client (Tunnelblick or OpenVPN Connect) may not set DNS automatically. Use a script or set DNS manually in System Preferences.

Also, if you are using a split tunnel (only some traffic goes through VPN), ensure that the traffic you are trying to reach (e.g., a website) is actually in the routed subnet.

Step 6: Verify with Diagnostic Commands

Run these in order to isolate the problem:

ping 10.8.0.1 – from the client, this tests the tunnel itself. If this fails, the tunnel is not up properly.
ping 8.8.8.8 – from the client, this tests routing through the tunnel. If this works, routing is fine.
ping google.com – from the client, this tests DNS. If this fails, DNS is the issue.
On the server, run tcpdump -i tun0 and tcpdump -i eth0 to see if packets arrive and leave. If you see packets on tun0 but not on eth0, NAT/forwarding is broken.

If you are using a commercial VPN provider, you usually cannot change the server config. In that case, try their support or switch to a different protocol (e.g., WireGuard) if available.

Frequently Asked Questions

Why does my OpenVPN connect but I can’t ping anything?

If you can’t even ping the server’s VPN IP (10.8.0.1), the tunnel is down despite the “Connected” status. Check the server’s firewall for the OpenVPN port, and ensure the client and server have matching cipher and auth settings. Also check that the server’s server directive uses a subnet that doesn’t conflict with the client’s LAN.

How do I make OpenVPN use my own DNS instead of the pushed one?

On the client, you can ignore pushed DNS by adding pull-filter ignore "dhcp-option DNS" in the client config. Then set your DNS manually in the OS. However, this may break access to internal resources that rely on the VPN DNS.

What is the difference between redirect-gateway and redirect-gateway def1?

redirect-gateway without def1 adds a route for 0.0.0.0/0, which can be overridden by other routes. def1 adds two routes (0.0.0.0/1 and 128.0.0.0/1) that together cover all addresses and are more specific, so they are preferred. Use def1 for reliable full-tunnel routing.

My VPN works on my phone but not on my PC – why?

This usually points to a client-specific issue: firewall on the PC, DNS not being applied, or a conflicting route. Compare the network settings on both devices. On Windows, try disabling IPv6 temporarily, as some VPN setups have issues with IPv6 leaks.

Do I need to open ports on my router for OpenVPN to work?

Only if you are running the OpenVPN server behind a NAT router. The client needs to reach the server’s public IP and port (default 1194/udp). If you are only a client, you don’t need to open any ports.

Can I fix this by reinstalling OpenVPN?

Rarely. Reinstalling the client software often does not change routing, DNS, or server-side NAT. Those are configuration issues. Reinstall only if you suspect corrupted configuration files, but first check the steps above.

Method: the standard formula for this calculation, rounded as each result states. See how the calculators work or report an error.

More cards in this drawer

The whole Numbers and Powers drawer →