[tproxy] tproxy can't work with ip_conntrack

[Balazs Scheidler]

On Wed, 2008-10-22 at 16:59 +0200, KOVACS Krisztian wrote:
> Hi,
> 
> On sze, okt 22, 2008 at 04:11:09 +0800, Dong Wei wrote:
> > >> I think that we can add some new fields to identify the two HTTP
> > >> connections in ip_conntrack structure(one is Client->TPROXY Server,
> > >> and the other is TPROXY Server->HTTP Server).
> > >> I hope we can get the right conntrack when we just know the tuple
> > >> containing src_ip,src_port,dst_ip,dst_port. Because there is lots of
> > >> kernel code like this:
> > >>
> > >> 1. get the tuple 4 fields(src_ip,src_port,dst_ip,dst_port) from skb
> > >> 2. call: nf_conntrack_find_get(tuple) to find the corresponding ip_conntrack.
> > >> So in this case we can only know the 4 fields, we can't get any more
> > >> message from skb.
> > >>
> > >> Assuming there are 2 ip_conntrack:
> > >> [1]: 192.168.2.2:12345->192.168.1.2:80(client->TPROXY Server)
> > >> [2]: 192.168.2.2:12345->192.168.1.2:80(TPROXY Server->HTTP Server)
> > >> When we process TCP packets between client and TPROXY Server, we find
> > >> the conntrack for 192.168.2.2:123456->192.168.1.2:80, the result
> > >> should
> > >> be [1], and if the TCP packets belong to TPROXY Server and HTTP Server
> > >> connection, the result should be [2]
> > >>
> > >> Does anyone have good idea about the requirement mentioned above?
> > >
> > > I think most users work around the problem: you usually don't really
> > > need the source port to be preserved exactly and by choosing a different
> > > source port the problem goes away.
> > >
> > > (If you don't care about the source port then bind the socket to port 0
> > > and the kernel will choose an unused port.)
> > 
> > Thanks for your reply.  But, I think maybe this solution still have problems.
> > 
> > Here is a sample:
> > Client -> TPROXY Server (192.168.2.2:12345 ->192.168.1.2:80)
> > TPROXY Server -> HTTP Server(192.168.2.2:54321->192.168.1.2:80)
> > Now the two connections have different ip_conntrack. TPROXY Server use
> > port 54321 instead of 12345 as src port
> > 
> > Next time, the client connect to the HTTP Server
> > Client -> HTTP Server(192.168.2.2:54321 -> 192.168.1.2:80).
> > Now Client use the port 54321 connecting to 192.168.1.2:80(This is
> > common for a NAT server connecting to the same HTTP Server using
> > different src port)
> > When  TPROXY receive this packet, and find ip_conntrack. It will match
> > the old one - TPROXY Server -> HTTP Server.
> > 
> > This still exist the ip_conntrack conflict.
> 
> Yes, and unfortunately you can't do much about that if you're using
> connection tracking. (Except for implementing some method of
> differentiating between the two conntracks in ip_conntrack/nf_conntrack,
> of course.)
> 

Or using the NOTRACK target to exempt tproxied connections from
conntrack.

-- 
Bazsi