Pascal Hambourg a écrit :
Hello,
Vincent Regnard a écrit :
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
What do you mean ? Could you give an example of such expansion ?
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
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
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.
So I have to re-write my firewall rules.
How did you rewrite the above rule ?
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
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
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.
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.
You're right, but I have some constraints that does not permit this
right now.
PS: what's the use of "-d 0.0.0.0/0" ?
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.
