>> > Running a non-exit Tor relay on Linux and have iptables set up to block >> > inbound and outbound RFC1918 addresses on the outside interface. Notice in >> > the firewall logs several seemingly random private IP addresses connection >> > attempts to my relay port getting dropped on the outside over the past few >> > months. The MAC address associated with these matches my ISP's default >> > gateway. >> > >> > Does Tor do some type of loopback on the outside int.? Or is my ISP doing >> > something peculiar with NAT?
Regarding RFC1918 observations... ISP's with clue are supposed to do reverse path filtering on their customer connections (src), and not route 1918 space beyond their borders (dst). It is more likely to see 1918 space in src addresses on the net because some ISP somewhere forgot RPF. And common to see 1918 in dst addresses if you're hosted in some amateur datacenter that hasn't figured out VLAN's. Most ISP's and transits with clue block it all as well as a bunch of other nonsensical bogons. Just block all inbound 1918 packets (whether it's in src and/or dst), and everything not addressed to you via the wan interface. And make sure you're not leaking your own 1918 space to your provider. Special care of your modem/bridge management and any dhcp may be needed. >> Assuming it's my ISP, is there any way to configure my relay to discourage >> clients in my AS from using it as an entry point? > > Could you say more about why you would want to do that? I ask because > this increases those clients' risk from an AS-level attacker by > mandating an increase in the number of ASes that must be traversed > between client and entry node. / Conversely, entering through a relay in your own AS means that somebody / can definitely see all of your traffic and all of your entry node's / traffic. Is that really better? It's still encrypted traffic, not plaintext. Your cable/dsl operator AS has no interest in being a passive adversary itself. Though it may partner with an actual PA who can see beyond just that AS anyways. _______________________________________________ tor-talk mailing list [email protected] https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk
