Thanks for stepping in there. That simple change was all it needed. Obvious when you look at it.
Are there any other security or performance improvements you’d suggest?
Thanks to you and also to Anav for the previous help.
Darren.
Thanks for stepping in there. That simple change was all it needed. Obvious when you look at it.
Are there any other security or performance improvements you’d suggest?
Thanks to you and also to Anav for the previous help.
Darren.
One tip, order of rules matters. So if you look at filter rules in input chain (in 10Jun.rsc), #6-8 are useless, because #9 would drop matching packets anyway. It’s not the rules themselves, but their position. Correct order would be:
1, 6, 5, 7, 2, 3, 4, 9 (8 is useless)
Last rule in forward chain is useless too, because nothing will ever get to it through the unconditional drop before it.
Thanks again for your help. I made the changes you proposed and they seemed to work fine. I didn’t notice any real-world impact either way - perhaps because I don’t really stress the system.
Can you explain why that change in order might have an impact? I’m interested for my own education.
Order of rules matters, because router goes through them from top and checks if conditions match for current packet. If they do, then that rule is used and all following ones are skipped.
Some changes make functional difference. For example, the rule that blocks packets from internet that have non-public source addresses, if you have it after rule that accepts Wireguard packets, then it’s pointless, because WG rule will accept even packets with non-public source. Same for dropping packets with invalid connection state, you don’t want them at all (usually), so you need to deal with them before some other rule accepts them.
Other changes can help with performance. The idea is to process majority of packets as soon as possible, i.e. the lower number or rules that have to be checked, the better. That’s why accepting established and related is first, because it’s what vast majority of packets are. As for new connections (after you dealt with established, related and invalid), most of them will be from LAN (definitely more than e.g. new WG connections), so you want that near top.
Performance wise, you won’t really see any difference with just few rules like you have, but it’s still good to know about it. Maybe one day you’ll need firewall with thousand rules, and then it will matter.