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.