multiport tolerance changes

Hi all,

I recently upgraded my firewall setup. Mainly upgrading kernel from 2.6.8 to 2.6.16 and iptables from 1.2.7 to 1.3.5. And I had to modify my
firewall rules due to what I think is a syntax tolerance change
regarding multiport.

With iptables 1.2.7 I had some rules where I could write some multiport (port lists or ranges) both for source and destination ports, like this:

/sbin/iptables -A fw2net_eth3 -p tcp -m multiport -s 82.67.103.87 --sport 1024:65535 -d 0.0.0.0/0 --dports 80,8080,81,8000,1755 -j ACCEPT

iptables was coping well with this and expanded the port matrix into appropriate single rules (ipchains was also able to do this well in its good time). But iptables 1.3.5 refuses to have multiport for both source and destination ports and objects:

iptables v1.3.5: multiport can only have one option

So I have to re-write my firewall rules.

What is the reason why this practical feature (expanding the port matrix) disapeared ? Is it related to the merge of extended multiport into multiport (including ranges in lists) ? Is there any plan to re-introcduce such a functionality in the future releases of iptables ?

Thanks for your comments on this.

Vincent

Hello,

What do you mean ? Could you give an example of such expansion ?

Well, it seems that my old iptables 1.2.6a already had the same limitation. I submitted your rule to it and got an error too.

How did you rewrite the above rule ?
If I reorder the options, so that the --sport parameter appears to belong to the implicit "-m tcp" match created by "-p tcp", the rule is accepted by my iptables 1.2.6a :

/sbin/iptables -A fw2net_eth3 -s 82.67.103.87 -d 0.0.0.0/0 \
-p tcp --sport 1024:65535 -m multiport --dports 80,8080,81,8000,1755 \
-j ACCEPT

As a general rule it seems to me that it is more logical and readable to put the parameters of a match right behind the match.

PS: what's the use of "-d 0.0.0.0/0" ?

The expansion in that case becomes:

    0     0 ACCEPT     tcp  --  *      *       82.67.103.87
0.0.0.0/0          tcp spts:1024:65535 dpt:8080
    0     0 ACCEPT     tcp  --  *      *       82.67.103.87
0.0.0.0/0          tcp spts:1024:65535 dpt:81
    0     0 ACCEPT     tcp  --  *      *       82.67.103.87
0.0.0.0/0          tcp spts:1024:65535 dpt:8000
    0     0 ACCEPT     tcp  --  *      *       82.67.103.87

0.0.0.0/0 tcp spts:1024:65535 dpt:1755

I suppressed the SOURCE port range and the rule becomes more permissive (but works):

/sbin/iptables -A fw2net_eth3 -p tcp -m multiport -s 82.67.103.87 -d 0.0.0.0/0 --dports 80,8080,81,8000,1755 -j ACCEPT

I confirm that when writing it that way (reordering properly) I also have no more error. But for some protocol, I would like to be able to write some source port range and also some destination port range. A rule like this:

/sbin/iptables -A fw2net_eth3 -p tcp -m multiport -s 82.67.103.87 --sports 10000,10001,10002 -d 0.0.0.0/0 --dports 80,8080,81,8000,1755 -j ACCEPT

And such a rule actually does not work.

You're right, but I have some constraints that does not permit this right now.

0.0.0.0 is here just because I use shell script variable for my rules and sometimes it gets replaced with a "proper" IP bloc or address I have some general scripts that generate config for many routeurs, the config are then uploaded onto the routers for iptables treatment. A kind of general firewall configuration generator based on per router DB variables.