I have recently finally put my IPFire-Firwall into operation, and I want to replace my TOR-Relay, which at the moment doesn’t work either (other story).
So I installed the TOR addon and configured it as a “relay only” with its own relay port and directory port. ( It is not the default ports of TOR).
Tor also seems to work so far. At least I can find my relay on metrics.torproject.org. But with an extremely bad offered bandwidth.
In the firewall log I can find a lot of DROP_NEWNOTSYN messages on the relay port. It is quite unlikely that these requests are actually due to previous use of my public IP. (As I said, it is not the default port).
Now to my question: Do I also have to set up a firewall rule to ignore the “not SYN rule” on the port? Finally, is it the desired behavior that relays are addressed from the outside, without, or did I see it wrong?
Unfortunately I can’t help you as I never run a tor relay. The reason I am replying is to ask a naive question. Are you sure is it a good idea to run a tor relay on your firewall? Would not be better to use a dedicated machine for that, like your previous setting?
I am submitting to you the possibility of framing your network differently. The firewall should be dedicated to keep your network secure and therefore have the smallest surface of attack possible. Just filtering and routing packets, with the possible exception of squid proxy server and VPN, as they are tightly integrated in the security model of IPFire. Everything else should be running behind the firewall in a separate machine (virtual or physical).
Regardless, keep in mind that IPFire might also interfere with the tor traffic in several ways, e.g. the IP block lists or the intrusion prevention system.
Thank you for your advice. In general, you are absolutely right, and I also see the problem. But for me personally, in this case, the advantage of simplicity is more important.
Especially because I think, that the providing of a Tor relay is a thing that helps to keep my family safe. The relay is not only addressed from the outside, but also used by my own devices (both from inside the LAN, as well as from outside) as an entry node.
I understand. I wish I could give you a suggestion, but I cannot.
I would consider simplifying IPFire as much as you can (no suricata, no ip filtering, ecc…) to see if all those broken packets are due to IPFire filtering activity. Maybe, and here I reveal all my ignorance, I would consider also whether the Reverse Path Filtering setting of IPFire to strict might be implicated.
Good hint, I’ll try it like this.
And, if this doesn’t bring any success, I think I’ll better open a new Topic, with just the question, how to deactivate the NewNotSync proof on a dedicated port.
DROP_NEWNOTSYN is a very common on connections with high latency like tor. If a client close a connection via RST there is a grace period that the packets drop without logging but the sender still send data after this time it will also logged. Usually you can save disabe the logging of DROP_NEWNOTSYN in the firewall options.