- tproxy - lists.balabit.hu

Problem with foreign connect using tproxy4
by Pranav Desai 30 Oct '08

30 Oct '08

Hello, I am trying to do a foreign connect with tproxy4. Here is what I have tried so far, seems like I have missed a few things since its not working for me. After applying the kernel patch for 2.6.24.7, I can get the pkts going out using a foreign address, I also see the syn ack pkts coming back from the server on the client machine, but client doesn't send an ack back. I am guessing that I missed something with the iptables rules ? The README suggests that I have to set the following rules and do the setsockopt for the foreign connect. iptables -t mangle -N DIVERT iptables -t mangle -A PREROUTING -p tcp -m socket -j DIVERT iptables -t mangle -A DIVERT -j MARK --set-xmark 0x1/0xffffffff iptables -t mangle -A DIVERT -j ACCEPT For me the --set-xmark fails with: iptables v1.4.0: Unknown arg `--set-xmark' Try `iptables -h' or 'iptables --help' for more information. I have applied the tproxy patch for iptables-1.4.0 Here is my mangle table. The UNKNOWN match seems suspicious. Chain PREROUTING (policy ACCEPT 258K packets, 36M bytes) pkts bytes target prot opt in out source destination 138 11024 DIVERT tcp -- * * 0.0.0.0/0 0.0.0.0/0 UNKNOWN match `socket' Chain INPUT (policy ACCEPT 75192 packets, 11M bytes) pkts bytes target prot opt in out source destination Chain FORWARD (policy ACCEPT 0 packets, 0 bytes) pkts bytes target prot opt in out source destination Chain OUTPUT (policy ACCEPT 62722 packets, 11M bytes) pkts bytes target prot opt in out source destination Chain POSTROUTING (policy ACCEPT 62722 packets, 11M bytes) pkts bytes target prot opt in out source destination Chain DIVERT (1 references) pkts bytes target prot opt in out source destination 32 2096 ACCEPT all -- * * 0.0.0.0/0 0.0.0.0/0 What am I missing here ? I would appreciate any help I can get. Also, are there any pointers explaining the different between tproxy2 and 4. Thanks -- Pranav

2 3

tproxy can't work with ip_conntrack
by Dong Wei 26 Oct '08

26 Oct '08

Hi,all When I use a transparent proxy application using tproxy, I find there is something wrong when I load ip_conntrack module Here is a sample: network topology(router mode): Client[192.168.2.2]--------[192.168.2.1]TPROXY Server[192.168.1.1]--------[192.168.1.2]HTTP Server 1. Client try to connect to HTTP Server, and TPROXY Server redirect the traffic to itself. Now the conntrack is: ORIG: 192.168.2.2:12345->192.168.1.2:80 REPLY:192.168.1.2:80->192.168.2.2 After 3 way handshake the connection between Client and TPROXY server should be in ESTABLISHED state 2. TPROXY Server connect to HTTP Server using fake src ip and src port. Now the SYN packet should be 192.168.2.2:12345->192.168.1.2:80. But kernel find there is an old ip_conntrack entry for this SYN packet whose state is ESTABLISHED So, kernel will drop the SYN packet, and delete the old entry 3. SYN packet will be retransmitted after 1 sec on TPROXY Server. And then kernel will allocate an new entry for this SYN packet. 4. After 3 way handshake between TPROXY Server and HTTP Server, this ip_conntrack entry should be in ESTABLISHED state 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? -- Thanks BR. Wei Dong

4 7

Re: [tproxy] TProxy patch for 2.6.26 and Squid 3.HEAD news (heads-up)
by Arun Srinivasan 22 Oct '08

22 Oct '08

Hi all, This is to confirm that the NF-SNAT functionality with tproxy4 is working with no issues for the scenarios mentioned below: Details of packages used: Kernel version: 2.6.26 Tproxy version: tproxy4-2.6.26-200809262032 iptables version: tproxy-iptables-1.4.0-20080521-113954-1211362794 Squid version: squid-3.HEAD-20081021 Scenarios: 1. Full transparency - Yes 2. Full transparency with SNAT (NF - POSTROUTING) - Yes 3. Client-side transparency (interception only) - Yes I didn't test this with bridging enabled. Regards, Arun S. 2008/10/1 KOVACS Krisztian <hidden(a)sch.bme.hu>: > Hi, > > On Wed, Oct 01, 2008 at 05:20:10PM +0530, Arun Srinivasan wrote: >> Hi, >> >> Should I take iptables source patch from the git repo or this patch >> tproxy-iptables-1.4.0-20080521-113954-1211362794.patch would do? > > It's okay, however it won't apply to iptables version 1.4.1 or above. > > -- > KOVACS Krisztian > -- Regards, Arun S.

2 1

Need your input regarding some issue with tproxy (may not be related to tproxy)
by Pranav Desai 17 Oct '08

17 Oct '08

Hello, We have a http proxy server which is in full transparent mode using tproxy 2.0.6 + kernel 2.6.20.15. The iptables rule to redirect port 80 traffic from clients is: 574K 34M REDIRECT tcp -- * * 0.0.0.0/0 0.0.0.0/0 tcp dpts:80:82 redir ports 8001 8001 is our proxy port. We use tproxy to send connections to web servers using the clients IP. Using setsockopt(TPROXY_ASSIGN) ... The server is at around 240req/s. Most of the time its working fine i.e. I see a lot of traffic on port 80 going out using the clients IP, but I see quite a few pkts going out using src port 8001 (trace below). The rate is not as high port 80 traffic, but still high enough to be a concern. The interesting thing is I don't see any pkts destined to port 8001. I have been monitoring this server for an entire day. Hence, I am guessing that at times for some reason tproxy is not able to assign the foreign address and just uses the local address:port ... Any ideas or suggestions on how I should go about debugging this. Or whether I should be looking somewhere other than the tproxy module. Its a production server, so I can't get the client side traces, but I can get more info from the server. Let me know if you need any other information. I would really appreciate any help I can get. Thanks -- Pranav Here is a small part of the trace using (tcpdump -vvv -nn -i bond1 port 8001) =========================================================== 03:15:19.915737 IP (tos 0x0, ttl 64, id 28888, offset 0, flags [DF], proto 6, length: 40) 10.10.224.6.8001 > 10.1.1.8.4849: F [tcp sum ok] 4133498992:4133498992(0) ack 3495097709 win 7290 03:15:22.180160 IP (tos 0x0, ttl 64, id 12306, offset 0, flags [DF], proto 6, length: 40) 10.10.224.6.8001 > 10.1.1.8.4826: F [tcp sum ok] 4117981558:4117981558(0) ack 2998309917 win 9310 03:15:24.578292 IP (tos 0x0, ttl 64, id 65515, offset 0, flags [DF], proto 6, length: 40) 10.10.224.6.8001 > 10.1.2.47.1106: F [tcp sum ok] 4086941566:4086941566(0) ack 3480965117 win 6432 03:15:25.064570 IP (tos 0x0, ttl 64, id 38848, offset 0, flags [DF], proto 6, length: 40) 10.10.224.6.8001 > 10.1.3.131.1044: F [tcp sum ok] 4055165713:4055165713(0) ack 3713243767 win 9648 03:15:27.232857 IP (tos 0x0, ttl 64, id 17142, offset 0, flags [DF], proto 6, length: 40) 10.10.224.6.8001 > 10.1.1.8.4888: F [tcp sum ok] 4134874226:4134874226(0) ack 2610855931 win 7380 03:15:30.079850 IP (tos 0x0, ttl 64, id 13364, offset 0, flags [DF], proto 6, length: 1185) 10.10.224.6.8001 > 10.1.4.49.46316: P 22595600:22596733(1133) ack 805897755 win 1746 <nop,nop,timestamp 24258316 3379834444> 03:15:31.089784 IP (tos 0x0, ttl 64, id 37000, offset 0, flags [DF], proto 6, length: 40) 10.10.224.6.8001 > 10.1.3.131.1045: F [tcp sum ok] 4053960032:4053960032(0) ack 1538769655 win 6432 03:15:36.686007 IP (tos 0x0, ttl 64, id 3070, offset 0, flags [DF], proto 6, length: 40) 10.10.224.6.8001 > 10.1.1.8.4824: F [tcp sum ok] 4120796002:4120796002(0) ack 2440799003 win 10992 03:15:37.229926 IP (tos 0x0, ttl 64, id 60997, offset 0, flags [DF], proto 6, length: 52) 10.10.224.6.8001 > 10.1.1.86.2288: F [tcp sum ok] 4164262937:4164262937(0) ack 3891303954 win 7497 <nop,nop,timestamp 24260104 27180085> 03:15:37.802145 IP (tos 0x0, ttl 64, id 60433, offset 0, flags [DF], proto 6, length: 40) 10.10.224.6.8001 > 10.1.1.8.4816: F [tcp sum ok] 4105151875:4105151875(0) ack 189658004 win 6432

3 5

tproxy performance
by Ravi Valmikam 15 Oct '08

15 Oct '08

Hi All Any of you aware of any tproxy performance data? Specifically, any extra latency it adds to packet processing (% is fine). Our testing seems to add significant latency (3ms on base 2-3 ms in non transparent proxy mode). Does it make sense? Thanks Ravi

4 4

TProxy patch for 2.6.26 and Squid 3.HEAD news
by KOVACS Krisztian 01 Oct '08

01 Oct '08

Hi, During the last few days Balazs and me have been working on getting TProxy 4.1 and Squid3's support for it into a better shape. Balazs has fixed the ICMP issue that was definitely the most important item on our to-do list and I was working with Amos Jeffries from the Squid team to fix problems with Squid's tproxy support. So anyone who had problems with tproxy 4.1 or Squid in the past please give it another try: download the latest snapshot of Squid 3.HEAD from the Squid site (http://www.squid-cache.org/Versions/v3/HEAD/) and our latest snapshot of tproxy (http://people.netfilter.org/hidden/tproxy/tproxy4-2.6.26-200809262032.tar.b…) Also, you can get a patched iptables source from Balazs's git repository (git clone git://git.balabit.hu/bazsi/iptables-tproxy.git) which contains the user-space support for the 'socket' match and the 'TPROXY' target. The Squid wiki has a page on how to configure Squid (http://wiki.squid-cache.org/Features/Tproxy4) as well as a howto (http://wiki.squid-cache.org/ConfigExamples/TPROXYPatchingCentOS) -- KOVACS Krisztian

2 2

Squid support
by Pablo Sebastián Greco 26 Sep '08

26 Sep '08

I've just updated for me, the squid2.7STABLE4 patch based on the squid2.6. Please let me know if it works for you

2 2

tproxy support for iptables > 1.4.0
by Ritter, Nicholas 25 Sep '08

25 Sep '08

Is there tproxy patch support for iptables 1.4.1 and/or 1.4.1.1? I just tried to patch against both and got errors when using the tproxy-iptables-1.4.0-20080521-113954-1211362794.patch <http://www.balabit.com/downloads/files/tproxy/tproxy-iptables-1.4.0-200 80521-113954-1211362794.patch> patch file.

3 3

Inclusion of tproxy 4.x in mainline kernel
by Igmar Palsenberg 25 Sep '08

25 Sep '08

Hi, Is there a TODO list that lists what is keeping tproxy from beeing included in the mainline kernel ? It's features are quite usefull, and inclusion in a vanilla kernel saves us a whole lot of manual patching :) Regards, Igmar

3 6

port=0 ERROR ASSIGN
by Richard Smith 23 Sep '08

23 Sep '08

Hello Guys, Sorry i'm late, but recently set up a squid on a debian box patched with tproxy and compiled iptables like you did and everything seems woking except this error message on the cache log about the "port=0 ERROR ASSIGN". tproxy ip=179.166.10.3,0x3017477,port=0 ERROR ASSIGN can't connect to the outside if the tproxy iptables rules loaded. Googled for some answer but no succes. If this issue is solved any kind of help would be much appreciated, Thanks and more power.

3 2