[tproxy] tproxy can't work with ip_conntrack

[Dong Wei]

Hi,

2008/10/23 NTPT <NTPT at seznam.cz>:
> I thing there is no need to track connction from client to TPROXY server.
>
> And what about to move -m socket match and other stuff to the raw conntrack table  and then use a -j NOTRACK target to selectively  do not conntrack connections from client to tproxy server, while other connections, include from tproxy server to the world , will be still conntracked ?
>
> please  execuse my wrong english

I think it's hard for us to check whether a TCP packet belongs to a
tproxy socket. When we receive a SYN from the client, we can't make
sure this packet belongs to a tproxy socket before the packet travel
to TPROXY target in mangle table PREROUTING chain.
Here is an sample:
iptables -t mangle -A PREROUTING -p tcp --dport 80 -j TPROXY \
--tproxy-mark 0x1/0x1 --on-port 50080
When TPROXY target handle the SYN packet, find the dport is 80, then
it will look up the tproxy socket listening on 50080.  But in raw
table we don't know which listening port should we take when we find
the SYN packet dport is 80.

I think maybe we need write a match like TPROXY, all the matched
packet do NOTRACK

>
> # ------------ Původní zpráva ------------
> # Od: KOVACS Krisztian <hidden at sch.bme.hu>
> # Předmět: Re: [tproxy] tproxy can't work with ip_conntrack
> # Datum: 22.10.2008 17:30:04
> # ----------------------------------------
> # 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.)
> #
> # --
> # KOVACS Krisztian
> # _______________________________________________
> # tproxy mailing list
> # tproxy at lists.balabit.hu
> # https://lists.balabit.hu/mailman/listinfo/tproxy
> #
> #
> #
>



-- 
Thanks
BR. Wei Dong