Posted: Sun Mar 21, 2010 19:18 Post subject: iptables rules optimization
Hi.
I was experimenting with eko's 13577 build for a WRT54GL (dd-wrt.v24-13577_NEWD_std-nokaid_nohotspot_nostor.bin) and I found out that some of the iptables rules could be better optimized by changing the order of certain rules. It might seem unimportant but the router's CPU isn't as powerful as one in a desktop PC and measuring the difference with iperf proved this. Interpreting and checking iptables rules uses CPU cycles
I strongly recommend moving the state RELATED,ESTABLISHED line to the first position in the FORWARD chain because if a connection already passed to the ESTABLISHED state it's not necessary to check each packet again for the same rules.
Also, the TCPMSS clamp line matches TCP SYN packets only which clearly can't be an ESTABLISHED state.
I've also made several tests with iperf to check how the transfer speed changes when I move the RELATED,ESTABLISHED rule to the first line in the chain.
Deleting the rule and inserting it as the first line:
Code:
iptables -D FORWARD -m state --state RELATED,ESTABLISHED -j ACCEPT
iptables -I FORWARD -m state --state RELATED,ESTABLISHED -j ACCEPT
Rule moved to first line:
[ ID] Interval Transfer Bandwidth
[164] 0.0-10.0 sec 66.3 MBytes 55.5 Mbits/sec
This test was made with iperf between 2 boxes on a 100 Mbps connection (different networks) and the router was doing NAT between them. The performance gain is caused by CPU needs to check less rules for the packets which are in the ESTABLISHED state.
I hope developers will consider changing the iptables rules' order in the factory default startup scripts. When the user or the UPnP daemon creates port forwarding rules they should also be created after the state RELATED,ESTABLISHED rule.
Last edited by Diosbejgli on Mon Mar 22, 2010 15:24; edited 1 time in total
Assuming that output is predictable, that's a nice little increase in thruput. Where did you gain such knowledge of iptables? Or were you just experimenting?
If your correct in the order and it doesn't break anything, submit your find to the DD-WRT Trac so it can be implemented.....or ignored. _________________ Eko Builds
I'm working with iptables for years and read through couple of documentation regarding these questions. Knowing how TCP is working and how a packet filter should handle its packets has nothing special to do with iptables anyway.
It certainly does not break anything because as you can see these are just ACCEPT rules, moving that rule to the first line will not drop anything. It just ensures that packets in already established flows to be accepted at the beginning and not wasting CPU cycles on the same rules for each packet.
There may be a fringe case that needs the TCPMSS above the RELATED/ESTABLISHED rule for urgent flagged out of band packets (they're part of that rule), although there are other rules above it which may break things in such a case and I'm not sure if such packets even need to be clamped...
Although it would be nice to have it higher up by default, I don't think it's realistic to expect it to stay there. There are many many guides that require inserting rules and they can't assume anything about the user's setup so they need to insert the rules at the top of the chain. The UPnP daemon could be rewritten to insert further down the chain, but then user inserted rules could still push the RELATED,ESTABLISHED rule below where UPnP inserts them.
I doubt the devs will want to restructure a bunch of code to try to keep it at the top. The most I would expect is that it might get moved higher by default, but more likely you'll just have to keep doing it yourself. _________________ Read the forum announcements thoroughly! Be cautious if you're inexperienced.
Available for paid consulting. (Don't PM about complicated setups otherwise)
Looking for bricks and spare routers to expand my collection. (not interested in G spec models)
Having a flow of packets in an ESTABLISHED state is usually the most often. That's why that rule should be at the first lines. Because we are not dropping anything there, it will not cause harm and the changed order only helps free up CPU cycles.
User portforward entries could be inserted to the second line with iptables -I 2 ...
UPnP could do the same. Anyway, having it at the top by default would be better.
That's why I asked for "iptables-restore format" instead of loading each rule with iptables command, but the devs doesn't seem interested in changing that. With "iptables-restore format" you don't need -I, because ruleset will be restored in sequence..
That's why I asked for "iptables-restore format" instead of loading each rule with iptables command, but the devs doesn't seem interested in changing that. With "iptables-restore format" you don't need -I, because ruleset will be restored in sequence..
You mean you asked for it to be included and it isn't? _________________ Eko Builds
I started a topic about it, requesting that "Save as firewall" would convert whatever is typed there to iptables-restore format, but low interest from forum users.. perhaps is not a good idea anyway.. but would be nice to have a "firewall file" so you can edit all in one
Joined: 24 Feb 2009 Posts: 2026 Location: Sol System > Earth > USA > Arkansas
Posted: Mon Mar 22, 2010 3:29 Post subject:
Hell, I am for anything that would improve the performance of the router in those cases. Since it will probably take a while to get this implemented (if it was even considered), what steps would need to be taken to make this happen on a default install (that possibly already has some firewall rules)?
Is it going to be as simple as placing the above listed commands:
Code:
iptables -D FORWARD -m state --state RELATED,ESTABLISHED -j ACCEPT
iptables -I FORWARD -m state --state RELATED,ESTABLISHED -j ACCEPT
as the last lines in the DD-WRT firewall script?
If it is that simple (since the firewall script will get run if anything in the firewall changes), then why don't we have it implemented in that manner for now? _________________ E3000 22200M KongVPN K26
WRT600n v1.1 refirb mega 18767 BS K24 NEWD2 [not used]
WRT54G v2 16214 BS K24 [access point]
Try Dropbox for syncing files - get 2.5gb online for free by signing up.
Read! Peacock thread
*PLEASE* upgrade PAST v24SP1 or no support.
I started a topic about it, requesting that "Save as firewall" would convert whatever is typed there to iptables-restore format, but low interest from forum users.. perhaps is not a good idea anyway.. but would be nice to have a "firewall file" so you can edit all in one
It would be good if there were an option to use iptables-save/restore, maybe the way (changing the default webif) you suggested it would not be optimal.
It could be done in "MyPage" without too much trouble I imagine....and speaking of MyPage, I wonder what Eko has been up to lately. _________________ Eko Builds
Is it going to be as simple as placing the above listed commands:
Code:
iptables -D FORWARD -m state --state RELATED,ESTABLISHED -j ACCEPT
iptables -I FORWARD -m state --state RELATED,ESTABLISHED -j ACCEPT
as the last lines in the DD-WRT firewall script?
Yes. _________________ Read the forum announcements thoroughly! Be cautious if you're inexperienced.
Available for paid consulting. (Don't PM about complicated setups otherwise)
Looking for bricks and spare routers to expand my collection. (not interested in G spec models)
2. Use the firmware modkit to insert iptables-save/restore into the firmware permanently.
3. Build an install script for iptables-save/restore.
For me either 2 or 3 would be optimal.
I would have to look, but isn't iptables-save just a shell script anyway?
Previously I had tried to insert a uuencoded gzipped shell script (my miniupnpd installer) into an nvram variable and zcat it back through uudecode then sh, but haven't gotten this to work quite right. I like this method, I feel it would work (survive reboots), no need for jffs2 overhead, but this is not very safe. So I ended up just creating a firewall script that downloads the actual installation script and executes it upon each reload of the firewall, you could do something similar for iptables-save/restore. _________________ Eko Builds
I think there must be a reason why it isn't included, but if used at the proper time I don't see too much of a problem. The rules are generated dynamically based on nvram variables, so I think you would have to diff the old iptables-saved chains if you changed any setting from the webif before running iptables-restore....otherwise your rules would be incorrect (out of sync).
I think I'm too tired right now to figure out any kind of proper way to integrate save/restore reliably. Diff is probably not included either.
I just realized this is not what you want, you want DD-WRT to save your webif entries in iptables-restore format and call the command after creating the default rules....therefore inserting your rules you entered from the webif alongside the defaults. The firmware modkit would be necessary I think, you would need to edit the startup scripts....prewall I believe is the script that would hold the key. _________________ Eko Builds
