ANSWERED Firefox(-based browser) startup is stalled when connected to AirVPN with network lock enabled

[hcReJhTCzLS5c5U 1]

Description of Issue and Initial Testing:
As the title states, whenever I have AirVPN with network lock enabled then starting Firefox takes an inordinately long time (for example, if I were to open the terminal and type "Firefox" it takes about 5-10 minutes before anything happens on my screen; it does not matter if I start Firefox from the GUI or terminal). The issue does not present itself when I try to open a chromium-based browser; it opens normally. It does not matter whether it is the first time launching Firefox or the nth time for n > 1.

If I attempt to start Firefox, then the browser will still not open if I disconnect from the server. It will open the instant I turn off network lock. Startup speed is normal if I connect to a server without network lock enabled. Sometimes the problem intermittently comes and goes (bad days and good days) but most of the time it is there. I have tried adjusting the homepage in firefox and it made no difference, even if I set the homepage as simply a blank page.

Conditions to reproduce:

• Use Eddie-UI on Fedora 40 (unsure if it depends on the distro/OS)
• Enable network lock
• Connect to any server
• Attempt to open Firefox or any Firefox-based browser.

Investigating further, the following messages are printed in journalctl when the conditions above are satisfied (approximately alternating):

Quote

[date/time] [host name] systemd-resolved: Using degraded feature set TCP instead of UDP for DNS server [IPv4 address or IPv6 address]
[date/time] [host name] systemd-resolved: Using degraded feature set UDP instead of TCP for DNS server [IPv6 address or IPv6 address]

I do not know enough about how networks are managed on gnu/linux to resolve this on my own, or make sense of this error. Nothing in the logs for Eddie seem to point to the issue either. I have attached the log from Eddie for completeness. It shows me connecting and disconnecting from various servers and attempting to open Firefox with network lock enabled.

Additional info:
OS: Fedora 40 (the issue is present on earlier versions of Fedora as well, at least since Fedora 35)
Client: Eddie UI version 2.21.8
Firefox version: version 128.0, and present on earlier versions.

Note: A separate issue that I will briefly mention here, in case it is relevant, is that on most WiFi networks I have a DNS leak visible in ipleak.net with AirVPN--with or without network lock. On a few networks this DNS leak is not present as long as network lock is enabled. When I say DNS leak I mean that ipleak.net shows the VPN DNS server as well as my router's DNS servers. Again, this may or may not be relevant.

Eddie_20240715_004856.txt

[Staff 10640]

@hcReJhTCzLS5c5U

Hello!

When Firefox starts, it usually generates a lot of traffic. It contacts Mozilla Servers to check for updates, download new features, add-on servers to download and install new extensions, themes, and plugins, DNS servers on its own, SSL/TLS certificate authorities, gelocation services to determine the user’s location and provide location-based services and crash reporting services. If the Firefox traffic goes outside the VPN tunnel for any reason (check Firefox Internet connection configuration) it will be blocked by Network Lock and Firefox main window pop-up will be delayed severely.

Furthermore, a potential new issue is ongoing, which is typical in Fedora and many other distributions "transitioning to" nftables by maintaining iptables syntax backward compatibility with translations and all that jazz (yet another evidence of lack of adequate design skills and vision typical in some Linux environments).

libvirt adds rules via iptables-nft with xtables commands and nft can't process correctly anymore the ruleset. Eddie uses nft whenever it finds it, by default, so if you use libvirt for any purpose (from QEMU to VirtualBox and more), a big rule set mess can arise whenever a program runs nft. The issue has been at the moment tackled and resolved in the AirVPN Suite 2.0.0 beta 1 which goes back to launch iptables-nftables when available (even when nft is available) to avoid the mess.

On Eddie, please modify the "Preferences" > "Network Lock" > "Mode" combo box into iptables-legacy and the problem should be resolved.
 

2 hours ago, hcReJhTCzLS5c5U said:

Note: A separate issue that I will briefly mention here, in case it is relevant, is that on most WiFi networks I have a DNS leak visible in ipleak.net with AirVPN--with or without network lock. On a few networks this DNS leak is not present as long as network lock is enabled. When I say DNS leak I mean that ipleak.net shows the VPN DNS server as well as my router's DNS servers. Again, this may or may not be relevant.

This problem could be resoved by Eddie 2.24 beta, please test it: https://airvpn.org/forums/topic/57401-eddie-desktop-224-beta-released/

Kind regards
 

[hcReJhTCzLS5c5U 1]

18 hours ago, Staff said:

On Eddie, please modify the "Preferences" > "Network Lock" > "Mode" combo box into iptables-legacy and the problem should be resolved.

It would seem that this actually fixed both issues (for the DNS leak, I can only say so for just one of the tested WiFi networks on which the leak existed). Thanks.

[Tech Jedi Alex 1572]

Tells you a thing or two about the Fedora Steering Committee..

But that aside, Mr. hcReJhTCzLS5c5U, this is one hell of a superb bug report. Very well done!
The only minor mistake you made was to copy the logs and not the system report.

[cheeze 8]

I'll wake this topic up again regarding libvirt. 

I have the problem with kvm qemu virtual machines not being able to connect due to the Eddie lock not letting the guest machine connect via NAT. It is suspected the issue lies in the way Eddie uses nft and libvert use ip-tables.

I tried setting Eddie to Iptables-legacy then closed Eddie and opened it again, but the problem persisted. 
Should I have rebooted or logged out of the host machine after making the change to iptables-legacy?

[sethbuck23 0]

 

cheeze said:

I’ll wake this topic up again regarding libvirt because I am still running into the same issue with KVM/QEMU virtual machines. The guests are unable to connect properly because the Eddie lock appears to block their NAT traffic. From what I have been able to gather, the problem may come down to Eddie using nftables while libvirt is still relying on iptables rules, so the two are not playing nicely together. I tried switching Eddie over to iptables-legacy, then completely closed Eddie and reopened it to make sure the change took effect, but unfortunately the problem persisted. At this point I am wondering if there is another firewall rule, bridge setting, or forwarding option that also needs to be adjusted for libvirt NAT to work while Eddie is active. The VMs connect normally once Eddie is out of the picture, so that still seems to point back to the lock or firewall handling rather than the guests themselves. After staring at networking rules for too long, I usually need something completely unrelated to reset my brain, and ivibet casino is the kind of thing where slots with different themes, reel layouts, and mechanics, plus live games and separate category navigation, provide a very different kind of interface to look at. Has anyone found a reliable Eddie and libvirt configuration that works without disabling the lock entirely?

 

No reboot should normally be needed after switching Eddie to iptables-legacy, but you do need to make sure Eddie fully releases and reapplies Network Lock after the change. Closing Eddie while Network Lock is still active can leave rules behind, so I’d first disable Network Lock from Eddie, disconnect, close Eddie, then start it again and reconnect with the new backend selected. That said, libvirt can be a bit of a gremlin here because it creates its own NAT/firewall rules, and Network Lock is intentionally strict, so the guest bridge/NAT traffic may still be blocked unless the relevant libvirt interface is explicitly allowed or routed through the VPN setup you want. Also check whether your distro is actually using iptables-nft behind the iptables command, because “legacy” in Eddie won’t help much if the rest of the system is still dancing with nftables in another corner.

Edited ... by sethbuck23

[cheeze 8]

I'll give this a try.
Thank you
 

[cheeze 8]

I gave the procedure you suggested a try. 
As soon as the lock activates the NAT connection breaks.

Thanks for the suggestion though.