Hi, does anyone know how to solve the following problem. I have installed Nordvpn. I can connect to a server of Nordvpn That works, but after that the internet stops working. When I disconnect from the Nordvpn server, the internet works again. Has anyone experience with Nordvpn?
Hello @jeu and welcome!
I have had this happen before with OpenVPN, which is always just a configuration issue that I’ve flummoxed. That said, while there’s no direct hit when searching for your issue on the Internet, there is one relating to the exact issue using Windows. In that post, they say to:
- Try changing the server you are connecting to
- Try using OpenVPN (TCP)
- The issue may also be related to your antivirus or security software
Before you discount the last item, it could be a security setting in your firewall or selinux configuration if you are using either of those. I’m hoping that someone that uses NordVPN will also respond with their experiences.
One more thing. I also found this post responding to someone with the exact problem:
"Late to the party, but I installed nordvpn (Linux) today and had the same issue, this is how I fixed it:
nordvpn whitelist add subnet 192.168.0.0/24
Problem was that the nordvpn firewall was blocking access to the local network, that includes my DNS server.
Whitelist the local network, problem goes away :-)"
But there’s a bigger picture to consider:
In some cases, when you connect to a VPN, you are supposed to lose local internet access, and use the internet access at the other end. e.g. you RDP into a Windows PC and run a web browser and it shows web pages. The DNS is also supposed to be at their end.
Of course you can set it up in a different way, sometimes called a “split tunnel” where local requests are routed in a different way to remote requests.
We do know that in default (one interface) setup the routing table looks like:
default via (GW in LAN)
link-local subnet (LAN): use interface (em1)
Now your VPN client establishes connection to VPN server. It must use the routes above:
forward to GW, i.e. toss out from em1 (unless the VPN server is in the link-local subnet …)
The VPN offers a new interface and subnet behind it. Fine, you have two sets of neighbours:
link-local subnet (VPN): use interface (vp0)
However, without the “split tunnel” the default route is changed to be someone in the VPN subnet (once known as “roadwarrior” config):
default via (GW2 in VPN)
link-local subnet (LAN): use interface (em1)
link-local subnet (VPN): use interface (vp0)
Now the question is: How does the VPN client continue to send packets to the VPN server?
According to routing table it should send to GW2 by tossing packets out from vp0.
If it puts anything out from vp0, it will get those packets, encrypt them, and should send a packet to VPN server.
That is impossible. Therefore, the machine must continue to send the packets of the VPN connection via “local internet”.
At least one OpenVPN setup did actually create following routes:
default via (GW2 in VPN)
VPN server via GW in LAN
link-local subnet (LAN): use interface (em1)
link-local subnet (VPN): use interface (vp0)
That extra static route keeps the whole up.
I have seen setups where that (or equivalent) was not sufficient; the initial local config had quirks that the VPN client failed to anticipate.
I don’t know Nordvpn, but if it does tamper with firewall too … 
I would look at routes and ruleset both before and after starting the gizmo:
ip ro
cat /etc/resolv.conf
sudo nft list ruleset
Hi all,
Thank you very much for your comments.
Unfortunately, so far I couldn’t solve the problem.
@sspencerwire. Yesterday I also contacted the Nordvpn helpdesk. They also recommended using OpenVPN and TCP. But it didn’t work. Whitelisting the local network in the Nordvpn firewall also didn’t work.
I disabled selinux on another installation of Rocky Linux, which also had no effect. And today I disabled the firewall, and that didn’t work either.
I think it must be something in Rocky Linux that is causing the problem. If I install another Linux distribution, I have no problems.
@jlehtone. I ran the three commands just before connecting to Nordvpn and just after. The command “ip ro” makes no difference, but the other two do. See attachment differences.txt. Maybe that provides an entry point for the solution?
I notice I cannot attach the file. Then I will paste the text of differences.txt here. I didn’t show the entire output of the ¨nft list ruleset¨ command, but only the differences.
ip ro
Before:
default via 192.168.178.1 dev enp34s0 proto dhcp src 192.168.178.141 metric 100
192.168.178.0/24 dev enp34s0 proto kernel scope link src 192.168.178.141 metric 100
After:
default via 192.168.178.1 dev enp34s0 proto dhcp src 192.168.178.141 metric 100
192.168.178.0/24 dev enp34s0 proto kernel scope link src 192.168.178.141 metric 100
-----------------------------------------------------------------------------------
cat /etc/resolv.conf
Before:
# Generated by NetworkManager
search fritz.box
nameserver 192.168.178.1
After:
# Generated by NordVPN
nameserver 103.86.96.100
-----------------------------------------------------------------------------------
nft list ruleset
Before:
table ip filter {
chain INPUT {
type filter hook input priority filter; policy accept;
+ iifname "enp34s0" ip saddr 103.86.99.100 counter packets 0 bytes 0 accept
+ iifname "enp34s0" ip saddr 103.86.96.100 counter packets 0 bytes 0 accept
+ iifname "enp34s0" ct mark 0xe1f1 counter packets 1 bytes 120 accept
+ iifname "enp34s0" counter packets 18 bytes 2562 drop
}
chain OUTPUT {
type filter hook output priority filter; policy accept;
+ oifname "enp34s0" ip daddr 103.86.99.100 counter packets 0 bytes 0 accept
+ oifname "enp34s0" ip daddr 103.86.96.100 counter packets 0 bytes 0 accept
+ oifname "enp34s0" mark 0xe1f1 counter packets 831 bytes 130084 ct mark set mark
+ oifname "enp34s0" ct mark 0xe1f1 counter packets 831 bytes 130084 accept
+ oifname "enp34s0" counter packets 36 bytes 2814 drop
}
}
After:
table ip6 filter {
chain INPUT {
type filter hook input priority filter; policy accept;
+ iifname "enp34s0" ct mark 0xe1f1 counter packets 0 bytes 0 accept
+ iifname "enp34s0" counter packets 0 bytes 0 drop
}
chain OUTPUT {
type filter hook output priority filter; policy accept;
+ oifname "enp34s0" mark 0xe1f1 counter packets 0 bytes 0 ct mark set mark
+ oifname "enp34s0" ct mark 0xe1f1 counter packets 0 bytes 0 accept
+ oifname "enp34s0" counter packets 2 bytes 232 drop
}
}
Perhaps another interesting fact. When I am connected to Nordvpn, Firefox refuses to open. Only when the connection with Nordvpn is broken, Firefox will still be opened.
I think the fact that your route doesn’t change (the results of the ip ro command above) is the key. You’ve got working machines, as I understand it, using different Linux distros. What are the differences on those machines both before and after connecting to the VPN? To give you an example, here is what my routes look like, first without a connection to my VPN and then with the connection active:
default via 10.0.0.1 dev wlp0s20f3 proto dhcp src 10.0.0.108 metric 600
10.0.0.0/24 dev wlp0s20f3 proto kernel scope link src 10.0.0.108 metric 600
10.168.231.0/24 dev lxdbr0 proto kernel scope link src 10.168.231.1
192.168.122.0/24 dev virbr0 proto kernel scope link src 192.168.122.1 linkdown
and after connecting:
default via 192.168.50.1 dev tun0 proto static metric 50
default via 10.0.0.1 dev wlp0s20f3 proto dhcp src 10.0.0.108 metric 600
10.0.0.0/24 dev wlp0s20f3 proto kernel scope link src 10.0.0.108 metric 600
10.0.0.1 dev wlp0s20f3 proto static scope link metric 50
10.168.231.0/24 dev lxdbr0 proto kernel scope link src 10.168.231.1
140.228.132.100 via 10.0.0.1 dev wlp0s20f3 proto static metric 50
192.168.1.0/24 via 192.168.50.1 dev tun0 proto static metric 50
192.168.50.0/24 dev tun0 proto kernel scope link src 192.168.50.2 metric 50
192.168.122.0/24 dev virbr0 proto kernel scope link src 192.168.122.1 linkdown
The absence of a tun0 route (or something that depicts the tunnel) seems to me like the red flag.
I have a guest VM Debian 11. Rocky is the host OS (VirtualBox installation). Nordvpn works in Debian. But the ip ro command shows no difference between being connected or not connected to the VPN:
default via 10.0.2.2 dev enp0s3 proto dhcp metric 100
10.0.2.0/24 dev enp0s3 proto kernel scope link src 10.0.2.15 metric 100
default via 10.0.2.2 dev enp0s3 proto dhcp metric 100
10.0.2.0/24 dev enp0s3 proto kernel scope link src 10.0.2.15 metric 100