strange behavior of connlimit matching rules

strange behavior of connlimit matching rules

[Bernd Strebel]

Along with the implementation of a simple rule set ( ACCEPT connections 
if ! --connlimit-above nan LOG connections if --connlimit-above n) we 
experienced a strange behavior of the connlimit matching module:

Rule #m:   ...-m connlimit   --connlimit-above n -j LOG
Rule #m+1: ...-m connlimit ! --connlimit-above n -j ACCEPT

works fine, while

Rule #m:   ...-m connlimit ! --connlimit-above n -j ACCEPT
Rule #m+1: ...-m connlimit   --connlimit-above n -j LOG

works not (no match on rule #m+1).

Many thanks for any explanation.
Bernd


environment: kernel 2.4.26, iptables 1.2.9, pomng-20040302
============

iptables output (source/dest. stripped, always 0.0.0.0/0)
===============

Chain OUTPUT (policy DROP 9 packets, 560 bytes): OK

num   pkts bytes target     prot opt in     out

1      131  9331 ACCEPT     all  --  *      lo

2      116 11140 ACCEPT     all  --  *      *
        state RELATED,ESTABLISHED

3        5   260 LOG        tcp  --  *      eth0
        mport dports 22 #conn/32 > 2 state NEW
        LOG flags 0 level 4 prefix CONNLIMIT

4        5   260 ACCEPT     tcp  --  *      eth0
        mport dports 22 #conn/32 < 2 state NEW

5        9   560 LOG        all  --  *      *
        LOG flags 0 level 4 prefix DROP-AT-END-OF-CHAIN


Chain OUTPUT (policy DROP 10 packets, 612 bytes): CONNLIMIT not logged!

num   pkts bytes target     prot opt in     out

1      138  9950 ACCEPT     all  --  *      lo

2      124 11648 ACCEPT     all  --  *      *
        state RELATED,ESTABLISHED

3        0     0 ACCEPT     tcp  --  *      eth0
        mport dports 22 #conn/32 < 2 state NEW

4        0     0 LOG        tcp  --  *      eth0
        mport dports 22 #conn/32 > 2 state NEW
        LOG flags 0 level 4 prefix CONNLIMIT

5       10   612 LOG        all  --  *      *
        LOG flags 0 level 4 prefix DROP-AT-END-OF-CHAIN

Re: strange behavior of connlimit matching rules

[Bernd Strebel]

Thanks for your reply. I've re-arranged the rules to something like

-P DROP

--state RELATED,ESTABLISHED -j ACCEPT
--connlimit-above n -j LOG
--state NEW --syn ! --connlimit-above n -j ACCEPT
--state NEW --syn ... -j ACCEPT
... many ... -j ACCEPT

... many ... -j LOG to log packages which aren't accepted

and now it is working.

But, with this solution every SYN packet first has to be checked against 
the connlimit rule before entering the ACCEPT block. I would prefer to 
do the logging of unwanted packages after all accepting rules and this 
works fine with all the other matching modules (e.g. time, owner).

And,  I am still worried about the fact, that a package no longer 
matches against a connlimit rule after it was checked against a 
!connlimit rule ...

Stephane Bortzmeyer wrote:
> On Tue, May 18, 2004 at 09:00:52AM +0200,
>  Bernd Strebel <b.strebel@digitec.de> wrote 
>  a message of 63 lines which said:
> 
> 
>>Along with the implementation of a simple rule set ( ACCEPT connections 
>>if ! --connlimit-above n and LOG connections if --connlimit-above n) we 
>>experienced a strange behavior of the connlimit matching module:
>>
>>Rule #m:   ...-m connlimit   --connlimit-above n -j LOG
>>Rule #m+1: ...-m connlimit ! --connlimit-above n -j ACCEPT
>>
>>works fine, while
>>
>>Rule #m:   ...-m connlimit ! --connlimit-above n -j ACCEPT
>>Rule #m+1: ...-m connlimit   --connlimit-above n -j LOG
>>
>>works not (no match on rule #m+1).
> 
> 
> No idea but what I do (and it works) is:
> 
> Rule #m:   ...-m connlimit   --connlimit-above n -j LOG
> Rule #m+1: ...-m connlimit   --connlimit-above n -j REJECT
> ... Other rules, which may accept
> 
>