3 ms·

The biggest problem I'm having is that our edge firewall doesn't play nicely with it for some reason. I get these random websites that refuse to work in Firefox

The biggest problem I'm having is that our edge firewall doesn't play nicely with it for some reason. I get these random websites that refuse to work in Firefox, but they always work fine in Chrome. And it's not certificate errors, it's just "connection reset by peer". I'm not entirely sure how it's working, but I've seen a few other people with these issues at the mozilla bug tracker and it's always just sort of either ignored or dismissed or people say it's caused by antivirus (which I don't have). I can't figure out how to debug it because literally everything else I try works. curl/wget/etc. I asked IT about it and they just said that I should use Chrome. Firefox just gives a "connection reset by peer" error and literally nothing more. Changing the new firefox security settings has no effect. The exact same url put in chromium or chrome or curl or wget loads fine. I cannot find anything that doesn't work except firefox. So either the firewall is specifically targeting firefox for some (and only some) https sites or there's something going on in firefox. It's literally the only reason I'm considering not using firefox at this point. I've just got no idea what to do or how to debug this. Thankfully, most major sites work fine. But it's annoying when some website blocks off like this.

hannob 6y ago
> The biggest problem I'm having is that our edge firewall doesn't play nicely with it for some reason.[...] I'm not entirely sure how it's working, but I seen a few other people with these issues at the mozilla bug tracker and it's always just sort of either ignored or dismissed. This sounds like you have some expensive enterprise equipment that is doing funny things with your TLS connection, but instead of complaining to your enterprise vendor that you likely pay a lot of money to, you complain to an open source project that probably has nothing to do with it.
- fluidcruft 6y ago
  I mean that's fair, but it's really frustrating that for whatever reason all the other clients work. I just want to figure out what's going on and how the firewall knows to target firefox. Like I said IT's response is "well who cares just use Chrome".
  - nitrogen 6y ago
    Try comparing the packet conversation using Wireshark to see if Firefox is doing something different from Chrome.
    - capableweb 6y ago
      Someone please correct me if I'm wrong, but I do think Firefox ships their own root certificates with their browser, while Chrome uses the system ones. It's possible fluidcruft's employer has installed new root certificates so they can analyze/inspect the traffic through their network and Chrome is happily rolling along, while Firefox does not like it because now the connection effectively has been broken.
      - GekkePrutser 6y ago
        This is most likely exactly what's happening. On Windows you can choose to use the system store though. On other platforms you can only use the internal one
      - fluidcruft 6y ago
        I 'm pretty confident that shows up as a certificate error with it's own scare page, not connection reset. Usually on cert errors you can click through all the warnings and accept the risks to connect anyway. Connection reset is just a complete dead end. I have pondered whether there's some way for the firewall to have a whitelist of sites that it allows without SSL MITM and otherwise sends reset for unknown SSL sites unless the firewall's MITM certificates are used. Our IT might be paranoid enough to do that. I don't have any evidence that the firewall does any MITM other than I found it listed as a feature that can be configured on the firewall's website when I've been googling. But even then the error people complain about is bad cert not connection resets. I have tested with Chrome on systems that IT cannot have injected certificates into and they do work. I do know that I can access my home server's let's encrypt site using firefox and chrome without problems and the keys are correct. So it's not really high in my suspicion list. Anyway it looks like I need to learn how to packet sniff.
- random5634 6y ago
  Huh? If everything but one browser works, the suggestion will be to avoid using that browser unless you can show the expensive equip is doing something wrong. So firefox doing nothing more than a connection reset message does not help at all. A trouble ticket that says chrome works, wget works, curl works, IE works, but my firefox browser with 10 privacy plugins does not work - is NOT going to get a good response from you support contact.
  - parliament32 6y ago
    So, it sounds like FF is sending something that's causing an RST to be emitted from either the website or (more likely) your appliance. Next step would be to pcap/tcpdump a connection from both a working browser and FF, and see what the difference is. That kind of information is a lot more useful to FF devs than "something is happening that causes an RST from someone".
    - random5634 6y ago
      I was only partly joking about extensions. Definitely disable them all for this testing.
rincebrain 6y ago
Have you tried forcing QUIC on or SPDY off in Firefox to see if either of those options circumvents it?
- fluidcruft 6y ago
  No that's new to me. I'll look into it, thanks!
terramex 6y ago
I've had exactly the same issue for 2 years and I have narrowed it to dropped packets on the network. I'm connected to internet through WiFi bridge that periodically has transmission issues (over 200 meters distance) and if average amount of transmitted packets (I can see it in antenna panel) is anything else then 100% and negotiated speed is anything lower than maximum 54 Mbps then neither Safari nor Firefox will be reliable and I will get "connection reset by peer" error that will go away after refresh. Chromium-based browsers work fine, I'm using Vivaldi with no issues. On Windows tools like curl and wget work with no issues but not on macOS - it looks like a deeper problem with its network stack that Chromium browsers somehow avoid. It might be a correlation without casualization, but I also was unable to find a good way to debug this issue.
ohyeshedid 6y ago
I'm wondering if the tested Firefox install has enabled DoH?
- fluidcruft 6y ago
  Oh interesting. Firefox says it's both enabled and set to use 1.1.1.1, and I figured that nothing would resolve if it wasn't... but if https://1.1.1.1/help https://1.1.1.1/help is correct then it's not actually working and something else is happening. I know I tried setting and disabling that when I was testing but I saw no change. I don't remember setting 1.1.1.1 but I may have enabled DoH. I'll see if changing the DNS server in firefox to whatever everything else is using helps. Edit: It looks like Firefox just silently falls back to non-DoH system defaults if it's not working. Good to know, I guess. Not really sure what the point of DoH is if networks can just silently override the setting. > Mozilla has announced plans to enable DoH for all Firefox desktop users in the United States in 2019. DoH will be enabled for users in “fallback” mode. For example, if the domain name lookups that are using DoH fail for some reason, Firefox will fall back and use the default DNS configured by the operating system (OS) instead of displaying an error. https://support.mozilla.org/en-US/kb/firefox-dns-over-https https://support.mozilla.org/en-US/kb/firefox-dns-over-https
  - ohyeshedid 6y ago
    FWIW, I've only seen the issue you reported when resolving a Cloudflare hosted site through Cloudflare dns, with Firefox as the client. Refreshing multiple times seemed to work. I haven't had the time to investigate it when it occurred; anecdata. I have wondered if it's related to handing off from the CF balancer to the sites tls.
  - tialaramex 6y ago
    > Not really sure what the point of DoH is if networks can just silently override the setting. You can explicitly configure the browser to insist on DoH whereupon it's your fault if that doesn't work. But the defaults changed only to try to do DoH if they can. "If a user has chosen to manually enable DoH, the signal from the network will be ignored and the user’s preference will be honored."

hannob 6y ago

> The biggest problem I'm having is that our edge firewall doesn't play nicely with it for some reason.[...] I'm not entirely sure how it's working, but I seen a few other people with these issues at the mozilla bug tracker and it's always just sort of either ignored or dismissed. This sounds like you have some expensive enterprise equipment that is doing funny things with your TLS connection, but instead of complaining to your enterprise vendor that you likely pay a lot of money to, you complain to an open source project that probably has nothing to do with it.

fluidcruft 6y ago
I mean that's fair, but it's really frustrating that for whatever reason all the other clients work. I just want to figure out what's going on and how the firewall knows to target firefox. Like I said IT's response is "well who cares just use Chrome".
- nitrogen 6y ago
  Try comparing the packet conversation using Wireshark to see if Firefox is doing something different from Chrome.
  - capableweb 6y ago
    Someone please correct me if I'm wrong, but I do think Firefox ships their own root certificates with their browser, while Chrome uses the system ones. It's possible fluidcruft's employer has installed new root certificates so they can analyze/inspect the traffic through their network and Chrome is happily rolling along, while Firefox does not like it because now the connection effectively has been broken.
    - GekkePrutser 6y ago
      This is most likely exactly what's happening. On Windows you can choose to use the system store though. On other platforms you can only use the internal one
    - fluidcruft 6y ago
      I 'm pretty confident that shows up as a certificate error with it's own scare page, not connection reset. Usually on cert errors you can click through all the warnings and accept the risks to connect anyway. Connection reset is just a complete dead end. I have pondered whether there's some way for the firewall to have a whitelist of sites that it allows without SSL MITM and otherwise sends reset for unknown SSL sites unless the firewall's MITM certificates are used. Our IT might be paranoid enough to do that. I don't have any evidence that the firewall does any MITM other than I found it listed as a feature that can be configured on the firewall's website when I've been googling. But even then the error people complain about is bad cert not connection resets. I have tested with Chrome on systems that IT cannot have injected certificates into and they do work. I do know that I can access my home server's let's encrypt site using firefox and chrome without problems and the keys are correct. So it's not really high in my suspicion list. Anyway it looks like I need to learn how to packet sniff.
random5634 6y ago
Huh? If everything but one browser works, the suggestion will be to avoid using that browser unless you can show the expensive equip is doing something wrong. So firefox doing nothing more than a connection reset message does not help at all. A trouble ticket that says chrome works, wget works, curl works, IE works, but my firefox browser with 10 privacy plugins does not work - is NOT going to get a good response from you support contact.
- parliament32 6y ago
  So, it sounds like FF is sending something that's causing an RST to be emitted from either the website or (more likely) your appliance. Next step would be to pcap/tcpdump a connection from both a working browser and FF, and see what the difference is. That kind of information is a lot more useful to FF devs than "something is happening that causes an RST from someone".
  - random5634 6y ago
    I was only partly joking about extensions. Definitely disable them all for this testing.

rincebrain 6y ago

Have you tried forcing QUIC on or SPDY off in Firefox to see if either of those options circumvents it?

fluidcruft 6y ago
No that's new to me. I'll look into it, thanks!

terramex 6y ago

I've had exactly the same issue for 2 years and I have narrowed it to dropped packets on the network. I'm connected to internet through WiFi bridge that periodically has transmission issues (over 200 meters distance) and if average amount of transmitted packets (I can see it in antenna panel) is anything else then 100% and negotiated speed is anything lower than maximum 54 Mbps then neither Safari nor Firefox will be reliable and I will get "connection reset by peer" error that will go away after refresh. Chromium-based browsers work fine, I'm using Vivaldi with no issues. On Windows tools like curl and wget work with no issues but not on macOS - it looks like a deeper problem with its network stack that Chromium browsers somehow avoid. It might be a correlation without casualization, but I also was unable to find a good way to debug this issue.

ohyeshedid 6y ago

I'm wondering if the tested Firefox install has enabled DoH?

fluidcruft 6y ago
Oh interesting. Firefox says it's both enabled and set to use 1.1.1.1, and I figured that nothing would resolve if it wasn't... but if https://1.1.1.1/help https://1.1.1.1/help is correct then it's not actually working and something else is happening. I know I tried setting and disabling that when I was testing but I saw no change. I don't remember setting 1.1.1.1 but I may have enabled DoH. I'll see if changing the DNS server in firefox to whatever everything else is using helps. Edit: It looks like Firefox just silently falls back to non-DoH system defaults if it's not working. Good to know, I guess. Not really sure what the point of DoH is if networks can just silently override the setting. > Mozilla has announced plans to enable DoH for all Firefox desktop users in the United States in 2019. DoH will be enabled for users in “fallback” mode. For example, if the domain name lookups that are using DoH fail for some reason, Firefox will fall back and use the default DNS configured by the operating system (OS) instead of displaying an error. https://support.mozilla.org/en-US/kb/firefox-dns-over-https https://support.mozilla.org/en-US/kb/firefox-dns-over-https
- ohyeshedid 6y ago
  FWIW, I've only seen the issue you reported when resolving a Cloudflare hosted site through Cloudflare dns, with Firefox as the client. Refreshing multiple times seemed to work. I haven't had the time to investigate it when it occurred; anecdata. I have wondered if it's related to handing off from the CF balancer to the sites tls.
- tialaramex 6y ago
  > Not really sure what the point of DoH is if networks can just silently override the setting. You can explicitly configure the browser to insist on DoH whereupon it's your fault if that doesn't work. But the defaults changed only to try to do DoH if they can. "If a user has chosen to manually enable DoH, the signal from the network will be ignored and the user’s preference will be honored."