Port based mangling trouble

[Chad Clark]

I am certainly willing to use existing work.  I believe LVS uses a round-
robin and/or load based method of selecting a real server.  I understand 
that this could cause problems with session variables.  This thinking 
lead to the idea of using the client's IP to determine the real server.  
(Also I would like to find a stateless solution.)

IP tables does not seem to have the ability to jump based on selected 
bits of the source IP beyond simple matches. (eg. the mod of N, where N 
is the number of real servers that are running.)  If this is not the case 
please point me in the right direction.

I did think that I would be able to use the u32 selector from tc (to mark 
packets for iptable rules) however I'm told the tc filters come after 
iptables in the stack.

I also understand that iptable hooks are available to allow userspace 
programs to filter/mangle (in my case mark) packets.  That doesn't seem 
much different from what I attempted in my earier module however I expect 
it to be slower due to copying into and out of user space.  The real 
problem is I have been told that once a user land proccess handles a 
packet the packet can't be passed on to other rules (so it can't be sent 
to DNAT).  This does sound odd and again if it is not the case please let 
me know.

I must confess I had not thought about fragmented packets and the TCP 
port.  I may be back where I started looking for a solution.  Any other 
input would be appreciated.

Cheers, Chad


-----Original Message-----
From: Henrik Nordström <hno@marasystems.com>
To: "Chad Clark" <chad@webcorelabs.com>, netfilter-devel@lists.samba.org
Date: Sun, 18 Nov 2001 22:12:10 +0100
Subject: Re: Port based mangling trouble

> I don't have a answer to your question, but:
> 
> What is wrong with using the Netfiler provided NAT framework? Why
> reinvent it 
> all again?
> 
> There is a lot more to NAT than only changing IP addresses of the
> packets. 
> You also need to deal with at least
> a) Fragmented packets
> b) Related ICMP packets
> 
> Plain IP based NAT may work fine without these if you stick to the IP
> level, 
> but by inspecting port numbers you are up into the TCP levels which is
> more 
> than IP. The Netfilter NAT framework has mostly all one need for any
> kind of 
> NAT, but are lacking a little in selection mechanisms..
> 
> There is also another NAT implementation ontop of the Netfilter
> provided 
> packet hoos: IPVS <http://www.linuxvirtualserver.org/>, duplicating
> much of 
> the complexity of NAT but in a different manner than the "native"
> Netfiler 
> implementation.
> 
> Regards
> Henrik Nordstrom
> 
> 
> 
> On Sunday 18 November 2001 21.07, Chad Clark wrote:
> > Hi All,
> >
> > So far the following function hooks to NF_IP_PRE_ROUTING and seems to
> > redirect to the selected IP
> > okay.  The problem is when I telnet from 10.10.1.8 to 10.10.1.252:80.
> > Looking at tcpdump on 10.10.7.2 I see the requests comming in (to
> > 10.10.7.2) but don't see any ACK's going back.  When I telnet from
> > the virtual server (ie requests come from 10.10.7.1) to 10.10.7.2:80
> > tcpdump shows the connection going through (in fact 'GET /' works).
> >
> > It looks like the real sever (10.10.7.2) is droping the packets.  I'm
> > guessing that the checksums don't match up.  Can anyone comfirm this
> > or fill me in on what I'm missing?
> >
> > Thanks, Chad Clark
> >
> >
> > /* file: cnf_hack.c
> >    details: should rewrite incoming port 80 tcp trafic to one of 2
> >    ip's based on the least signifigant bit of the source IP ADDR. 

 <--- snip --->