VPN on Linux Not Working: DNS, NetworkManager and MTU Without Panic in 2026

If VPN on Linux is not working, it does not always mean the service is blocked or "broken forever." On Linux, three layers usually get in the way: DNS via systemd-resolved, the NetworkManager profile, and MTU packet size. Below is practical diagnostics for Ubuntu, Fedora, Arch-based systems and other distributions, without risky workarounds and without "wipe everything and reinstall" advice.

This guide is useful if the tunnel connects but websites don't open; if some domains load while others hang; if WireGuard or OpenVPN work on your phone but not on your laptop; if DNS disappeared after a Linux update. If you need a ready-to-use VPN for daily access with clear support, start with the FoliVPN landing page and use this article as a diagnostic checklist.

Why This Topic Matters in 2026

In 2026, users in Russia increasingly face not one big error, but a combination of network restrictions, unstable mobile networks, traffic filtering, and local device settings. In previous articles we already covered why VPN on Windows 11 is not working, what to do when VPN on Mac is not working, and why MTU VPN breaks website loading. Linux deserves a separate breakdown: there is more freedom here, but also more places where DNS, routes and clients can conflict.

Recent research shows three recurring patterns. First, on Linux NetworkManager sometimes fails to apply the VPN provider's DNS, which causes domains not to resolve or leads to a DNS leak; this is exactly what the IVPN help article for Linux describes. Second, WireGuard officially recommends checking the interface, peer, AllowedIPs and, if necessary, PersistentKeepalive, because NAT and stateful firewalls can "forget" a silent tunnel. Third, OpenVPN cases where the tunnel is connected but some sites don't open often point to MTU: the packet is too large for a specific route and starts getting dropped.

Quick Diagnostics: First Separate VPN from Regular Internet

Before changing configs, check the basics. Disable the VPN and open several neutral sites: a search engine, your bank's site or a government portal, your ISP's page. If the internet is also unstable without VPN, the problem is not in the client. Then connect the VPN and check three signs:

• whether the external IP changes;
• whether domains open, not just IP addresses;
• whether Wi‑Fi, cable, and mobile hotspot behave the same way.

If VPN works over a mobile hotspot but not over your home router, the conflict is more likely in the router, MTU, DNS, or ISP rules. If Windows or a phone work on the same network but Linux does not, look at NetworkManager, systemd-resolved, routes, and the local firewall.

Symptoms and Likely Causes Table

Step 1. Check DNS, Not Just the "Connected" Status

The most common Linux trap is when the client says VPN is connected, but DNS queries still go through the router or ISP. In this situation the browser may show "can't find server IP," Telegram and messengers hang, and the IP check is misleading: the tunnel seems to exist, but site names are not resolved correctly.

What to do safely:

1. Look at which DNS servers are assigned to interfaces. On modern systems, resolvectl dns usually helps.
2. Find the VPN interface: wg0, tun0, ppp0, NetworkManager profile, or the client name.
3. Make sure the VPN DNS is assigned specifically to the VPN interface, not just globally.
4. If DNS is empty or still shows a router address like 192.168.1.1, check the VPN profile in NetworkManager.
5. Don't make /etc/resolv.conf "permanent" via chattr +i unless necessary: it may solve one case and break future network updates.

The IVPN help article describes a similar scenario: when connecting through NetworkManager, the provider's DNS may not be applied automatically, so sites don't open or the real DNS is used. This is not a universal instruction for all VPNs, but a good indicator of the diagnostic direction.

Step 2. Deal with systemd-resolved and NetworkManager

systemd-resolved is not the enemy of VPN by itself. The problem appears when NetworkManager, the VPN client, and resolved have different ideas about which interface should handle DNS queries. On Ubuntu and Fedora this is especially noticeable: /etc/resolv.conf may point to 127.0.0.53, while the real DNS servers live in resolvectl.

A practical order is:

• don't disable systemd-resolved as your first action;
• check whether the VPN profile creates DNS for its interface;
• look at DNS priority in NetworkManager if you use a GUI profile;
• make sure old Docker, bridge, or tun interfaces are not pulling routes;
• after changing the profile, reconnect the VPN, not just restart the browser.

If you use a corporate OpenVPN or WireGuard profile, don't change server DNS at random. It's better to first compare the output before and after connecting, and send it to your provider's support. For FoliVPN the useful minimum is: distribution, client version, protocol type, error screenshot/text, DNS output, and a description of the network — Wi‑Fi, LTE, router, or office network.

Step 3. WireGuard: Check AllowedIPs, Handshake and Keepalive

WireGuard is minimalist: if the config is wrong, it doesn't always produce a "pretty" error. The official quick start shows the basic logic: interface, address, keys, peer, endpoint, AllowedIPs, then bringing up the interface via wg-quick or the system manager. What matters to the user is not commands for the sake of commands, but the meaning of the checks.

Look at three things:

1. Handshake. If there is no latest handshake, the client did not agree with the server. The reason may be the endpoint, keys, network, or firewall.
2. AllowedIPs. For a full tunnel, all traffic is usually routed; for a split tunnel, only specific subnets. If there's an error here, some sites will bypass the VPN or won't go through at all.
3. PersistentKeepalive. WireGuard documents that it is "silent" by default. Behind NAT or a stateful firewall, the tunnel can go idle and lose reachability. A 25-second interval is often used as a reasonable setting, but it should be enabled only when there is a symptom: the connection lives briefly or drops after being idle.

Don't publish private keys, configs, or full endpoint addresses in open chats. For diagnostics it is enough to mask sensitive values and leave the profile structure.

Step 4. OpenVPN: If Connected but Sites Open Only Halfway

OpenVPN can successfully connect, get an address and routes, yet HTTPS pages still hang. It is especially suspicious if small sites open while YouTube, cloud services, GitHub, or heavy pages don't. In this case, check MTU. On Ask Ubuntu a similar case was discussed where VPN works on Windows and over mobile, but breaks on Linux on home Wi‑Fi; one likely factor is MTU.

MTU is the maximum packet size. VPN adds service headers, so a packet that fit the route without the tunnel can become too large inside the tunnel. If fragmentation is blocked along the path, the result looks strange: "internet works," but some sites don't load.

What to check without risky actions:

• compare behavior over a different network;
• temporarily lower MTU in the profile or interface, if the client allows it;
• check whether the issue repeats only on OpenVPN, or also on WireGuard;
• don't change DNS, MTU and firewall at the same time — otherwise you won't know what helped.

Step 5. Local Firewall, Docker and Routes

Linux is often used by developers, which means a laptop may have Docker networks, bridge interfaces, local proxies, nftables, iptables, and corporate security agents. All of this can affect routing.

Mini checklist:

• after connecting the VPN, check whether a default route through the tunnel appeared;
• make sure the Docker bridge doesn't conflict with the VPN subnet;
• temporarily disable only