Re: UNTRACKED packets are identified as INVALID

[Pascal Hambourg <pascal.mail@plouf.fr.eu.org>]

Hello,

Sharon Tal a écrit :
> I have 2 web servers behind an iptables based load-balancer, and I'm trying
> to setup a graphics web server on the load-balancer, so that if a simple
> static file is requested it will be able to respond instead of forwarding
> the request to the web servers.
>  
> I've been trying to do that by matching packets at the raw table, setting
> them to be UNTRACKED and leaving them on the LB.
> The problem is that all UNTRACKED packets are identified as INVALID as soon
> as they get to the mangle chain and dropped.
> [...]
> # JPG requests should be answered by LB
> $IPTABLES -t raw -A PREROUTING -i $EXTFACE -p tcp --dport 80 -m string
> --algo bm --string "GET /" -m string --algo bm --string ".jpg HTTP/1." -j
> NOTRACK
> $IPTABLES -t mangle -A PREROUTING -i $EXTFACE -p tcp --dport 80 -m state
> --state UNTRACKED -j MARK --set-mark 0x11

IMHO, the packets caught by the NOTRACK target are not the same as the 
packets in the INVALID state. The important thing is that only the 
individual packet containing the string will have the UNTRACKED state, 
not the whole connection. Allow me to guess what happens.

A SYN packet starting a new connection is received by the load-balancer. 
It contains no data, so it cannot match the NOTRACK rule. The conntrack 
creates a new entry for that connection. Then the packet - and the whole 
connection - is DNATed to one web server, and the conntrack entry is 
updated accordingly. This means that all subsequent incoming packets 
identified by the conntrack as belonging to that connection will be 
DNATed to the same web server.

The 3-way TCP handshake (SYN/ACK from the server, ACK from the client) 
completes. Then comes the packet carrying the HTTP request containing 
the string. This packet is UNTRACKED, so it is not DNATed and reaches 
the TCP layer of the load balancer. But it is not a SYN packet, and it 
does not match any local socket because the local TCP layer did not see 
the 3-way handshake. So it is dropped, maybe triggering a TCP RST packet 
back to the client (not sure about that).

I guess that the segment being UNTRACKED may disturb the TCP sequence 
number tracking, so at some point subsequent segments may be considered 
INVALID.

Anyway, NOTRACK won't do what you want. You can't change the destination 
of a whole TCP connection after it has started. I'm afraid that the only 
way to achieve what you want is to set up load balancing using a reverse 
proxy instead of NAT.