[tproxy] I'm having a little trouble binding a tproxy and I might do something wrong.

[KOVACS Krisztian]

Hi,

On 12/20/2012 06:54 PM, Eliezer Croitoru wrote:
> Hello,
> 
> I am writing a small proxy and while trying to use tproxy I am getting a 
> problem while I am not sure I am doing it right.
> 
> The server accepts the connection and identify the two ends.
> But when I try to connect using the client IP and PORT I am getting 
> error "Connection timed out - connect(2)"
> while on netstat I am getting two sockets:
> tcp        0      1 192.168.10.100:51573    81.218.79.155:80        SYN_SENT
> tcp      287      0 81.218.79.155:80        192.168.10.100:51573 
> ESTABLISHED
> 
> The upper one is the server "connect" which seems to stuck like that 
> with no response.
> 
> This problem accrues only when I try to bind the same ip and port of the 
> client.
> When I use other random port as src port for the forged connection I can 
> connect and everything is fine.
> 
> I might be doing something wrong but since I have no clue.

I think this might be the limitation of Netfilter's connection tracking
code. Do you have connection tracking enabled?

If so, the problem is that while you have two distinct TCP connections
in the TCP stack, the connection tracking code is using exclusively the
connection endpoint addresses as the key for its own state table and
thus tries to use only a single conntrack entry for your two TCP
connections.

I have seen exactly this problem before and you have a few options:

* do not use connection tracking (not always an option)
* use connection tracking but use connection tracking zones to have the
two separate conntrack state tables (https://lwn.net/Articles/370152/)
* you can combine connection tracking zones with a custom hack
(involving introducing a new socket flag for sockets on which connect()
has been called and extending the socket match so that you can select a
conntrack zone based on that flag)

Unfortunately not using the same source port is not an ultimate
solution, either: if you use a random source port you still have a
chance that it will clash with the endpoint of another existing TCP
connection.

-- 
KOVACS Krisztian