VPN Connects but No Internet: Troubleshooting Guide

The tunnel says connected. The handshake completed. And nothing loads. VPN connects but no internet is one of the most common VPN complaints, and the fix is almost never "reinstall everything." It's a short list of usual suspects, checked in order. Here's the systematic way through it.

The three-ping diagnosis

This takes sixty seconds and tells you exactly where to look. With the tunnel connected:

1. Ping the server's tunnel address (e.g., 10.0.0.1). Success = the tunnel itself carries traffic. Failure = the tunnel is up but not passing data (check keys, firewall on the server, or conflicting routes).
2. Ping an outside IP by number (e.g., 1.1.1.1 or 8.8.8.8). Success = routing to the internet works. Failure = the server isn't forwarding/NATing your traffic (IP forwarding off, missing masquerade rule, wrong firewall zone).
3. Ping a domain name (e.g., example.com). Success = everything works; your "no internet" was probably one broken app. Failure while step 2 worked = DNS problem, the single most common cause.

Write down which step fails. Everything below hangs off that answer.

If step 1 fails: the tunnel isn't really passing traffic

• Firewall on the server blocking forwarded packets. The WireGuard/OpenVPN port being open isn't enough; the firewall must also allow forwarding between the tunnel interface and the WAN. On firewalld/ufw-based systems this is the classic miss.
• Wrong firewall zone (OpenWrt/GL.iNet): the VPN interface must be in a zone allowed to forward to WAN. Check the firewall section, not just the VPN section.
• Key mismatch that still "connects." Some clients show connected with a half-handshake. Re-verify keys both ends.
• Conflicting local route: your tunnel subnet colliding with the LAN you're visiting. If both are 10.0.0.x, packets go to the wrong place. Use an unusual tunnel subnet.

If step 2 fails: the server isn't routing you out

• IP forwarding disabled. net.ipv4.ip_forward must be 1. It gets reset by updates and reboots more often than anyone admits.
• Missing NAT masquerade. The iptables/nftables POSTROUTING rule that lets your private tunnel address talk to the internet. If it was added manually and not persisted, a reboot silently removed it. Make it persistent.
• Server's own internet is down. Embarrassing, but check: can the server itself reach the internet? A home outage looks exactly like a VPN routing failure from the client side.
• CGNAT-side weirdness: if the server is behind CGNAT with a relay, the relay path may be up while forwarding is broken. Check the relay logs.

If step 3 fails: it's DNS (it usually is)

• Client DNS points at the tunnel, but the server isn't resolving. Point the client at a public resolver (Quad9, Cloudflare) through the tunnel instead of the server's LAN DNS, or fix the server's DNS.
• OS ignoring the pushed DNS. Some systems (looking at you, certain Android skins and systemd-resolved configs) keep using the local DNS despite the VPN. Set DNS manually on the client to a resolver reachable through the tunnel.
• Hotel captive portal DNS hijacking. Some portals hijack all DNS until you authenticate. Complete the portal with the VPN off, then connect.

When it's the hotel network, not your VPN

Sometimes the tunnel is fine and the local network is the adversary:

• The hotel throttles or shapes VPN traffic into uselessness. Symptom: tunnel works perfectly on mobile data, crawls on hotel WiFi. Fix: phone hotspot as uplink, or the TCP/443 fallback profile.
• Double NAT or broken hotel DHCP handing your travel router a useless uplink. Reboot the router, re-join the hotel WiFi, complete the portal fresh.
• The hotel blocks the VPN port but not the handshake. Partial filtering produces exactly "connects but nothing flows." Switch protocols/ports.

The mobile-data A/B test is decisive here: if everything works on the hotspot, stop debugging your server. It's the building.

Quick questions

Still stuck?

Our VPN audit exists for exactly this: we trace the failure layer by layer, fix the config, and leave you with a setup that fails loudly instead of mysteriously. https://homeipvpn.com.