January 2007 - tproxy - lists.balabit.hu

reuse connection
by Eyal Rundstein 17 Jan '07

17 Jan '07

Hi, I am using kernel 2.4.32 with TPROXY 2.0.5. My application is a transparent proxy. My client opens a connection to the proxy and a transparent connection is opened to the server. Now my application closes the server connection and FIN is sent to the server. The server does not reply with FIN. (it is down). The connection goes to FIN_WAIT1 state (netstat). The client connection stays open and I try to reestablish the backend connection with the same client (source IP/port) parameters. The problem is that I can not reestablish the connection for about 60-80 seconds. It seems that the entry of the connection is not cleared so I can not reuse the connection. 1) Is there a way I can delete the entry as soon as the FIN is sent? 2) Is there a timeout I can change to shorten the time I need to wait before reusing the connection? Thanks in advance, E.R

1 0

tproxy LISTEN proxy does not work.
by Yoshioka Tsuneo 16 Jan '07

16 Jan '07

Hello When I tried to listen proxy using tproxy like following, it does not work to be intented. Structure: Client <===> Proxy <===> Server 1. On Proxy, listen on the port 9999. 2. On Proxy, assign Server:2000 using TPROXY_ASSIGN, and set ITP_LISTEN flag. 3. Client connect to Server:2000. 4. Proxy steal connection using tproxy.(using ITP_LISTEN) 5. Proxy connect to Server:2000. On "4.", Proxy should connect server:2000 on "4.". But, actually, proxy connect to Proxy:9999. Packet capturing result is like following. (*) line is "5.". It should be like "10.65.3.100.47886 > 10.65.3.110.2000". ========================================================= 13:12:30.957695 10.65.1.208.5495 > 10.65.3.110.2000: S 2155077236:2155077236(0) win 65535 <mss 1460,nop,nop,sackOK> (DF) 13:12:30.957821 10.65.1.208.5495 > 10.65.3.100.9999: S 2155077236:2155077236(0) win 65535 <mss 1460,nop,nop,sackOK> (DF) 13:12:30.957837 10.65.3.110.2000 > 10.65.1.208.5495: S 754591780:754591780(0) ack 2155077237 win 5840 <mss 1460,nop,nop,sackOK> (DF) [ttl 1] 13:12:30.957860 10.65.3.110.2000 > 10.65.1.208.5495: S 754591780:754591780(0) ack 2155077237 win 5840 <mss 1460,nop,nop,sackOK> (DF) [ttl 1] 13:12:30.957874 10.65.1.208.5495 > 10.65.3.110.2000: . ack 1 win 65535 (DF) 13:12:30.957884 10.65.1.208.5495 > 10.65.3.100.9999: . ack 754591781 win 65535 (DF) (*)13:12:30.958069 10.65.3.100.47886 > 10.65.3.100.9999: S 765420716:765420716(0) win 5840 <mss 1460,sackOK,timestamp 1284404 0,nop,wscale 2> (DF) 13:12:30.958096 10.65.3.110.2000 > 10.65.3.100.47886: S 756210562:756210562(0) ack 765420717 win 32768 <mss 16396,sackOK,timestamp 1284404 1284404,nop,wscale 2> (DF) [ttl 1] 13:12:30.958116 10.65.3.100.47886 > 10.65.3.100.9999: . ack 756210563 win 1460 <nop,nop,timestamp 1284404 1284404> (DF) 13:12:30.958152 10.65.3.100.47886 > 10.65.3.100.9999: P 0:10(10) ack 1 win 1460 <nop,nop,timestamp 1284404 1284404> (DF) 13:12:30.958164 10.65.3.110.2000 > 10.65.3.100.47886: . ack 11 win 8192 <nop,nop,timestamp 1284404 1284404> (DF) [ttl 1] ========================================================= IP address is like following. Client: 10.65.1.208 Proxy: 10.65.3.100 Server: 10.65.3.110 Test code is attached. I have confirmed the issue on both: "linux-2.6.19.1" with "cttproxy-2.6.19-2.0.6" and "linux-2.4.31" with "cttproxy-2.4.31-2.0.2" I guess that the connection is NAT'ed. But I cannot find the way to connect Server:2000. This scenario happens while ftp data connection. For about ftp itself, using ip_nat_ftp seems solve the issue. But, can I get any information(reason, advice), if possible ? Thank you ! -- (Nihon F-Secure Corporation) Yoshioka Tsuneo E-MAIL: Tsuneo.Yoshioka(a)f-secure.com

2 2

NAT to TPROXY convertion rules
by zulkarnain 15 Jan '07

15 Jan '07

Hi, I'm running tproxy with the squid server in different box, my topology look like this: [Client]-------[Squid]---[tproxy/FW]----[Web server] 192.168.1.3 192.168.1.2 192.168.1.1 192.168.2.2 192.168.2.1 [squid] - tproxy patched kernel and iptables-1.3.6 [tproxy/FW]: iptables -t tproxy -A PREROUTING -i eth0 -s ! 192.168.1.2 -m tcp -p tcp --dport 80 -j TPROXY --on-port 3128 --on-ip 192.168.1.2 with the config above, my squid not running well. I read on "Transparent Proxy with Linux and Squid mini-HOWTO" there are some rules I've to configure which is; iptables -t nat -A PREROUTING -i eth0 -s ! squid-box -p tcp --dport 80 -j DNAT --to squid-box:3128 iptables -t nat -A POSTROUTING -o eth0 -s local-network -d squid-box -j SNAT --to iptables-box iptables -A FORWARD -s local-network -d squid-box -i eth0 -o eth0 -p tcp --dport 3128 -j ACCEPT the problem is some of those rule are not compatible with tproxy table, is there any guide on how to convert it to tproxy rules? any help would be greatly appreciated. regards, Zul __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com

2 1

TProxy version 2.0.6 released
by KOVACS Krisztian 08 Jan '07

08 Jan '07

Hi, TProxy version 2.0.6 has been released for Linux 2.4.33, 2.4.34, 2.6.16, 2.6.17, and 2.6.18, 2.6.19, and 2.6.20-rc3. (I hope the 2.6.20-rc3 patches will work for final 2.6.20 kernels, too). Because of the severity of problems discovered all TProxy users are advised to upgrade. This release fixes multiple serious problems discovered since the 2.0.5 release: * an SMP race condition possibly leading to memory corruption in the nat_delete patch (reported and fixed by torinet.co.kr user wckwon) Linux 2.6 specific bugs: * a serious problem related to the TCP time-wait socket unassign callback leading to referencing invalid memory addresses Linux 2.4 specific problems fixed: * a possible kernel hang (deadlock) if the NAT reservations and NAT delete patches are both applied * an interaction between the iptables TPROXY and REJECT rule which could lead to kernel oopses if UDP packets have been first TPROXY-ed and later REJECT-ed The release tarballs are available here: http://www.balabit.com/downloads/tproxy/ MD5 checksums of the tarballs: 3c46dee353f89fee8b3f414fbed63ff4 cttproxy-2.4.33-2.0.6.tar.gz 32287de5cdc31a185139ebec1e33e848 cttproxy-2.4.34-2.0.6.tar.gz 93e98b78cf52269541958ac92feba1d0 cttproxy-2.6.16-2.0.6.tar.gz 9bd1e7fd942886feb2df697b7483eda0 cttproxy-2.6.17-2.0.6.tar.gz a23b9ae57ff6d6b5b8b2550dd1177b1e cttproxy-2.6.18-2.0.6.tar.gz 8dbe1a3d19c87c104cbdb62b4ce1f035 cttproxy-2.6.19-2.0.6.tar.gz f6204b588fe6c42f1a78c41dc039b1ad cttproxy-2.6.20-2.0.6.tar.gz -- Regards, Krisztian Kovacs

1 1

TPROXY 2.0.5 with NAT reservations deadlocks on 2.4.33.3
by Lior Dotan 02 Jan '07

02 Jan '07

Hi, I'm running TPROXY 2.0.5 compiled with the NAT reservations patch on 2.4.33.3. >From time to time the machine freezes. I was able to capture the following stack trace: Stack traceback for pid 0 0x403b2000 0 0 1 0 R 0x403b2370 *swapper EBP EIP Function (args) 0x403b3bd8 0x40107e23 __write_lock_failed+0xf (0x60ad9300, 0x140, 0x58e55214, 0x 58b74a68, 0x58b74a68) kernel .text 0x40100000 0x40107e14 0x40107e34 0x608c0e03 [iptable_nat].text.lock.ip_nat_core+0x6d iptable_nat .text 0x608be060 0x608c0d96 0x608c0eb 0 0x608bf5d1 [iptable_nat]ip_nat_reserved_unregister_all+0x31 (0x58e552 14) iptable_nat .text 0x608be060 0x608bf5a0 0x608bf67 0 0x403b3be4 0x608bf681 [iptable_nat]ip_nat_reserved_cleanup_expect+0x11 (0x58e552 14, 0x58e55214) iptable_nat .text 0x608be060 0x608bf670 0x608bf69 0 0x403b3bf4 0x608a7bb9 [ip_conntrack]destroy_expect+0x29 (0x58e55214, 0x58e55214) ip_conntrack .text 0x608a7060 0x608a7b90 0x608a7b c0 0x403b3c04 0x608a7dc8 [ip_conntrack]__unexpect_related+0x68 (0x58e55214, 0x58e55 214) ip_conntrack .text 0x608a7060 0x608a7d60 0x608a7d d0 0x403b3c14 0x608a7e00 [ip_conntrack]unexpect_related+0x30 (0x58e55214, 0x58b74a1 0, 0x403b3d60, 0x0) ip_conntrack .text 0x608a7060 0x608a7dd0 0x608a7e 10 0x403b3c2c 0x608a7e7e [ip_conntrack]remove_expectations+0x6e (0x58b74a10, 0x1, 0 x58b74a10) ip_conntrack .text 0x608a7060 0x608a7e10 0x608a7e 80 0x403b3c40 0x608a7eea [ip_conntrack]clean_from_lists+0x6a (0x58b74a10, 0x58b74a3 4) ip_conntrack .text 0x608a7060 0x608a7e80 0x608a7f 00 0x403b3c50 0x608a81d5 [ip_conntrack]death_by_timeout+0x55 (0x58b74a10, 0x5a7805b 4, 0x1d6002c, 0x1500, 0x1d6002d) ip_conntrack .text 0x608a7060 0x608a8180 0x608a82 30 0x403b3c74 0x608bf73a [iptable_nat]ip_nat_used_tuple+0xaa (0x403b3d60, 0x5a7805b 4, 0x1, 0x1, 0x608c4a00) iptable_nat .text 0x608be060 0x608bf690 0x608bf74 0 0x403b3cbc 0x608bfd5c [iptable_nat]get_unique_tuple+0xcc (0x403b3d60, 0x403b3d30 , 0x403b3d9c, 0x5a7805b4, 0x0) iptable_nat .text 0x608be060 0x608bfc90 0x608bfeb 0 0x403b3d7c 0x608bff11 [iptable_nat]ip_nat_setup_info+0x61 (0x5a7805b4, 0x403b3d9 c, 0x0, 0x0, 0x608c48a0) iptable_nat .text 0x608be060 0x608bfeb0 0x608c023 0 0x403b3dc4 0x608beacb [iptable_nat]ip_nat_rule_find+0xab (0x403b3ec8, 0x0, 0x60a d9300, 0x0, 0x5a7805b4) iptable_nat .text 0x608be060 0x608bea20 0x608beae 0 0x403b3df8 0x608be1a5 [iptable_nat]ip_nat_fn+0x145 (0x0, 0x403b3ec8, 0x60ad9300, 0x0, 0x4025a270) iptable_nat .text 0x608be060 0x608be060 0x608be2f 0 0x403b3e20 0x608be331 [iptable_nat]ip_nat_in+0x41 (0x0, 0x403b3ec8, 0x60ad9300, 0x0, 0x4025a270) iptable_nat .text 0x608be060 0x608be2f0 0x608be37 0 0x403b3e48 0x4024c175 nf_iterate+0x65 (0x404e35c0, 0x403b3ec8, 0x0, 0x60ad9300, 0x0) kernel .text 0x40100000 0x4024c110 0x4024c190 0x403b3e84 0x4024c552 nf_hook_slow+0xc2 (0x2, 0x0, 0x403b3ec8, 0x60ad9300, 0x0) kernel .text 0x40100000 0x4024c490 0x4024c690 0x403b3ec0 0x4025a02c ip_rcv+0x45c (0x5ee7e4c4, 0x60ad9300, 0x403ab390, 0x60ad93 00, 0x4040ee2c) kernel .text 0x40100000 0x40259bd0 0x4025a0e0 0x403b3ee0 0x402429a8 netif_receive_skb+0x148 (0x5ee7e4c4, 0x1a5220, 0x4040ee20, 0x40, 0x4040ef10) kernel .text 0x40100000 0x40242860 0x40242a80 0x403b3f04 0x40242b0a process_backlog+0x8a (0x4040ee4c, 0x403b3f20, 0x1a5220, 0x 4040ee20, 0x0) kernel .text 0x40100000 0x40242a80 0x40242bb0 0x403b3f30 0x40242c7a net_rx_action+0xca (0x4040e8f0, 0x46, 0x0, 0x403b3f44, 0x4 040a980) kernel .text 0x40100000 0x40242bb0 0x40242d30 0x403b3f54 0x40120339 do_softirq+0x109 (0xc, 0x403b3f84, 0x5eee0424, 0x180, 0x0) kernel .text 0x40100000 0x40120230 0x40120370 0x403b3f7c 0x4010b396 do_IRQ+0x106 (0x40107210, 0x5b06e000, 0x403b2000, 0x403b20 00, 0x403b2000) kernel .text 0x40100000 0x4010b290 0x4010b3b0 0x403b3fb8 0x4010de68 call_do_IRQ+0x5 (0x1, 0xa0600, 0x40105000) kernel .text 0x40100000 0x4010de63 0x4010de70 0x401072d2 cpu_idle+0x52 (0x40105090, 0x0, 0x10e00) kernel .text 0x40100000 0x40107280 0x401072f0 0x403b3fe0 0x40105044 stext+0x44 (0x402bd6c0, 0x40413440, 0x0, 0x40413340) kernel .text 0x40100000 0x40105000 0x40105060 0x403b3ff8 0x403b49ab start_kernel+0x15b kernel .text.init 0x403b4000 0x403b4850 0x403b4a10 Is this a known issue with TPROXY 2.0.5?

4 4