Tristan: yep, I was assuming a non-exit. Although sure, you can block incoming traffic without affecting outbound traffic with a stateful firewall like iptables.

That's my setup as well. My UFW looks like:

To Action From -- ------ ---- 80/tcp ALLOW Anywhere 443/tcp ALLOW Anywhere xxx/tcp ALLOW Anywhere

I have my DirPort set to 80 and ORPort on 443. The last line is my ssh port (I didn't want to broadcast it).

I also see the same type of blocked incoming packets. It's never been a problem. I think it's just the nature of the stateful firewall. Once connections are closed and no longer in the state table, additional packets are getting denied. That's my lazy/gut explanation, I don't have more time to think about it at the moment, but I don't think it's anything to worry about.

Hey Tristan,

Any ideas what in-addr.arp is

Yes, this is the standard format for reverse DNS lookups for IPv4 addresses.

I'm not sure what command(s) you were using, but in-addr.arpa is an expected result (or intermediate step) of doing something like "host 8.8.4.4" on Linux. The IP octets are reversed and appended to the domain suffix in-addr.arpa (ex: 4.4.8.8.in-addr.arpa for 8.8.4.4) to create a hostname. Then to continue the same example, the host tool finds a PTR record for that hostname (ex: google-public-dns-b.google.com). You can read more about this here:

https://en.wikipedia.org/wiki/Reverse_DNS_lookup https://tools.ietf.org/html/rfc2317

So... those in-addr.arpa references don't really tell you anything. It's just a distraction. My hunch is that the IP addresses in your log are going to be a random selection of IPv4 addresses from Tor clients and relays.

why the firewall would block it even on allowed ports?

I was trying to explain earlier but did a poor job. I don't have a specific explanation for Tor, but it's common to see the same behavior with denied packets to port 80 and 443 on a web server, even when there is a UFW (iptables) allow rule. It has to do with the state of the connection. There's an explanation for web servers and port 80 blocks here:

https://ubuntuforums.org/showthread.php?t=2138691 (see the 2nd post)

I am making an assumption that we're seeing the same behavior on the Tor ports. It would be good if someone with a better understanding of the protocols could confirm or deny the theory. I'm not 100% certain.

Green,

Thanks for the info. I used iptables once when setting up a VPN, but I just followed instructions. It's obviously way more intricate than UFW lets on.

Also thanks to Mike for the really good blog post about operational security. It was really informative.

On Aug 4, 2016 8:49 PM, "Green Dream" greendream848@gmail.com wrote:

P.S. Tristan, here's the explanation from that mailing list... just in case people can't access the link or it goes away:

"Yes, it has everything to do with those flag bits. For TCP connections, Linux tends to use a "half-duplex" close sequence where either side of the session can initiate connection termination via a single 2 way FIN-ACK handshake (which puts the connection into the CLOSE_WAIT state), instead of a full 4 way FIN-ACK handshake. When one also includes routers and such, it is not uncommon, indeed common, that one side might think the connection has been terminated, while the other side thinks it has still open or not fully terminated. Your log file is, most probably, showing entries for cases where your computer thinks the tcp had been closed and it has forgotten about it, but the client is trying to close the session. In the case where you got a RST bit, it can be because the client gave up trying the FIN method and now is just trying to reset the connection. By observation only, rather than authoritative reference, it seems that Apple computers tend to use FIN and FIN-ACK more, and MS windows computers tend to use RST more.

Conclusion: Everything is fine."

---

tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays