Add CGNAT 100.64.0.0/10 to Default Exit Relay Reject Policy
Hello, I've noticed that the non-publicly routable CGNAT subnet of 100.64.0.0/10 is not in the default exit policy reject list like 192.168/16 and 10/8 are. This range is not publicly routed, and should never need to be accessed from a Tor exit. Tailscale and other ISPs use this block. How many exit relays connected to a Tailscale network are unknowingly exposing all of their other Tailscale devices to the Tor network? ISPs may be less willing to allow exit relays if there are bots using Tor to toy with the ISPs 100.64/10 range. Maybe there is something I am missing for it to not be included? Thanks, Likogan.Dev
On Sun, 06 Jul 2025 19:13:36 +0000 admin--- via tor-relays <tor-relays@lists.torproject.org> wrote:
I've noticed that the non-publicly routable CGNAT subnet of 100.64.0.0/10 is not in the default exit policy reject list like 192.168/16 and 10/8 are. This range is not publicly routed, and should never need to be accessed from a Tor exit.
Sorry for the late answer, I noticed that this range has been added in tor_addr_is_internal_() now. Anyway, shouldn't TOR ExitPolicy reject all special IP ranges? See https://en.wikipedia.org/wiki/Reserved_IP_addresses DS-Lite (192.0.0.0/24) seems to be some kind of CG-nat too. Isn't 198.18.0.0/15 a private range, like RFC 1918? 224.0.0.0/4 and 255.255.255.255 should be probably be blocked too, as well as ff00::/8 I did not look deep into all the IPv6 special ranges. Currently reserved IP ranges are not routed but may be revived later and have security consequences My 2 ¢
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 Hello.
Isn't 198.18.0.0/15 a private range, like RFC 1918?
Its RFC 2544, which contains ranges reserved for internal benchmarking. The term here is "bogon". That is any address which should not be seen being routed on the public internet. This includes special-purpose addresses like CG-NAT and benchmarking addresses, as well as reserved addresses that have not been allocated.
Currently reserved IP ranges are not routed but may be revived later and have security consequences
In 2011, the IETF wrote RFC 6441 (BCP 171), in which they recommend that unallocated ranges should no longer be considered bogons due to the IPv4 exhaustion. Any range that are reserved for "eventual" public use should just be considered allocated. I don't believe Tor does any special filtering for bogons, only for certain local addresses in tor_addr_is_internal_(), specifically: fc00/7 fc80/10 fec0/10 ::/127 10/8 0/8 127/8 100.64/10 169.254/16 172.16/12 192.168/16 With special cases for binding to 0/32 and 100.64/10. See: https://bgpfilterguide.nlnog.net/guides/bogon_prefixes/ Regards, forest -----BEGIN PGP SIGNATURE----- iQIyBAEBCgAdFiEEvLrj6cuOL+I/KdxYBh18rEKN1gsFAmkwwC4ACgkQBh18rEKN 1gtb+w/46xOAPmcUzepMwJnqlXrLxwTMwK/NkrSbRJw+hTgO7u886vsYKZ9LykSg IBfUzawpe9xnnTS4APdb3cXeVYEpeI2yD2P4A9QLB61LD3NkFdJsEFgRA6jDi48V oojcfsd+3vQ4xFGKoi7CLSxFLP6vnxXclVRdN72heienQeQPoh8WmnIovrEqt2Z4 6WrbI6Cept6zvrUD83Q1YTFs4aKL9AQ9pjmGvnIIRDGAafk8xEr0CN9ugnuIYeNB nyh2t/sZZZyl+pSuEe4qRhNv8/ypMMUKAivt+QNYVs2pJqeSTir7+xWqCt1xavIV 3UjBkZkoGhsH06EoerzW9UgI5+mVCIRgHGzGlrXArsjgQVQSrjFadoDuMUd6LJu1 hjnt0HhDD27aod8coF4jI4tA2Qh4/4bWwVZlccWA1FQwXY9v/SLcJh1qOF9URcaO p/Lvgf8Z7SjBJWd1pXf0zo7xn/Orge4ossdNh7wjcEKNMT3efaNRwem6I5Eb8LMh ce7SIRMXQcR4CyEi9TKrc1fVDNB6agSaljhxisSRL7A84sd2TEMASpO6AJrAcqQJ FYWL/3qkFUQXv7inz2E4aig/qpyIrINk4ssI0GDAMcOOVD3cejtQnXWgnSHDerfr oU9W4xiuv13r4Gqe+b++1r8hmkZ7ADgYDm2drniLcW733irbJQ== =wq/m -----END PGP SIGNATURE-----
participants (3)
-
admin＠likogan.dev -
forest-relay-contact＠cryptolab.net -
vm666＠omniphobe.fr.eu.org