Score:0

¨Network is unreachable" for 104.72.131.10 (Discover.com) but works for 142.251.45.46 (Google.com) after changing to AT&T fiber

ci flag

I upgraded to AT&T Fiber from a DSL connection. Now, Ubuntu 22.04 (Jammy) cannot establish http or ping connections to many websites. I just gave one example. dig works fine for everything. So, DNS is good. GET google.com works fine (as do some others). GET discover.com has "network unreachable" as do many others.

A chromebook is working fine on the same router. A Windows box is working fine on the same router.

If I connect Ubuntu -> LAN side Google mesh router, Google mesh router WAN port -> AT&T Fiber router, it works. Whatever the Google (Nest) mesh router is doing in its NAT protocol fixes the problem.

A reboot did not fix the problem (nor did simply cycling the NIC with ip link set enp4s0 down/up).

Yahoo.com works too. Most sites are broken.

Ervan Darnell avatar
ci flag
Disabling IPV6 for the NIC in the "Settings/Network" applet got the system working again, but is not exactly a complete fix.
Score:0
cn flag

The way you describe it, especially with it working when you disable IPv6, it sounds like being related to the very old peering disputes between providers (these are not new, and I have not followed the development in recent years, but I can imagine they are still a thing).

I have found this workaround, which is of course also not a complete fix. Basically, you figure out which IPv6 prefixes are not being routed to the end destination (in the example from the link, these were all Cogent prefixes), and then disable routing for these prefixes, like this (copied from example above):

#!/bin/sh

for prefix in 2001:0550::/32 2001:067c:12e8::/48 2001:0978::/32 2607:9700::/32 2607:f298:000a::/48 2607:f5d8::/32 2610:00f8:2f00::/48 2610:00f8:2fed::/48 2620:009a:8000::/48 2620:00fb::/48 2620:00fb::/56
do
    ip -6 route add unreachable $prefix 2>/dev/null
done

exit 0

The correct fix (after you verify this is indeed the problem!) would be of course to complain to your provider and hope that eventually these disputes will be resolved for good. You can pinpoint the exact location of the problem by running:

mtr -n -6 <ipv6_address>

from your machine and from a machine that can reach the address (You can omit the -n of course, but I prefer to have the numeric addresses, and when figuring out where the problem is, find out the name by a whois <ipv6> query)

Now the next question is, why does Chromebook and Windows work on the same router. I can think of two possibilities here:

  • They have already IPv6 disabled for some reason.
  • They use a different DNS resolver (default resolver from your Fiber provider, and in your Ubuntu box you have set up some public resolver like 8.8.8.8), which may be configured to filter out IPv6 routes that it knows you can not reach. (A little far fetched, but possible).

The reason why it works if you use the Google mesh router should be similar, that router is probably not set up to give you a public IPv6 address, so basically it causes your network to have only a link local IPv6 address and not able to reach any public one, which makes all connections fall back to IPv4.

Ervan Darnell avatar
ci flag
This is great info. I came back to investigate a week later, and things were working, without disabling IPv6. That weakly confirms your theory about the ISP on the possibility that a new DHCP lease and/or strictly an update ISP side resolved it.
mangohost

Post an answer

Most people don’t grasp that asking a lot of questions unlocks learning and improves interpersonal bonding. In Alison’s studies, for example, though people could accurately recall how many questions had been asked in their conversations, they didn’t intuit the link between questions and liking. Across four studies, in which participants were engaged in conversations themselves or read transcripts of others’ conversations, people tended not to realize that question asking would influence—or had influenced—the level of amity between the conversationalists.