This site will have limited functionality while we undergo maintenance to improve your experience. If an article doesn't solve your issue and you want to ask a question, we have our support community waiting to help you at @FirefoxSupport on Twitter and/r/firefox on Reddit.

Search Support

Avoid support scams. We will never ask you to call or text a phone number or share personal information. Please report suspicious activity using the “Report Abuse” option.

Learn More

Hierdie gesprek is in die argief. Vra asseblief 'n nuwe vraag as jy hulp nodig het.

Firefox for Linux [Flatpak] takes minutes to start when behind VPN.

  • 5 antwoorde
  • 1 het hierdie probleem
  • 1 view
  • Laaste antwoord deur jonzn4SUSE

more options

The issue concerns the Flatpak version of Firefox on Linux. This issue only happens when I'm connected to my VPN router. For info, I'm using Fedora 35 Silverblue. This issue happens on Fedora 35 or Fedora 35 Silverblue. I been using Fedora since version 33 and such problem existed back then.

When connected to my VPN provider via my router, trying to start a Firefox Flatpak instance takes minutes upon minutes to load. I'm guessing it has to do with DNS query's Firefox does on start but I'm not sure. All I know is that when I connect directly to the internet without being hehind my VPN, Firefox loads in a split second. When I'm using the RPM version of Firefox supplied by Fedora, I do not have such issues even when connected to my VPN. This issue only affects Firefox Flatpak when behind a VPN. I tried opening the AppImage version of Firefox while connected to my VPN, and once again, it loaded within a few seconds. I been having this issue for many years and only figured out recently that my VPN connection was causing a problem.

I would like to point out that the Flatpak verion of Microsoft Edge and Chromium do start without any issues even while I'm connected to my VPN provider...

The issue concerns the Flatpak version of Firefox on Linux. This issue only happens when I'm connected to my VPN router. For info, I'm using Fedora 35 Silverblue. This issue happens on Fedora 35 or Fedora 35 Silverblue. I been using Fedora since version 33 and such problem existed back then. When connected to my VPN provider via my router, trying to start a Firefox Flatpak instance takes minutes upon minutes to load. I'm guessing it has to do with DNS query's Firefox does on start but I'm not sure. All I know is that when I connect directly to the internet without being hehind my VPN, Firefox loads in a split second. When I'm using the RPM version of Firefox supplied by Fedora, I do not have such issues even when connected to my VPN. This issue only affects Firefox Flatpak when behind a VPN. I tried opening the AppImage version of Firefox while connected to my VPN, and once again, it loaded within a few seconds. I been having this issue for many years and only figured out recently that my VPN connection was causing a problem. I would like to point out that the Flatpak verion of Microsoft Edge and Chromium do start without any issues even while I'm connected to my VPN provider...

Gekose oplossing

I found the problem. One of my VPN router's was causing the issue!!... The problem is now resolved.

Thank You.

Lees dié antwoord in konteks 👍 1

All Replies (5)

more options

So it's not a Mozilla browser issue right?

Gewysig op deur jonzn4SUSE

more options

Hello jonzn4SUSE,

I have no idea what causes the problem, all I know is that I been having this issue for many years and I'm getting tired of it. I would like to use Firefox as a Flatpak on my Linux distro, Fedora in this case and doing so while connected to my VPN...

I'm not a technical expert, I found a bug and I'm only looking for someone who might be able to help and solve the issue once and for all.

Regards.

MR

more options

Hi MR!

As this seems like a clear cut enough issue, I'd recommend filing this as a bug in Bugzilla directly.

Regards, Balázs

more options

Gekose oplossing

I found the problem. One of my VPN router's was causing the issue!!... The problem is now resolved.

Thank You.