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

[hcReJhTCzLS5c5U 0]

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 9972]

@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 0]

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.

[OpenSourcerer 1435]

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.