Firefox is unable to load any webpage ("An error occurred during a connection to www.google.com. ") while Chromium is unable to load some webpages (https://login.tailscale.com/ is unreachable. ERR_ADDRESS_UNREACHABLE). Firefox, when launched in safe mode, behaves the same as Chromium, but following regular trouleshooting steps like disabling all extensions is insufficient to make it work like that in the regular mode with me logged in. I can isolate with CLI tools something like what I see in Chromium:
This issue is something I’ve spent hours trying to diagnose, but I think it’s best to start anew with none of my misunderstandings and assumptions in the mix. I will appreciate any advice on how to get more information to track down the problem to its root. Here’s a configuration.nix that’s sufficient to reproduce this on my machine.
You get “network unreachable” when connecting to a domain with AAAA records, meaning your IPv6 connection is broken. My guess is that either your router is handing out unique local addresses that are somehow treated as global and/or you’re missing a default route to the IPv6 internet.
That seems to be the right track. ip -6 route show gives me nothing. How do I make sure that my router isn’t misbehaving? What could other devices on this network be doing to be able to function just fine? I looked in my router/modem settings and it has an empty field for the default ipv6 gateway and ipv6 dns server. Concerning. sudo radvdump doesn’t print any advertisements
so apparently my network just doesn’t have functioning ipv6 based on checking an ipv6 test website on my phone too. Nevertheless my phone has access to login.tailscale.com without any problems. I’ve turned off ipv6 again with networking.enableIPv6 = false; and it still tries to use ipv6 addresses when I wget login.tailscale.com. More interesting observations, wget -4 login.tailscale.com works fine. I think the mystery is this: why does my system
use ipv6 addresses when I wget login.tailscale.com
show ipv6 addresses after a fresh boot with ipv6 disabled even after sudo nmcli general reload which should clear dns cache I think at the end of the output of nslookup login.tailscale.com
$ ip -6 addr show
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 state UNKNOWN qlen 1000
inet6 ::1/128 scope host proto kernel_lo
valid_lft forever preferred_lft forever
2: enp5s0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 state UP qlen 1000
inet6 fe80::9e5d:f410:3c85:ebe5/64 scope link noprefixroute
valid_lft forever preferred_lft forever
Huh, the router doesn’t list any dhcp v6 leases, the table for that is empty, unlike the ipv4 one… is that normal? Ipv6 itself is allowed on it, but not on the DSL interfaces or PPPoE/PTM/ATM.
I have previously been able to reduce the configuration to a tiny .nix file which I have linked at the top of the thread. There’s nothing of note in there, so no VPN
It is normal to have a router correctly know that ISP does not provide an IPv6 address to you. It is also normal to establish a link-local no-global-routing IPv6 address for the interface without anything from the router. (It is not normal to not try IPv4 when there is not IPv6 route, of course).
If you manually remove the address from the interface (ip -6 a flush dev enp5s0), does anything change in either of the browsers?
$ ip -6 addr show
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 state UNKNOWN qlen 1000
inet6 ::1/128 scope host proto kernel_lo
valid_lft forever preferred_lft forever
2: enp5s0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 state UP qlen 1000
inet6 fe80::9e5d:f410:3c85:ebe5/64 scope link noprefixroute
valid_lft forever preferred_lft forever
This rules out the stray ULA/GUA IPv6 address hypothesis: you only have link-local addresses (normal).
Puzzlingly, today, “everything” started working in a way it hadn’t in months, both browsers. It’s possible that networking.networkmanager.dns = "none"; helped but only after a restart, I don’t remember what my last actions exactly were. curl -Ivv http://login.tailscale.com log reveals that the first set of IPs tried are ipv6 and they all have to fail until the ipv4 is tried which succeeds: curl -Ivv http://login.tailscale.com · GitHub
This isn’t unlikely, restarting just Firefox may have helped. IME it internally caches resolved DNS in addition to whatever DNS the system may have configured. Perhaps whatever DNS server your router has configured returns IPv6 addresses, maybe for some login portal you cannot actually reach or such?
It’s not weird: if there are both A and AAAA records both will show up. Applications should implement happy eyeballs: so they try both, generally preferring IPv6, but falling back to IPv4 if it fails to connect.