dns_proxy.go: Include 192.0.0.0/24 in private addresses?

[wildy]

Hi there.

We have a macOS 25 client running (at the time) ctrld 1.5.2. When the client connected to one particular iPhone hotspot, DNS resolution stopped working.

I tracked this down to this particular cellular carrier (Freenet Germany, https://www.freenet.de/) using 464XLAT. Freenet uses 192.0.0.0/24 for the IPv4 range that is passed to macOS CLAT, and this is not a standard RFC1918 address (it's RFC5736 - IANA IPv4 Special Purpose Address Registry).

With such a setup, ctrld might see requests coming in from the local host running the CLAT, using a source address of 192.0.0.2 (for example), which ctrld would consider a WAN request, according to the address selection logic at cmd/cli/dns_proxy.go:1132.

Workaround: explicitly set DNS to 127.0.0.1 for the affected hotspot connection, or change the ctrld config (either allow_wan_clients or set up a dedicated network for 192.0.0.0/24.)

Sadly, this is not the first time I see testing IP ranges abused for such purposes (I wonder why wouldn't they use the RFC6598 Shared Address Space?)

[cuonglm]

Thanks for reporting.

We already special-cases CGNAT, so including 464XLAT range is feasible.

[wildy]

@cuonglm Keep in mind that it's not a 'special-case for 464XLAT', it's just non-intended use of a reserved prefix.
From my understanding, the CLAT address range might be anything.

For example, my quick RFC search yielded this (https://www.ietf.org/archive/id/draft-ietf-v6ops-claton-00.html#name-clat-ipv4-addresses):

"In the latter case, the CLAT instance needs a single IPv6 and a single IPv4 address only. The node providing CLAT functions to local applications SHOULD use IPv4 addresses from the dedicated 192.0.0.0/29 range ([RFC7335]), reserved for IPv4 continuity solutions including but not limited to 464XLAT."

So maybe it would make sense to include 192.0.0.0/29 for now.

[cuonglm]

@wildy The fix is included in dev version, you can try by running:

ctrld upgrade dev