CONNLIMIT Questions

CONNLIMIT Questions

[Peter Renzland]

What I want to do is limit the total number of (mostly) outgoing  
(mostly UDP) connection (attempts) by LAN IP.  This is because of out- 
of-control BT (etc.) configurations and clients that will try to set  
up thousands of connections in a few seconds, almost all of which will  
fail and time out.  With a dozen LAN users doing this simultaneously,  
the router is toast.


I have seen the following two rules suggested frequently:


iptables -I FORWARD -p tcp --syn -m iprange --src-range  
192.168.0.100-192.168.0.199 -m connlimit --connlimit-above 100 -j DROP

iptables -I FORWARD -p ! tcp -m iprange --src-range  
192.168.0.100-192.168.0.199 -m connlimit --connlimit-above 50 -j DROP


My questions:

1. Is REJECT any better than DROP?  (Will anything or anyone actually  
get the reject message and learn anything from it?)

2. Is the "--syn" necessary?  The manual says:

     "--syn
         Only match TCP packets with the SYN bit set and the ACK,RST  
and FIN bits cleared. Such packets are used to request TCP connection  
initiation; for example, blocking such packets coming in an interface  
will prevent incoming TCP connections, but outgoing TCP connections  
will be unaffected"

      When limiting connections with CONNLIMIT, can I not rely on  
CONNTRACK's logic to determine that a new connection is about to be  
tracked?  Why should I have to duplicate part of this effort?  Does  
the logic of the text of that paragraph accurately reflect the  
program's logic?


3. Is there not a single rule that will limit connections regardless  
of protocol?  Why does:

     iptables -I FORWARD  -m iprange --src-range  
192.168.0.100-192.168.0.199 -m connlimit --connlimit-above 50 -j DROP

     fail with "Invalid argument"?

     This man page ( http://linux.die.net/man/8/iptables ) states:

    "connlimit
	Allows you to restrict the number of parallel TCP connections to a  
server per client IP address (or address block)."


     And all examples are for TCP, and all specify "--syn".


     So, is "! tcp" just a kludge to get around a "tcp-only" design  
limitation?  Or is there some "good" reason? :-)


     (After all, the concept of connection in connection-tracking is  
much broader than the concept of connection in TCP.  What might I be  
missing? :-)


4. Here is the BIG question:

     The manual says: "restrict the number of parallel TCP connections  
to a server".

     But that is not at all what I want to do.   I want to restrict  
the number of greatly *divergent* connections to many, many different  
servers.



Perhaps there is a better (effective) way to limit connection attempts  
by LAN IP?
In any direction and for any protocol.


Thanks much!

Peter Renzland

Re: CONNLIMIT Questions

[Sitaram Chamarty]

On 2009-01-18, Peter Renzland <peter@dancing.org> wrote:
> 1. Is REJECT any better than DROP?  (Will anything or anyone actually  
> get the reject message and learn anything from it?)

REJECT is better than DROP in the sense that the application
making the connection will get (and be able to pass back to
the user, presumably) a proper error message.  A DROP looks
like the packet didn't make it, and the program will not
report back to the user until some timeout or retry limit
finishes.

>      But that is not at all what I want to do.   I want to restrict  
> the number of greatly *divergent* connections to many, many different  
> servers.

> Perhaps there is a better (effective) way to limit connection attempts  
> by LAN IP?
> In any direction and for any protocol.

You could take a look at the hashlimit and the limit
modules; one of those should do what you want.  I have no
used the hashlimit one so far, and the limit one only for
incoming connections, but they seem more general than
connlimit.

Re: CONNLIMIT Questions

[Peter Renzland]

[Netfilter v1.3.7, Linux 2.4.20, Tomato 1.23, Busybox v1.12.3,  
embedded in a WRT54GL router]

On 09  Jan 19, at 10:34 , Sitaram Chamarty wrote:

> On 2009-01-18, Peter Renzland <peter@dancing.org> wrote:
>> 1. Is REJECT any better than DROP?  (Will anything or anyone actually
>> get the reject message and learn anything from it?)
>
> REJECT is better than DROP in the sense that the application
> making the connection will get (and be able to pass back to
> the user, presumably) a proper error message.  A DROP looks
> like the packet didn't make it, and the program will not
> report back to the user until some timeout or retry limit
> finishes.

If (and that is the question) the reject-reason is indeed seen, then  
perhaps --reject-with icmp-admin-prohibited would be a clearer message  
to send than the default icmp-host-unreachable.

This raises some new questions, expanding the original (yet unresolved  
one) to:

1.1 will anyone or anything actually *get* and *use* the reject  
reason? (Especially PC users and their software, and especially  
BitTorrent users and BitTorrent clients.)

-- the iptables manual states that "Using icmp-admin-prohibited with  
kernels that do not support it will result in a plain DROP instead of  
REJECT".  -- 

1.2 why does a message text need kernel support?

1.3 why "drop" instead "reject with reason unavailable"?

1.4 how does an iptables user determine whether such kernel support  
exists?




>>     But that is not at all what I want to do.   I want to restrict
>> the number of greatly *divergent* connections to many, many different
>> servers.
>
>> Perhaps there is a better (effective) way to limit connection  
>> attempts
>> by LAN IP?
>> In any direction and for any protocol.
>
> You could take a look at the hashlimit and the limit
> modules; one of those should do what you want.  I have no
> used the hashlimit one so far, and the limit one only for
> incoming connections, but they seem more general than
> connlimit.

The central question that was never addressed was:

* The iptables manual page states that connlimit limits *incoming*  
*tcp* connections.  I want to limit what overwhelmingly are outgoing  
UDP connections.

Thanks,
Peter Renzland

[Netfilter v1.3.7, Linux 2.4.20, Tomato 1.23, Busybox v1.12.3,  
embedded in a WRT54GL router]

Re: CONNLIMIT Questions

[Gáspár Lajos]

Hi!


Peter Renzland írta:
> The central question that was never addressed was:
>
> * The iptables manual page states that connlimit limits *incoming* 
> *tcp* connections.  I want to limit what overwhelmingly are outgoing 
> UDP connections.
Don't get me wrong... but EVERY forwarded connection/packet at first is 
incoming on the firewall...
Think about it...
>
> Thanks,
> Peter Renzland
>
Swifty

Re: CONNLIMIT Questions

[Peter Renzland]

Swifty,

You're right and I was doubly wrong.

What the manual actually says, and what I had in my original message,  
was:

"restrict the number of parallel TCP connections to a server per  
client IP address (or address block)."

I want to limit what overwhelmingly are divergent UDP connection  
attempts to 1000's of servers.

Peter



On 09  Jan 21, at 13:43 , Gáspár Lajos wrote:

> Hi!
>
>
> Peter Renzland írta:
>> The central question that was never addressed was:
>>
>> * The iptables manual page states that connlimit limits *incoming*  
>> *tcp* connections.  I want to limit what overwhelmingly are  
>> outgoing UDP connections.
> Don't get me wrong... but EVERY forwarded connection/packet at first  
> is incoming on the firewall...
> Think about it...
>>
>> Thanks,
>> Peter Renzland
>>
> Swifty
>
>

Re: CONNLIMIT Questions

[Peter Renzland]

I got partial answers by experimenting:

icmp-admin-prohibited is indeed treated as "DROP"
icmp-net-prohibited and -host- ... ping says: Dest Unreachable, Bad  
Code: 9  (and 10)
telnet says "network unreachable" or "connection refused"
Safari says nothing specific.

However, I did find a significant operational difference between DROP  
and REJECT:

Reject immediately returns a message to the client.
Drop simply does not respond to the client.  I.e. it *ignores* the  
request, leaving the client waiting, until the client gives up.

 From the perspective of the router's well-being, DROP may be  
preferable, since the client will not try again, while he is busy  
waiting! :-)

This is especially so if the router is unable to send a meaningful  
reject message, such as "admin-prohibited".
Other messages will only result in retries, when the underlying  
message is "stop trying, you are failing because you are trying too  
much!"

[Perhaps one day we will be able to specify an arbitrary (meaningful)  
text, such as "Connection Limit Exceeded", and no kernel needs to  
approve of it!]

Peter


On 09  Jan 21, at 12:54 , Peter Renzland wrote:

> [Netfilter v1.3.7, Linux 2.4.20, Tomato 1.23, Busybox v1.12.3,  
> embedded in a WRT54GL router]
>
> On 09  Jan 19, at 10:34 , Sitaram Chamarty wrote:
>
>> On 2009-01-18, Peter Renzland <peter@dancing.org> wrote:
>>> 1. Is REJECT any better than DROP?  (Will anything or anyone  
>>> actually
>>> get the reject message and learn anything from it?)
>>
>> REJECT is better than DROP in the sense that the application
>> making the connection will get (and be able to pass back to
>> the user, presumably) a proper error message.  A DROP looks
>> like the packet didn't make it, and the program will not
>> report back to the user until some timeout or retry limit
>> finishes.
>
> If (and that is the question) the reject-reason is indeed seen, then  
> perhaps --reject-with icmp-admin-prohibited would be a clearer  
> message to send than the default icmp-host-unreachable.
>
> This raises some new questions, expanding the original (yet  
> unresolved one) to:
>
> 1.1 will anyone or anything actually *get* and *use* the reject  
> reason? (Especially PC users and their software, and especially  
> BitTorrent users and BitTorrent clients.)
>
> -- the iptables manual states that "Using icmp-admin-prohibited with  
> kernels that do not support it will result in a plain DROP instead  
> of REJECT".  --
> 1.2 why does a message text need kernel support?
>
> 1.3 why "drop" instead "reject with reason unavailable"?
>
> 1.4 how does an iptables user determine whether such kernel support  
> exists?
>
>
>
>
>>>    But that is not at all what I want to do.   I want to restrict
>>> the number of greatly *divergent* connections to many, many  
>>> different
>>> servers.
>>
>>> Perhaps there is a better (effective) way to limit connection  
>>> attempts
>>> by LAN IP?
>>> In any direction and for any protocol.
>>
>> You could take a look at the hashlimit and the limit
>> modules; one of those should do what you want.  I have no
>> used the hashlimit one so far, and the limit one only for
>> incoming connections, but they seem more general than
>> connlimit.
>
> The central question that was never addressed was:
>
> * The iptables manual page states that connlimit

[edited...]
> "restrict the number of parallel TCP connections to a server per  
> client IP address (or address block)."
>
> I want to limit what overwhelmingly are divergent UDP connection  
> attempts to 1000's of servers.
[...edited]


> Thanks,
> Peter Renzland
>
> [Netfilter v1.3.7, Linux 2.4.20, Tomato 1.23, Busybox v1.12.3,  
> embedded in a WRT54GL router]