NordVPN on Linux Blocks the LAN: Allowlist and DNS

Everything looks normal until you try to reach something on your own desk. The tunnel is up, pages load, and the network drive times out. Disconnect and the drive is back before you finish the sentence, which tells you more than any log will: the client is deliberately refusing traffic that does not enter the tunnel, and your local network is on the wrong side of that line.

The kill switch is doing its job

A kill switch exists to stop traffic from escaping when the tunnel is unavailable. Private address ranges count as traffic that does not enter the tunnel, so a strict implementation blocks them along with everything else. That is not a bug in the sense people mean when they file the report.

Read the client's own view first. One command prints the current settings, and a second shows the firewall objects the client created. You are looking for a drop or reject that appears before any tunnel exception, because that ordering is what makes the local network unreachable.

nordvpn settings
sudo nft list ruleset
sudo iptables -S

Then run one test that splits the problem in half. Reach the device by address, and reach it by name. Address works and name fails means the firewall is innocent and the resolver is not. Both fail means the firewall is refusing the packet, and the rest of this article applies.

Allowlisting: choose the entry type by symptom

The client offers an allowlist with three kinds of entry, and picking the right kind is most of the work. A subnet covers hosts. A port covers one service regardless of destination. A multicast group covers discovery traffic, which is a different shape of traffic from anything addressed to a single host.

nordvpn allowlist add subnet 192.168.1.0/24
nordvpn allowlist add port 22
nordvpn allowlist add subnet 239.255.255.250/32
sudo nft list ruleset | grep -i allow

Discovery failures catch people out because a printer or media server may be found by a group-addressed query rather than by a lookup of its own address. Adding the host's subnet does not automatically cover that group, so the device stays invisible while its web page loads fine when you type the address.

Keep the exception as narrow as the symptom allows. A wide prefix typed once is forgotten for years, and nobody can later explain which machines it was meant to admit. Delete entries when the project that needed them ends, and check what remains after an update.

Recent builds also expose a single LAN discovery setting. It is convenient, and it interacts with the allowlist rather than stacking on top of it: turning it on can clear existing private-subnet entries, and a manual private-subnet rule may be refused while it stays enabled.

Hostnames need a separate decision

Allowing a subnet restores connectivity by address and leaves naming untouched. Local hostnames are still sent to whichever resolver the client configured when the tunnel came up, so a name that used to resolve now returns nothing.

Pointing the client at the router's resolver fixes that in one step and quietly changes what you bought. Every lookup, not only local ones, then leaves through the router, so the tunnel no longer protects the part of your browsing that reveals intent.

The narrower route keeps the tunnel resolver and adds the few names that matter, either as a search domain or as individual entries. It costs more attention and preserves the property you paid for.

Check the result with a system resolver call rather than a browser. Browsers increasingly run their own encrypted resolution and will happily answer from a path your shell never uses, so the address bar can look healthy while the system resolver is still broken.

The install problem that comes first

A fair share of these reports never reach the firewall, because the command is not there at all. The vendor's bootstrap package registers a repository and a signing key. It does not install the client, so a missing command immediately afterwards is the expected outcome rather than a failure.

Refresh the package lists and install by name. If the package manager complains about a missing public key, the key did not land where it looks for one, and the fix is to place it there before refreshing again.

If the repository hostname resolves to a private address, stop and read that result twice. You may already be running a tunnel whose resolver is answering for public names, and retrying the install will produce the same message indefinitely.

Write it down before you close the lid

Establish that the tunnel is the only thing that changed, then allow the smallest thing that restores the symptom. Keep naming as its own decision with its own note.

Record which exception exists for which device and who asked for it. A local network that only works because someone typed a wide prefix is a decision that has already outlived the reason for it.

Re-test after the client updates. Firewall layout changes between releases, and last month's allowlist is not a fact about this month.