Long iptables rules efficiency & performance

The name of the pictureThe name of the pictureThe name of the pictureClash Royale CLAN TAG#URR8PPP








up vote
0
down vote

favorite












When building a long iptables rules, which one is more efficient, to use one long script per line or to use the tables? What about the performance, does it have effect to packets loss and untracked packets?



Example:




  1. one script per line



    iptables -A INPUT -i wlan0 -p tcp --sport 80 -j ACCEPT



  2. using the tables



    iptables -N table1
    iptables -A INPUT -i wlan0 -j tbl1
    iptables -A table1 -p tcp --sport 80 -j ACCEPT










share|improve this question























  • To performance test see people.netfilter.org/kadlec/nftest.pdf and strongarm.io/blog/linux-firewall-performance-testing
    – Panther
    Mar 28 at 14:38














up vote
0
down vote

favorite












When building a long iptables rules, which one is more efficient, to use one long script per line or to use the tables? What about the performance, does it have effect to packets loss and untracked packets?



Example:




  1. one script per line



    iptables -A INPUT -i wlan0 -p tcp --sport 80 -j ACCEPT



  2. using the tables



    iptables -N table1
    iptables -A INPUT -i wlan0 -j tbl1
    iptables -A table1 -p tcp --sport 80 -j ACCEPT










share|improve this question























  • To performance test see people.netfilter.org/kadlec/nftest.pdf and strongarm.io/blog/linux-firewall-performance-testing
    – Panther
    Mar 28 at 14:38












up vote
0
down vote

favorite









up vote
0
down vote

favorite











When building a long iptables rules, which one is more efficient, to use one long script per line or to use the tables? What about the performance, does it have effect to packets loss and untracked packets?



Example:




  1. one script per line



    iptables -A INPUT -i wlan0 -p tcp --sport 80 -j ACCEPT



  2. using the tables



    iptables -N table1
    iptables -A INPUT -i wlan0 -j tbl1
    iptables -A table1 -p tcp --sport 80 -j ACCEPT










share|improve this question















When building a long iptables rules, which one is more efficient, to use one long script per line or to use the tables? What about the performance, does it have effect to packets loss and untracked packets?



Example:




  1. one script per line



    iptables -A INPUT -i wlan0 -p tcp --sport 80 -j ACCEPT



  2. using the tables



    iptables -N table1
    iptables -A INPUT -i wlan0 -j tbl1
    iptables -A table1 -p tcp --sport 80 -j ACCEPT







iptables






share|improve this question















share|improve this question













share|improve this question




share|improve this question








edited Mar 29 at 2:58









muru

130k19273463




130k19273463










asked Mar 28 at 8:52









smnlss689

113




113











  • To performance test see people.netfilter.org/kadlec/nftest.pdf and strongarm.io/blog/linux-firewall-performance-testing
    – Panther
    Mar 28 at 14:38
















  • To performance test see people.netfilter.org/kadlec/nftest.pdf and strongarm.io/blog/linux-firewall-performance-testing
    – Panther
    Mar 28 at 14:38















To performance test see people.netfilter.org/kadlec/nftest.pdf and strongarm.io/blog/linux-firewall-performance-testing
– Panther
Mar 28 at 14:38




To performance test see people.netfilter.org/kadlec/nftest.pdf and strongarm.io/blog/linux-firewall-performance-testing
– Panther
Mar 28 at 14:38










1 Answer
1






active

oldest

votes

















up vote
0
down vote













In your second example, you define a new chain called table1, and route incoming packets to the new chain in order to perform matching on the chain.



This can be a good strategy if, for example, the processing you do on that chain is somewhat heavy and you don't want to subject all incoming packets to it.



But in your example,



  • ALL incoming traffic on the wlan0 interface is sent to the new chain (this even includes packets that are part of established connections!)

  • The processing on that chain is trivial - just matching by source and destination port.

So in this simple example the extra complexity of defining a new chain and routing everything to it is unnecessary and redundant, and were you able to measure a performance difference, would probably result in the lower performance.



Performance really won't affect you unless you have a lot more rules or much heavier processing.






share|improve this answer




















  • It is true, from my experience (just tested it) more chains will make it more heavier. I'm using a metered data connection, It consumes more bandwith when I use more chains, and using more REJECT. It also consumes more bandwith if I use DROP insted of REJECT. But I think more chains is more secure than simply write many rules at one with less chains. I'm just wondered how windows do it, it consumes less bandwith downloading using IDM software (tested it years ago) from the internet than any linux.
    – smnlss689
    Apr 10 at 2:54











  • If efficiency is a priority at all, you should accept any related or established packets as early as possible. You may already be doing this in rules that weren't part of your example, but I mention it just in case.
    – thomasrutter
    Apr 10 at 3:37










Your Answer







StackExchange.ready(function()
var channelOptions =
tags: "".split(" "),
id: "89"
;
initTagRenderer("".split(" "), "".split(" "), channelOptions);

StackExchange.using("externalEditor", function()
// Have to fire editor after snippets, if snippets enabled
if (StackExchange.settings.snippets.snippetsEnabled)
StackExchange.using("snippets", function()
createEditor();
);

else
createEditor();

);

function createEditor()
StackExchange.prepareEditor(
heartbeatType: 'answer',
convertImagesToLinks: true,
noModals: false,
showLowRepImageUploadWarning: true,
reputationToPostImages: 10,
bindNavPrevention: true,
postfix: "",
onDemand: true,
discardSelector: ".discard-answer"
,immediatelyShowMarkdownHelp:true
);



);













 

draft saved


draft discarded


















StackExchange.ready(
function ()
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2faskubuntu.com%2fquestions%2f1019893%2flong-iptables-rules-efficiency-performance%23new-answer', 'question_page');

);

Post as a guest






























1 Answer
1






active

oldest

votes








1 Answer
1






active

oldest

votes









active

oldest

votes






active

oldest

votes








up vote
0
down vote













In your second example, you define a new chain called table1, and route incoming packets to the new chain in order to perform matching on the chain.



This can be a good strategy if, for example, the processing you do on that chain is somewhat heavy and you don't want to subject all incoming packets to it.



But in your example,



  • ALL incoming traffic on the wlan0 interface is sent to the new chain (this even includes packets that are part of established connections!)

  • The processing on that chain is trivial - just matching by source and destination port.

So in this simple example the extra complexity of defining a new chain and routing everything to it is unnecessary and redundant, and were you able to measure a performance difference, would probably result in the lower performance.



Performance really won't affect you unless you have a lot more rules or much heavier processing.






share|improve this answer




















  • It is true, from my experience (just tested it) more chains will make it more heavier. I'm using a metered data connection, It consumes more bandwith when I use more chains, and using more REJECT. It also consumes more bandwith if I use DROP insted of REJECT. But I think more chains is more secure than simply write many rules at one with less chains. I'm just wondered how windows do it, it consumes less bandwith downloading using IDM software (tested it years ago) from the internet than any linux.
    – smnlss689
    Apr 10 at 2:54











  • If efficiency is a priority at all, you should accept any related or established packets as early as possible. You may already be doing this in rules that weren't part of your example, but I mention it just in case.
    – thomasrutter
    Apr 10 at 3:37














up vote
0
down vote













In your second example, you define a new chain called table1, and route incoming packets to the new chain in order to perform matching on the chain.



This can be a good strategy if, for example, the processing you do on that chain is somewhat heavy and you don't want to subject all incoming packets to it.



But in your example,



  • ALL incoming traffic on the wlan0 interface is sent to the new chain (this even includes packets that are part of established connections!)

  • The processing on that chain is trivial - just matching by source and destination port.

So in this simple example the extra complexity of defining a new chain and routing everything to it is unnecessary and redundant, and were you able to measure a performance difference, would probably result in the lower performance.



Performance really won't affect you unless you have a lot more rules or much heavier processing.






share|improve this answer




















  • It is true, from my experience (just tested it) more chains will make it more heavier. I'm using a metered data connection, It consumes more bandwith when I use more chains, and using more REJECT. It also consumes more bandwith if I use DROP insted of REJECT. But I think more chains is more secure than simply write many rules at one with less chains. I'm just wondered how windows do it, it consumes less bandwith downloading using IDM software (tested it years ago) from the internet than any linux.
    – smnlss689
    Apr 10 at 2:54











  • If efficiency is a priority at all, you should accept any related or established packets as early as possible. You may already be doing this in rules that weren't part of your example, but I mention it just in case.
    – thomasrutter
    Apr 10 at 3:37












up vote
0
down vote










up vote
0
down vote









In your second example, you define a new chain called table1, and route incoming packets to the new chain in order to perform matching on the chain.



This can be a good strategy if, for example, the processing you do on that chain is somewhat heavy and you don't want to subject all incoming packets to it.



But in your example,



  • ALL incoming traffic on the wlan0 interface is sent to the new chain (this even includes packets that are part of established connections!)

  • The processing on that chain is trivial - just matching by source and destination port.

So in this simple example the extra complexity of defining a new chain and routing everything to it is unnecessary and redundant, and were you able to measure a performance difference, would probably result in the lower performance.



Performance really won't affect you unless you have a lot more rules or much heavier processing.






share|improve this answer












In your second example, you define a new chain called table1, and route incoming packets to the new chain in order to perform matching on the chain.



This can be a good strategy if, for example, the processing you do on that chain is somewhat heavy and you don't want to subject all incoming packets to it.



But in your example,



  • ALL incoming traffic on the wlan0 interface is sent to the new chain (this even includes packets that are part of established connections!)

  • The processing on that chain is trivial - just matching by source and destination port.

So in this simple example the extra complexity of defining a new chain and routing everything to it is unnecessary and redundant, and were you able to measure a performance difference, would probably result in the lower performance.



Performance really won't affect you unless you have a lot more rules or much heavier processing.







share|improve this answer












share|improve this answer



share|improve this answer










answered Mar 29 at 0:07









thomasrutter

25.4k46086




25.4k46086











  • It is true, from my experience (just tested it) more chains will make it more heavier. I'm using a metered data connection, It consumes more bandwith when I use more chains, and using more REJECT. It also consumes more bandwith if I use DROP insted of REJECT. But I think more chains is more secure than simply write many rules at one with less chains. I'm just wondered how windows do it, it consumes less bandwith downloading using IDM software (tested it years ago) from the internet than any linux.
    – smnlss689
    Apr 10 at 2:54











  • If efficiency is a priority at all, you should accept any related or established packets as early as possible. You may already be doing this in rules that weren't part of your example, but I mention it just in case.
    – thomasrutter
    Apr 10 at 3:37
















  • It is true, from my experience (just tested it) more chains will make it more heavier. I'm using a metered data connection, It consumes more bandwith when I use more chains, and using more REJECT. It also consumes more bandwith if I use DROP insted of REJECT. But I think more chains is more secure than simply write many rules at one with less chains. I'm just wondered how windows do it, it consumes less bandwith downloading using IDM software (tested it years ago) from the internet than any linux.
    – smnlss689
    Apr 10 at 2:54











  • If efficiency is a priority at all, you should accept any related or established packets as early as possible. You may already be doing this in rules that weren't part of your example, but I mention it just in case.
    – thomasrutter
    Apr 10 at 3:37















It is true, from my experience (just tested it) more chains will make it more heavier. I'm using a metered data connection, It consumes more bandwith when I use more chains, and using more REJECT. It also consumes more bandwith if I use DROP insted of REJECT. But I think more chains is more secure than simply write many rules at one with less chains. I'm just wondered how windows do it, it consumes less bandwith downloading using IDM software (tested it years ago) from the internet than any linux.
– smnlss689
Apr 10 at 2:54





It is true, from my experience (just tested it) more chains will make it more heavier. I'm using a metered data connection, It consumes more bandwith when I use more chains, and using more REJECT. It also consumes more bandwith if I use DROP insted of REJECT. But I think more chains is more secure than simply write many rules at one with less chains. I'm just wondered how windows do it, it consumes less bandwith downloading using IDM software (tested it years ago) from the internet than any linux.
– smnlss689
Apr 10 at 2:54













If efficiency is a priority at all, you should accept any related or established packets as early as possible. You may already be doing this in rules that weren't part of your example, but I mention it just in case.
– thomasrutter
Apr 10 at 3:37




If efficiency is a priority at all, you should accept any related or established packets as early as possible. You may already be doing this in rules that weren't part of your example, but I mention it just in case.
– thomasrutter
Apr 10 at 3:37

















 

draft saved


draft discarded















































 


draft saved


draft discarded














StackExchange.ready(
function ()
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2faskubuntu.com%2fquestions%2f1019893%2flong-iptables-rules-efficiency-performance%23new-answer', 'question_page');

);

Post as a guest













































































Popular posts from this blog

pylint3 and pip3 broken

Missing snmpget and snmpwalk

How to enroll fingerprints to Ubuntu 17.10 with VFS491