ANSWERED No internet unless connected to AirVPN [SOLVED]

[Tubular 1]

I know this issue has been talked about a couple of times over the last decade, but I haven't found a solution yet, unless I'm not searching for the correct phrases or keywords.

My system:
Linux Mint 21.3 MATE
Eddie 2.24.6
PiHole on a Raspberry Pi.

If I don't connect to the VPN, I have no internet connection.
I always enable Network Lock before connecting; normally I set it to activate at startup.
I always disconnect properly before shutting down the computer, except for a couple of mishaps.
I've tried resetting Eddie to default settings and rebooting, with no effect.

I'm not sure if this is relevant, but, until recently, I had noticed that when using Network Lock, my `ufw` status would change from "active" to inactivated. Then when turning off Network Lock, `ufw` status would revert to "active." I think that's expected behavior, right?
Now, however, as of several months ago (?), with this current issue, I see that `ufw` does not go inactive when I enable Network Lock. Could that be part of the problem?

Is there a command I can run to get some relevant data for troubleshooting?
Thanks.

 

Edited ... by Tubular
To mark as Solved

[greenhouseblues 0]

I had this problem too. If I shut down Eddie without disengaging the vpn & network lock first, I couldn't access the internet without the VPN afterwards.

Being a Linux novice, a google search recommended that I open a terminal and run the command:

systemctl restart systemd-resolved.service

Don't know what it does, but it worked every time for me.

I'm sure more qualified members can hep more though.

[Tubular 1]

Thanks. Doesn't seem to work for me.

[Staff 10111]

On 1/23/2025 at 4:21 PM, Tubular said:

Now, however, as of several months ago (?), with this current issue, I see that `ufw` does not go inactive when I enable Network Lock. Could that be part of the problem?

Hello!

Maybe. For a quick check to discern whether the problem is caused by ufw please disable it completely with the command:

sudo ufw disable

You can later re-enable it with

sudo ufw enable

Kind regards
 

[Tubular 1]

On 2/7/2025 at 11:26 AM, Staff said:

quick check to discern whether the problem is caused by ufw

On 2/7/2025 at 11:26 AM, Staff said:

 

Thanks for the suggestion. Disabling and rebooting didn't solve the issue, though. Still a mystery. :-)

[Staff 10111]

On 2/18/2025 at 5:58 PM, Tubular said:

Thanks for the suggestion. Disabling and rebooting didn't solve the issue, though. Still a mystery. 🙂

Hello!

Please run Eddie, enable Network Lock, connect to a VPN server, disconnect from that VPN server, disable Network Lock and then send us:

• a system report generated by Eddie https://airvpn.org/forums/topic/50663-youve-been-asked-for-a-support-filesystem-report-–-heres-what-to-do/
• the output of "sudo nft list ruleset"
• the output of "sudo iptables-save"
• the output of "sudo ufw status"
• the output of "cat /etc/resolv.conf"

In general, since Mint packet filtering platform is based on nftables, you should keep ufw disabled (the default setting in Mint 21.x) to avoid various clashes caused by translations forced by the hybrid usage of iptables-legacy (ufw works only with iptables, not with nftables) and nft.

Kind regards
 

[Tubular 1]

Finally getting around to this... Thanks for the instructions. I've just sent you the requested log and output.

Some additional info:
I upgraded to Mint 22.1 to see if the issue would sort itself out, but it didn't. So it seems ufw is the culprit. Awaiting your reply to the reports I've submitted, at your convenience.

Thank you again.

Edited ... by Staff
Fixed problem caused by editor's quoting bug

[Staff 10111]

@Tubular

Thanks for the relevant log and output.

We have two overlapping problems here. One is caused by the translations between iptables and nftables (only when ufw is enabled, otherwise nftables usage is consistent and translations never enter into play). This is quickly resolved by not enabling ufw, as you noticed.

The other problem is that when a session is over Eddie restores an old /etc/resolv.conf backup created in the past by Eddie 2.21.8:

 # Generated by Eddie v2.21.8 - https://eddie.website - Tuesday, January 14, 2025 3:36:48 PM UTC

nameserver 10.<cut>

The above is wrong and it could be the consequence of some old Eddie 2.21.8 dirty status caused by a crash. For the new Eddie the above file is the normal system setting to restore at the end of a session, so Eddie will make your system unable to resolve names when your system is not connected to the VPN. Please shut down Eddie, edit /etc/resolv.conf with any text editor (root privileges required) and enter only publicly available name servers, for example Quad9 (we recommend it for privacy and neutrality commitment). An example:
 

nameserver 9.9.9.9
nameserver 149.112.112.112
nameserver 2620:fe::fe # only if your system, router and ISP support IPv6

Save the file, re-start Eddie, connect to some VPN server, shut down Eddie and verify whether the problem is solved.

Kind regards
 

[Tubular 1]

3 hours ago, Staff said:

The above is wrong and it could be the consequence of some old Eddie 2.21.8 dirty status caused by a crash. For the new Eddie the above file is the normal system setting to restore at the end of a session, so Eddie will make your system unable to resolve names when your system is not connected to the VPN. Please shut down Eddie, edit /etc/resolv.conf with any text editor (root privileges required) and enter only publicly available name servers, for example Quad9 (we recommend it for privacy and neutrality commitment). An example:

Yes, that totally fixed it! Thank you very much.
🙂