PSA: ERR_ADDRESS_UNREACHABLE on GrapheneOS for some hosts

mtukl

Hi to you all,

this post is just here to help anyone who might encounter this problem as well.
The other day, I wanted to look something up when connected to my home WiFi, but the browser just threw "ERR_ADDRESS_UNREACHABLE" for any website EXCEPT some, Google and YouTube, for example. That was very, very strange. When leaving the WiFi, the Internet works perfectly fine. The router uses DHCP.

I tracked the issue down to the following: having a bad connection to the router, I often needed to re-connect to my WiFi. Having per-connection MAC randomization turned on, my router assigned a new IPv4 address every single time I reconnected, as it thought my smartphone with GrapheneOS on it was yet another new device. This made it run out of IPv4 addresses to assign, giving me an IPv6 instead. Apparently, some websites or DNS providers are unable to treat this behavior correctly, resulting in system updates, app updates, Signal, browsing etc. breaking.

How to fix:

log in to your WiFi router and navigate to DHCP configuration. Increase the IPv4 address room to a slightly higher number, just to temporarily give it some breathing room.
then, turn off per-connection MAC randomization for your home WiFi (as you can hopefully trust it), rather use per-network MAC randomization, DO NOT USE THE DEVICE'S MAC ADDRESS.
remove the loads of devices that have been created erroneously, or at least some of them, they will likely get removed automatically after some time.
re-connect affected devices

If you do not have access to the UI of your router, you can simply wait for a few days as the built-in DHCP server of your router will likely remove the unused addresses and make them available again.

Hope that helps! :)

de0u

mtukl If you do not have access to the UI of your router, you can simply wait for a few days as the built-in DHCP server of your router will likely remove the unused addresses and make them available again.

Power-cycling the router will often clear old leases.

GrapheneOS

mtukl Some routers are buggy and lack the ability to clear inactive devices from their DHCP lease table to free up room for new devices. Per-connection MAC randomization should always work fine but these buggy routers exist. You can usually clear the DHCP lease table in the router UI to work around it. Using per-network persistent random MAC is nearly harmless for a non-moving access point in your own home. Worth noting that Wi-Fi MAC addresses are visible to everyone nearby, not only to the router, but your router is always in the same place so it doesn't reveal much that a device with the same MAC access often connects in the same general location.

mtukl

de0u Another good fix, but it didn't work in my case unfortunately...

pitgorg

Hello everyone, I think I have understood the problem and was able to solve it on the router. Thanks mtukl for the solution. But I still can't understand why the problem only occurs with grapheneos and not with the other android, ios, linux, mac and windows etc. Maybe someone can enlighten me!

mtukl

pitgorg Hey there, glad to hear it worked for you!

The answer on why this only occurs on GrapheneOS is simple: the OS employs an even stronger privacy protection mechanism (per-connection randomized MAC address) which leads to the router believing that each time you connect to it, a completely new device joined the network. The router will assign a new IP address to your device each time it connects.

After some time, it'll run out of IPs to assign and fail to connect you properly. In other words, the DHCP table is full then.

Other operating systems only generate one single randomized MAC per network, but not for each time you connect to it. This reduces security, but improves comfort for such routers with a bad implementation of their DHCP handling.

Hope this helps!

GrapheneOS

mtukl Routers unable to handle this are very broken and wouldn't even be able to handle being used in a small coffee shop. It shouldn't be common but unfortunately there are still routers doing it wrong. All they need to do is clear the least recently used entry when they run out of slots.

BewareTheGlowies

GrapheneOS

Routers are not necessarily misbehaving, as most home-use routers default to very long DHCP lease times to ensure consistent IP serving—a common practice that is, like everything, debatable. This may be due to factors like NAT connection tracking and the need to avoid excessive CPU loads on cheap processors (although DHCP does have mechanisms to renew leases for existing devices). MikroTik routers, for instance, default to 8 or 12-hour lease times IIRC. And this is just for DHCP alone, forgetting completely about the ARP table, with which DHCP should work closely.

A coffee shop owner or its technician would likely know to configure the router properly for high-turnover environments. However, if you're a home user with several devices—especially those from Apple, Xiaomi, and Pixel with GrapheneOS, all of which perform MAC randomization—things can go south quickly, particularly if you're using the common /24 subnet.

pitgorg

Thanks mtukl and GrapheneOS for the answers and explanations. I found the settings in grapheneOS. However, I do not want to change these for security reasons. So I have to delete the MAC tables for unused devices regularly. That will work for now. Do you know if you can automate this in a FritzBox 7590? I haven't found anything yet. I also don't want to set up my own DHCP server next to it....

Thanks and best regards

GrapheneOS

BewareTheGlowies They should be smart enough to remove the least recently used DHCP leases if they aren't explicitly set as reserved in the configuration. The lease time shouldn't matter. They should handle twenty devices reconnecting every 10 seconds for days without a problem. If they don't, a single user can break things even by accident due to a bug, etc.

BewareTheGlowies

GrapheneOS

Just a friendly reminder that DHCP RFCs came out long before MAC randomization on devices was a thing. And yes, the problem is with lease time and the inability to otherwise fingerprint connected devices, because as far as I know, most home-end router DHCP servers don't have any other way to track who is who if not for the MAC address. After googling a little, there are things like DHCP fingerprinting which seem to rely on DHCP Options which, again, for home-end routers and typical ISP routers are very exotic features.

Hell, I've seen lots of D-Link, Dell, Linksys, Netgear... unmanaged switches fail to keep up with their own MAC tables and need a reboot. (though are not the same as DHCP lease table but I think you'll get the point)

Maybe someone more experienced than me can confirm, but things on networks can go bad real quickly.

de0u

BewareTheGlowies Just a friendly reminder that DHCP RFCs came out long before MAC randomization on devices was a thing.

That is true, but then the question is what they said. Here is some text from the first DHCP RFC, 1531 (October 1993):

In some environments it will be necessary to reassign network addresses due to exhaustion of available addresses. In such environments, the allocation mechanism will reuse addresses whose lease has expired. The server should use whatever information is available in the configuration information repository to choose an address to reuse. For example, the server may choose the least recently assigned address. As a consistency check, the allocation mechanism may probe the reused address, e.g., with an ICMP echo request, before allocating the address, and the client will probe the newly received address, e.g., with ARP.

The DHCP server picks the lease times to issue, so it can issue short leases to first-time visitors (or all visitors).

MAC randomization isn't different in effect than a transient population such as what a coffee shop or airport sees. Issuing short leases and recycling addresses are things a DHCP server should be prepared to do in a wireless era.