New connlimit: how to use?

New connlimit: how to use?

[Christian Lerrahn]

Hi,
I've seen that this question has been asked before but without reply.
I'll therefore make another attempt to rephrase it.

I need connlimit on one of my boxes. For that I first tried kernel
2.6.22 with patch-o-matic which failed. The kernel dropped everything
on a given port as soon as any rule was set for that port.

So, I decided to go to 2.6.23 and was delighted to see that connlimit
is now included in the vanilla kernel. However, I realised that the
structure is not the same as the patch produced. So I assumed that you
would need the latest version of iptables. I therefore got iptables
1.4.0rc1 and compiled it. Generally speaking iptables works fine now.
However, if I try to set a rule using connlimit, I get an error

"iptables: Invalid argument"

If I run e.g.

iptables -vv -A INPUT -p tcp --dport 80 -m connlimit --connlimit-above 32 -j DROP

I see the output

DROP  tcp opt -- in * out *  0.0.0.0/0  -> 0.0.0.0/0  tcp dpt:80 #conn/32 > 32 
libiptc v1.4.0rc1. 620 bytes.
Table `filter'
Hooks: pre/in/fwd/out/post = 0/0/148/296/0
Underflows: pre/in/fwd/out/post = 0/0/148/296/0
Entry 0 (0):
SRC IP: 0.0.0.0/0.0.0.0
DST IP: 0.0.0.0/0.0.0.0
Interface: `'/................to `'/................
Protocol: 0
Flags: 00
Invflags: 00
Counters: 4598391 packets, 695123203 bytes
Cache: 00000000
Target name: `' [36]
verdict=NF_ACCEPT

Entry 1 (148):
SRC IP: 0.0.0.0/0.0.0.0
DST IP: 0.0.0.0/0.0.0.0
Interface: `'/................to `'/................
Protocol: 0
Flags: 00
Invflags: 00
Counters: 0 packets, 0 bytes
Cache: 00000000
Target name: `' [36]
verdict=NF_ACCEPT

Entry 2 (296):
SRC IP: 0.0.0.0/0.0.0.0
DST IP: 0.0.0.0/0.0.0.0
Interface: `'/................to `'/................
Protocol: 0
Flags: 00
Invflags: 00
Counters: 5476812 packets, 2506858579 bytes
Cache: 00000000
Target name: `' [36]
verdict=NF_ACCEPT

Entry 3 (444):
SRC IP: 0.0.0.0/0.0.0.0
DST IP: 0.0.0.0/0.0.0.0
Interface: `'/................to `'/................
Protocol: 0
Flags: 00
Invflags: 00
Counters: 0 packets, 0 bytes
Cache: 00000000
Target name: `ERROR' [64]
error=`ERROR'

iptables: Invalid argument

Now, being a total n00b (at least when it comes to these things),
that doesn't tell me anything. :(

Any hints?

Cheers,
Christian

Re: New connlimit: how to use?

[sadrafal]

Do you see " kernel: ip_tables: connlimit match: invalid size 32 != 16" in
/var/log/messages ?
Use the latest iptables snapshot (pom not needed) - problem fixed
Kernel 2.6.24-rc4
iptables v1.4.0rc1-20071205

regards

----- Original Message -----
From: "Christian Lerrahn" <lists@penpal4u.net>
To: <netfilter@vger.kernel.org>
Sent: Friday, December 07, 2007 12:56 AM
Subject: New connlimit: how to use?


> Hi,
> I've seen that this question has been asked before but without reply.
> I'll therefore make another attempt to rephrase it.
>
> I need connlimit on one of my boxes. For that I first tried kernel
> 2.6.22 with patch-o-matic which failed. The kernel dropped everything
> on a given port as soon as any rule was set for that port.
>
> So, I decided to go to 2.6.23 and was delighted to see that connlimit
> is now included in the vanilla kernel. However, I realised that the
> structure is not the same as the patch produced. So I assumed that you
> would need the latest version of iptables. I therefore got iptables
> 1.4.0rc1 and compiled it. Generally speaking iptables works fine now.
> However, if I try to set a rule using connlimit, I get an error
>
> "iptables: Invalid argument"
>
> If I run e.g.
>
> iptables -vv -A INPUT -p tcp --dport 80 -m connlimit --connlimit-above
32 -j DROP
>
> I see the output
>
> DROP  tcp opt -- in * out *  0.0.0.0/0  -> 0.0.0.0/0  tcp dpt:80 #conn/32
> 32
> libiptc v1.4.0rc1. 620 bytes.
> Table `filter'
> Hooks: pre/in/fwd/out/post = 0/0/148/296/0
> Underflows: pre/in/fwd/out/post = 0/0/148/296/0
> Entry 0 (0):
> SRC IP: 0.0.0.0/0.0.0.0
> DST IP: 0.0.0.0/0.0.0.0
> Interface: `'/................to `'/................
> Protocol: 0
> Flags: 00
> Invflags: 00
> Counters: 4598391 packets, 695123203 bytes
> Cache: 00000000
> Target name: `' [36]
> verdict=NF_ACCEPT
>
> Entry 1 (148):
> SRC IP: 0.0.0.0/0.0.0.0
> DST IP: 0.0.0.0/0.0.0.0
> Interface: `'/................to `'/................
> Protocol: 0
> Flags: 00
> Invflags: 00
> Counters: 0 packets, 0 bytes
> Cache: 00000000
> Target name: `' [36]
> verdict=NF_ACCEPT
>
> Entry 2 (296):
> SRC IP: 0.0.0.0/0.0.0.0
> DST IP: 0.0.0.0/0.0.0.0
> Interface: `'/................to `'/................
> Protocol: 0
> Flags: 00
> Invflags: 00
> Counters: 5476812 packets, 2506858579 bytes
> Cache: 00000000
> Target name: `' [36]
> verdict=NF_ACCEPT
>
> Entry 3 (444):
> SRC IP: 0.0.0.0/0.0.0.0
> DST IP: 0.0.0.0/0.0.0.0
> Interface: `'/................to `'/................
> Protocol: 0
> Flags: 00
> Invflags: 00
> Counters: 0 packets, 0 bytes
> Cache: 00000000
> Target name: `ERROR' [64]
> error=`ERROR'
>
> iptables: Invalid argument
>
> Now, being a total n00b (at least when it comes to these things),
> that doesn't tell me anything. :(
>
> Any hints?
>
> Cheers,
> Christian
> -
> To unsubscribe from this list: send the line "unsubscribe netfilter" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: New connlimit: how to use?

[Christian Lerrahn]

On Fri, 7 Dec 2007 08:56:47 +0100
<sadrafal@o2.pl> wrote:

> Do you see " kernel: ip_tables: connlimit match: invalid size 32 !=
> 16" in /var/log/messages ?
> Use the latest iptables snapshot (pom not needed) - problem fixed
> Kernel 2.6.24-rc4
> iptables v1.4.0rc1-20071205

No, I don't see any message like that in the logs. But I'll give the new
kernel and iptables versions a shot sometime. Thanks for the hint.

Cheers,
Christian

IPIP decapsulation

[Shaun Mccullagh]

Hi,

I'm trying to a assemble a simple web director consisting of a Director
at Location A, one Real Server at Location B and one Real Server at
Location C

The locations are about 30 miles apart.

The Director periodically checks that Real Server B is available. If for
any reason it is not, all browser requests are forwarded to Real Server
C until Real Server B has been repaired.

All systems are running CentOS 4.5 


                          Director A (62.101.52.99)
                              |    Virtual Server (62.101.52.106)
                              |
                              |
                              |
                              |
				Iptables Firewall (62.101.15.9)
                              |
			Real Server B (10.1.60.10)



The idea is Browser Requests are sent to the Web Director. This then
encapsulates the datagrams using IPIP and tunnels them to the IPtable
Firewall which is on the same LAN as Real Server B

I've setup a tunnel on the IP Tables firewall so that it can return the
datagrams to the client browser with the same source address as the
Director

The IP Addresses used on the Director are

eth0: inet 62.101.52.99/28 brd 62.101.52.111 scope global eth0
      inet 62.101.52.106/28 scope global secondary eth0  
      (This is used as a Virtual Server IP)

Ipvsadm looks like this on the Director:

Prot LocalAddress:Port Scheduler Flags
  -> RemoteAddress:Port           Forward Weight ActiveConn InActConn
TCP  62.101.52.106:80 wlc persistent 86400
  -> 62.101.15.9:80               Tunnel  1      4          0         

IPtables firewall uses
    inet 62.101.15.9/24 scope global secondary eth1.11
    inet 10.1.60.5/24 eth0.60

and

tun0@NONE: <POINTOPOINT,NOARP,UP> mtu 1480 qdisc noqueue 
    link/ipip 62.101.15.9 peer 62.101.52.99
    inet 62.101.52.106 peer 62.101.52.255/32 scope global tun2

This almost works.

The problem is I cannot figure out how to get the IPtables firewall to
forward the decapsulated datagrams to Real Server B. I believe this can
be done with mangling but I can't quite figure this out.

Please could someone explain how to do this?

Many thanks

Shaun


Here is my current NAT table

Chain PREROUTING (policy ACCEPT)
target     prot opt source               destination         
DNAT       tcp  --  0.0.0.0/0            62.101.15.9  dport 80
to:10.1.60.10

Chain POSTROUTING (policy ACCEPT)
target     prot opt source               destination         
SNAT       all  --  10.1.60.10           0.0.0.0/0
to:62.101.15.9

Input chain look like this

Chain INPUT (policy DROP)
target     prot opt source               destination         
ACCEPT     tcp  --  62.101.52.106         62.101.15.9   dport 80






Op dit e-mailbericht is een disclaimer van toepassing, welke te vinden is op http://www.xb.nl/disclaimer.html

Re: IPIP decapsulation

[Pascal Hambourg]

Hello,

Please do not reply to a message when you start a new discussion. This 
disrupts the existing thread and makes your message less visible.

Shaun Mccullagh a écrit :
> 
>                           Director A (62.101.52.99)
>                               |    Virtual Server (62.101.52.106)
>                               |
>                               |
> 				Iptables Firewall (62.101.15.9)
>                               |
> 			Real Server B (10.1.60.10)
> 
> The idea is Browser Requests are sent to the Web Director. This then
> encapsulates the datagrams using IPIP and tunnels them to the IPtable
> Firewall which is on the same LAN as Real Server B
> 
> I've setup a tunnel on the IP Tables firewall so that it can return the
> datagrams to the client browser with the same source address as the
> Director
> 
> The IP Addresses used on the Director are
> 
> eth0: inet 62.101.52.99/28 brd 62.101.52.111 scope global eth0
>       inet 62.101.52.106/28 scope global secondary eth0  
>       (This is used as a Virtual Server IP)
> 
> Ipvsadm looks like this on the Director:
> 
> Prot LocalAddress:Port Scheduler Flags
>   -> RemoteAddress:Port           Forward Weight ActiveConn InActConn
> TCP  62.101.52.106:80 wlc persistent 86400
>   -> 62.101.15.9:80               Tunnel  1      4          0         
> 
> IPtables firewall uses
>     inet 62.101.15.9/24 scope global secondary eth1.11
>     inet 10.1.60.5/24 eth0.60
> 
> and
> 
> tun0@NONE: <POINTOPOINT,NOARP,UP> mtu 1480 qdisc noqueue 
>     link/ipip 62.101.15.9 peer 62.101.52.99
>     inet 62.101.52.106 peer 62.101.52.255/32 scope global tun2
> 
> This almost works.
> 
> The problem is I cannot figure out how to get the IPtables firewall to
> forward the decapsulated datagrams to Real Server B. I believe this can
> be done with mangling but I can't quite figure this out.
> 
> Here is my current NAT table
> 
> Chain PREROUTING (policy ACCEPT)
> target     prot opt source               destination         
> DNAT       tcp  --  0.0.0.0/0            62.101.15.9  dport 80
> to:10.1.60.10

If I understand correctly (I have never used IPVS), IPIP encapsulating 
tunneling packets have source 62.101.52.99 and destination 62.101.15.9, 
and encapsulated TCP packets have source [the client address] and 
destination 62.101.52.106. So in the -d option I would put 62.101.52.106 
instead of 62.101.15.9.

> Input chain look like this
> 
> Chain INPUT (policy DROP)
> target     prot opt source               destination         
> ACCEPT     tcp  --  62.101.52.106         62.101.15.9   dport 80

In the filter/INPUT chain you must allow IPIP tunneling (protocol 4) 
instead of TCP. You must accept TCP port 80 from any to 10.1.6.10 in the 
filter/FORWARD chain, and symmetric return traffic from the server of 
course.

You may also need to disable source validation (rp_filter) on the tunnel 
interface tun0.

Re: New connlimit: how to use?

[Christian Lerrahn]

Hi,
I know that my original post (included in full above) is about 3 months
old. However, the problem remains unresolved. See below quoted bit for
some new information.

> I've seen that this question has been asked before but without reply.
> I'll therefore make another attempt to rephrase it.
> 
> I need connlimit on one of my boxes. For that I first tried kernel
> 2.6.22 with patch-o-matic which failed. The kernel dropped everything
> on a given port as soon as any rule was set for that port.
> 
> So, I decided to go to 2.6.23 and was delighted to see that connlimit
> is now included in the vanilla kernel. However, I realised that the
> structure is not the same as the patch produced. So I assumed that you
> would need the latest version of iptables. I therefore got iptables
> 1.4.0rc1 and compiled it. Generally speaking iptables works fine now.
> However, if I try to set a rule using connlimit, I get an error
> 
> "iptables: Invalid argument"
> 
> If I run e.g.
> 
> iptables -vv -A INPUT -p tcp --dport 80 -m connlimit
> --connlimit-above 32 -j DROP
> 
> I see the output
> 
> DROP  tcp opt -- in * out *  0.0.0.0/0  -> 0.0.0.0/0  tcp dpt:80
> #conn/32 > 32 libiptc v1.4.0rc1. 620 bytes.
> Table `filter'
> Hooks: pre/in/fwd/out/post = 0/0/148/296/0
> Underflows: pre/in/fwd/out/post = 0/0/148/296/0
> Entry 0 (0):
> SRC IP: 0.0.0.0/0.0.0.0
> DST IP: 0.0.0.0/0.0.0.0
> Interface: `'/................to `'/................
> Protocol: 0
> Flags: 00
> Invflags: 00
> Counters: 4598391 packets, 695123203 bytes
> Cache: 00000000
> Target name: `' [36]
> verdict=NF_ACCEPT
> 
> Entry 1 (148):
> SRC IP: 0.0.0.0/0.0.0.0
> DST IP: 0.0.0.0/0.0.0.0
> Interface: `'/................to `'/................
> Protocol: 0
> Flags: 00
> Invflags: 00
> Counters: 0 packets, 0 bytes
> Cache: 00000000
> Target name: `' [36]
> verdict=NF_ACCEPT
> 
> Entry 2 (296):
> SRC IP: 0.0.0.0/0.0.0.0
> DST IP: 0.0.0.0/0.0.0.0
> Interface: `'/................to `'/................
> Protocol: 0
> Flags: 00
> Invflags: 00
> Counters: 5476812 packets, 2506858579 bytes
> Cache: 00000000
> Target name: `' [36]
> verdict=NF_ACCEPT
> 
> Entry 3 (444):
> SRC IP: 0.0.0.0/0.0.0.0
> DST IP: 0.0.0.0/0.0.0.0
> Interface: `'/................to `'/................
> Protocol: 0
> Flags: 00
> Invflags: 00
> Counters: 0 packets, 0 bytes
> Cache: 00000000
> Target name: `ERROR' [64]
> error=`ERROR'
> 
> iptables: Invalid argument
> 
> Now, being a total n00b (at least when it comes to these things),
> that doesn't tell me anything. :(

One thing that I have found out in the meantime, however, is that I do
see something in my kernel logs which is

cannot load conntrack support for address family 2

and does help me just as much as the errors above because conntrack
seems to be in the kernel. I could only find an entry at Experts
Exchange about that but I don't have an account there and other than
that I couldn't find anything.

Does anybody know, what could cause the above error message?

Cheers,
Christian

Re: New connlimit: how to use?

[Jan Engelhardt]

On Mar 4 2008 13:52, Christian Lerrahn wrote:
>
>Hi,
>I know that my original post (included in full above) is about 3 months
>old. However, the problem remains unresolved. See below quoted bit for
>some new information.
>
>One thing that I have found out in the meantime, however, is that I do
>see something in my kernel logs which is
>
>cannot load conntrack support for address family 2
>
>and does help me just as much as the errors above because conntrack
>seems to be in the kernel.

Hmmm.... I'll see if I can reproduce that.

Re: New connlimit: how to use?

[Jan Engelhardt]

On Mar 9 2008 17:26, Jan Engelhardt wrote:
>On Mar 4 2008 13:52, Christian Lerrahn wrote:
>>
>>One thing that I have found out in the meantime, however, is that I do
>>see something in my kernel logs which is
>>
>>cannot load conntrack support for address family 2
>>
>>and does help me just as much as the errors above because conntrack
>>seems to be in the kernel.
>
>Hmmm.... I'll see if I can reproduce that.

No problem detected on my side. Make sure that conntrack *IS*
in the kernel or as a module, because you _definitely_
lack nf_conntrack_ipv4.