Basic requirment is to block all internet access to the LAN while still allowing LAN devices acccess to the internet.
Could anyone suggest changes to these rules to make them even simpler, less lines, better order, and theoretically less CPU utlization while still satisifying the basic requirment?
chain=forward action=drop comment="DROP ALL INVALID FORWARD" connection-state=invalid
chain=forward action=fasttrack-connection comment="SPEED UP ESTABLISHED FORWARD" hw-offload=yes connection-state=established log=no log-prefix=""
chain=forward action=drop comment="DROP ALL NEW FORWARD FROM INTERNET" connection-state=new,related,untracked in-interface=WAN
chain=input action=drop comment="DROP ALL INVALID INPUT" connection-state=invalid
chain=input action=drop comment="DROP ALL INPUT FROM INTERNET" in-interface=WAN
Re: Optimized firewall rules thought experiment
Default rules will prefend any access from the Internet to the internal network.
What I like to do is end both input and forward chain with a rule dropping everything else (first make sure that anything you like to do is allowed).
What I like to do is end both input and forward chain with a rule dropping everything else (first make sure that anything you like to do is allowed).
Re: Optimized firewall rules thought experiment
As mentioned by @pe1chl, default firewall is both quite secure and quite high performance. These two goals are slightly orthogonal. Your firewall for chain=forward might be highly secure, the following will be slightly better performer (at quick glance I can't say if it's equally secure or slightly worse):Basic requirment is to block all internet access to the LAN while still allowing LAN devices acccess to the internet.
Code: Select all
chain=forward action=fasttrack-connection comment="SPEED UP ESTABLISHED AND RELATED FORWARD" hw-offload=yes connection-state=established,related log=no log-prefix=""
chain=forward action=accept comment="ACCEPT ESTABLISHED AND RELATED FORWARD" hw-offload=yes connection-state=established,related log=no log-prefix=""
chain=forward action=drop comment="DROP ALL INVALID FORWARD" connection-state=invalid
chain=forward action=drop comment="DROP ALL NEW FORWARD FROM INTERNET" in-interface=WAN
Key points:
- action=fasttrack-connection simply marks connection for fasttrack (similarly to action=passthrough), but doesn't accept particular packet. So you really need rule with similar/same selection criteria that accepts packet.
- Keep in mind that firewall rules are evaluated from top to bottom for each eligible packet[+] until matched rule is executed. So if you have "drop invalid" as first rule while in normal operations invalid packets are only a tiny fraction, you'll waste CPU cycles for nothing. In case when somebody tries to hack you by sending invalid packets performance claim obviously reverts. However, using stateful firewall for fighting DDoS attacks is very inefficient way anyhow.
[+]packets belonging to fasttracked connections (other than first one and few every now and then) won't go through firewall filter rules. - If fasttracking is enabled (and active), only very few packets will ever get processed by firewall filters. Meaning that instead of optimizing performance to the last bit it's better to focus on security.
If, OTOH, one uses firewall in a way that doesn't allow fasttracking (e.g. due to use of mangle filters), then performance aspect of rules is very important. So again, keep in mind that rules are evaluated from top to bottom and you should push rules that handle more packets higher on the list.
While keeping security aspects in your mind ... which means you should still keep the "drop invalid" rule higher than any of accept rules that handle new connections (you don't have any explicit ones in your example).
All in all, your firewall filter list works ... in a pretty rare case where no connections from WAN are ever let into LAN (i.e. no DST-NAT in typical SOHO case).
Re: Optimized firewall rules thought experiment
chain=forward action=fasttrack-connection comment="SPEED UP ESTABLISHED AND RELATED FORWARD" hw-offload=yes connection-state=established,related log=no log-prefix=""
chain=forward action=accept comment="ACCEPT ESTABLISHED AND RELATED FORWARD" hw-offload=yes connection-state=established,related log=no log-prefix=""
chain=forward action=drop comment="DROP ALL INVALID FORWARD" connection-state=invalid
chain=forward action=accept in-interface-list=LAN out-interface-list=WAN ( clear requirement )
chain=forward action= drop Comment="drop all else" ( clear requirement )
This is better than MKXs version by a mile, or 1 kilometre, europeans dont quite go far enough LOL.
chain=forward action=accept comment="ACCEPT ESTABLISHED AND RELATED FORWARD" hw-offload=yes connection-state=established,related log=no log-prefix=""
chain=forward action=drop comment="DROP ALL INVALID FORWARD" connection-state=invalid
chain=forward action=accept in-interface-list=LAN out-interface-list=WAN ( clear requirement )
chain=forward action= drop Comment="drop all else" ( clear requirement )
This is better than MKXs version by a mile, or 1 kilometre, europeans dont quite go far enough LOL.
Re: Optimized firewall rules thought experiment
This is great thank you!
I noticed anav and MKX you left out the INPUT chains... was that intentional? Even the default firewall has lines for invalid and new INPUTS, is there any risk not calling out INPUTS?
The main difference between both MKX and anav's scripts are the last 2 lines... wouldent MKX's script be higher performance as it uses 1 less check... but anav's is likely more secure:
MKX
chain=forward action=drop comment="DROP ALL NEW FORWARD FROM INTERNET" in-interface=WAN
anav
chain=forward action=accept in-interface-list=LAN out-interface-list=WAN ( clear requirement )
chain=forward action= drop Comment="drop all else" ( clear requirement )
I noticed anav and MKX you left out the INPUT chains... was that intentional? Even the default firewall has lines for invalid and new INPUTS, is there any risk not calling out INPUTS?
The main difference between both MKX and anav's scripts are the last 2 lines... wouldent MKX's script be higher performance as it uses 1 less check... but anav's is likely more secure:
MKX
chain=forward action=drop comment="DROP ALL NEW FORWARD FROM INTERNET" in-interface=WAN
anav
chain=forward action=accept in-interface-list=LAN out-interface-list=WAN ( clear requirement )
chain=forward action= drop Comment="drop all else" ( clear requirement )
Re: Optimized firewall rules thought experiment
I prefer drop all rules at the end of the input chain and forward chain so its
necessary default Rules + Allow traffic rules + drop all else.
Its a simple formula whereby any reader of the config can quickly understand clearly what is permitted traffic.
One is not better (by any large measure) than another its often dependent upon what one is comfortable with.
viewtopic.php?t=180838
necessary default Rules + Allow traffic rules + drop all else.
Its a simple formula whereby any reader of the config can quickly understand clearly what is permitted traffic.
One is not better (by any large measure) than another its often dependent upon what one is comfortable with.
viewtopic.php?t=180838
Last edited by anav on Sat Jan 07, 2023 6:52 pm, edited 1 time in total.
Re: Optimized firewall rules thought experiment
Thank you, and excelent guide too.
Last edited by BartoszP on Sat Jan 07, 2023 6:13 pm, edited 1 time in total.
Reason: removed excessive quotting of preceding post; be wise, quote smart. lines of quote, 1 line of post.
Reason: removed excessive quotting of preceding post; be wise, quote smart. lines of quote, 1 line of post.
Re: Optimized firewall rules thought experiment
I noticed anav and MKX you left out the INPUT chains... was that intentional?
Well ... title of this topic says "optimized". You didn't say what exactly you're trying to optimize (performance or security), from rules you presented in opening post I understand you're mostly after performance.
Input chains are about traffic targeting router itself and that's minor part of traffic so optimizations in this part have lesser overall effect. But then, same concepts apply both for input and forward chains.
At the end of the day, firewall optmizations for performance (slightly) contradict optimizations for security. And it's up to firewall admin to decide which is more important.
IMO default firewall setup is pretty well optimized for both speed and security. When one starts to depart from defaults, parts of defaults shoukd be changed (e.g. the part mentioned by @anav about repkacing the last rule with two) ... if not for other things for readability (which is important part of security - reduces probability of introducing incorrect rules).
Your rules don't hughely depart from default (apart from reducing flexibility which in real life might bite your back), so I honestly don't see any point in this thread anyways. You might get 10% better performance as compared to defaults ... and this is probably a generous approximation. If you will have to introduce additional rules later on (e.g. because you decide you need DST-NAT after all), you'll loose whatever performance gains, possibly loosing even more if your additional rules won't be as witty as those in default firewall.
Re: Optimized firewall rules thought experiment
@Anav
Can you please explain why it is not possible to access LAN internal resources using L2TP vpn connection if your method is used -
Input Chai=drop All
Forward chain=drop All
If I specify In Interface= Wan in both chains, then everything is okay, you can access internal resources, everything pings, etc.
Thank you!
Can you please explain why it is not possible to access LAN internal resources using L2TP vpn connection if your method is used -
Input Chai=drop All
Forward chain=drop All
If I specify In Interface= Wan in both chains, then everything is okay, you can access internal resources, everything pings, etc.
Thank you!
You do not have the required permissions to view the files attached to this post.
Re: Optimized firewall rules thought experiment
Most firewall rule properties are selectors ... and in order for rule to execute, all of selectors have to match.
Now, if you alter the "drop all" rule to match against in-interface, it becomes selective and doesn't drop packets from l2tp interface. And keep in mind that any packet "surviving" all firewall rules will be accepted. At the same time, the "WAN" (as in: in-interface-list=WAN) is not something magical, it's (manually managed!) interface list, accidentally named "WAN".
If you'd follow @anav's concept of "drop all", you absolutrly shoukd not alter the last rule. Instead you should add another rule, which will accept specific connections (e.g. with in-interface=l2tp) and place that rule above the (ultimate) drop all rule.
Now, if you alter the "drop all" rule to match against in-interface, it becomes selective and doesn't drop packets from l2tp interface. And keep in mind that any packet "surviving" all firewall rules will be accepted. At the same time, the "WAN" (as in: in-interface-list=WAN) is not something magical, it's (manually managed!) interface list, accidentally named "WAN".
If you'd follow @anav's concept of "drop all", you absolutrly shoukd not alter the last rule. Instead you should add another rule, which will accept specific connections (e.g. with in-interface=l2tp) and place that rule above the (ultimate) drop all rule.