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: IPIP decapsulation

[Shaun Mccullagh]

Thanks to Pascal I have now got the whole system working for plain http

I've assembled a simple web director using Keepalived and iptables
consisting of
 
1 x Director at Location A 
1 x Real Server at Location B
1 x Real Server atLocation 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)



Browser Requests are sent to the Web Director. Keepalived uses LVS to
encapsulate the datagrams using IPIP and tunnel them to an IPtables
Firewall. The Real Server B is on the same LAN as the iptables firewall

The IP Addresses used on the Director are

eth0: inet 62.101.52.99/28 brd 62.101.52.111 scope global eth0
          (this is the source address used by IPIP encapsulation)

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

LVS 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

A tunnel interface and tunnel were created on the firewall

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


The ip command was used to create an endpoint for the tunnel created by
the Director. The kernel can then decapsulate the datagrams
 
ip tunnel add tun2 mode ipip remote 62.100.52.99 local 62.101.15.9

A tunnel interface for tun2 was then configured with a dummy endpoint: 

ifconfig tun2 62.101.52.106 pointopoint 62.100.52.255

This is required so that the kernel can use the source address
62.101.52.106 when 
it returns the datagrams to the client browser.


Iptables looks like this

Chain PREROUTING (policy ACCEPT)
target     prot opt source               destination         
DNAT       tcp  --  0.0.0.0/0              dport 80 62.101.52.106
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.52.106


Chain FORWARD (policy DROP)
target     prot opt source               destination
ACCEPT     tcp  --  0.0.0.0/0            10.1.60.10   dport 80

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

Finally the RP filter must be disabled on the tunnels for the tunnel to
work

sysctl -w net.ipv4.conf.tun2.rp_filter=0


Keepalived config looks like this

vrrp_instance VI_0 {
        state MASTER
        interface eth1
        lvs_sync_daemon_interface eth1
        track_interface {
                eth0
        }
        virtual_router_id 3
        priority 100
        advert_int 5
        authentication {
                auth_type PASS
                auth_pass xxxxxx
        }
        virtual_ipaddress {
                62.101.52.106/28 dev eth0
        }
        garp_master_delay 1
        smtp_alert
}



virtual_server 62.101.52.106 80 {
   delay_loop 20
   lb_algo wlc
   lb_kind TUN
   persistence_timeout 86400
   protocol TCP

  
   real_server 80.242.34.68 80 {
       weight 1
       # check real server on port 80, real server must respond
       # within 20 seconds
       TCP_CHECK {
          connect_port 80
          connect_timeout 20
       }
       # Real server will be removed from the pool after 3 retries
       nb_get_retry 3
       # Daemon will wait 2 seconds before retrying
       delay_before_retry 2
   }
  sorry_server 62.101.15.9 80
}

virtual_server 62.101.52.106 443 {
   delay_loop 20
   lb_algo wlc
   lb_kind TUN
   persistence_timeout 86400
   protocol TCP

   real_server 80.242.34.68 443 {
       weight 1
       # check real server on port 80, real server must respond
       # within 20 seconds
       TCP_CHECK {
          connect_port 80
          connect_timeout 20
       }
       # Real server will be removed from the pool after 3 retries
       nb_get_retry 3
       # Daemon will wait 2 seconds before retrying
       delay_before_retry 2
   }
  sorry_server 62.101.15.9 443
}





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

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.