I normally don’t use Firefox very often but wanted to give it a try again. My usual default browser would be Vivaldi (which is unfortunately Chrome based). Anyway I usually have turned on my NordVPN system wide (Windows 10 Edu V. 22H2), which works fine on Vivaldi. I turns out it does have a weird side effect on Firefox. The DNS resolution for “google.com” just doesn’t work anymore. Any http request runs into a timeout. Strangely it works on any other google domain like google.de or google.org, also I couldn’t find any other domain to reproduce this behavior. Now this wouldn’t be such a big deal if google’s reCaptcha wouldn’t also be used by a lot of webpages and the api is hosted on google.com so basically the reCaptcha box just never appears and I’m stuck on those pages.

I tested it with v. 123.0 (64-bit), in private mode, in safe mode, FF portable 115.8.0 ESR and it is all the same strange behavior.

NordVPN also does have a FireFox Extension and using this extension everything works again.

Also tested it with the FF MacOS version and NordVPN client, here it works.

I can’t really explain this behavior other than some weird Firefox behavior together with NordVPN or some interaction with the Windows 10 vpn layer.

Can someone confirm this behavior on Windows? I assume other VPN providers like Mozilla VPN don’t have this?

[Update]: Forgive me it was late yesterday. I still can’t explain the behavior exactly but for sure the reason is the split tunneling feature of NordVPN. I had it enabled as I only wanted certain apps to go through the VPN and Firefox wasn’t on that list. So actually the NordVPN client should have treated FF routed through my default system connection and FF should just not have been routed through the VPN. Now it is more likely that it is some split tunneling bug that for whatever reason the google.com requests are treated differently by NordVPN/FF and are kind of blocked on my side or wrongly routed and never reach the google server.

[Update2]: As @LucidBoi@lemmy.world noted in the comments, the problem is not only related to Firefox and therefore wrong in this community. It actually also works on other browsers as well. It seems to be a problem of the windows NordVPN client and/or Windows 10. As soon as you use the split tunneling feature and exclude a browser from it, suddenly google.com doesn’t work anymore. Very strange, but that’s it. Actually for Firefox you should just use the NordVPN add-on anyway as it gives you a lot of flexibility to use split tunneling per domain, which actually works also for google.com then.

  • cereals
    link
    fedilink
    arrow-up
    12
    ·
    9 months ago

    Are you sure this is a DNS issue? If google.com can’t be resolved it shouldn’t run into a timeout. It should display an error message that google.com can’t be resolved pretty much instantly.

    • pwalker@discuss.tchncs.deOP
      link
      fedilink
      arrow-up
      1
      arrow-down
      1
      ·
      edit-2
      9 months ago

      No I am not sure, I don’t really see any error message, just a timeout. Not sure how an error of the DNS resolver looks like compared to any error caused by a timeout. However the DNS resolution should indeed be returning a different error, at least when entering a random non existing URL Firefox returns “server not found” instead of “problem loading page”(and NS_ERROR_NET_TIMEOUT in network debugging consoel). But what else could it be? It is so strange that the combination of Firefox and NordVPN extension does work, so it seems that the routing through the vpn network generally works, so it actually has to be something with the windows client interaction I guess.

      • Galli [comrade/them]@hexbear.net
        link
        fedilink
        English
        arrow-up
        1
        ·
        9 months ago

        best guess is the vpn endpoint is blacklisted by google.com with the requests being ignored instead of serving you with a 403 as some sites might. The other geographic google tlds I assume are operating separate blacklists.

        • pwalker@discuss.tchncs.deOP
          link
          fedilink
          arrow-up
          1
          ·
          9 months ago

          See my update in the post, now everything makes a little more sense and it is for sure related to the split tunneling feature.