October 2003 - tproxy - lists.balabit.hu

tproxy development version 1.1.3
by KOVACS Krisztian 31 Oct '03

31 Oct '03

Hi, Development version 1.1.3 of tproxy has been released. This version contains no new features, but has some bugs fixed: - TF_NAT_ONCE was not working properly - two possible conntrack entry leaks fixed It contains a few cosmetic fixes to the code and the documentation also, and quite a few debugging-related changes. The experimental NAT entry reuse patch is still in the package, however, please do not use it unless you really have to. As always, the package is available from http://www.balabit.com/downloads/tproxy/linux-2.4/devel/ MD5 checksum of cttproxy-2.4.22-1.1.3.tar.gz: 61ac02d7b2b6cd99300b66596ae059c0 -- Regards, Krisztian KOVACS

2 2

UDP transparent proxying
by Jean-pierre Cartal 29 Oct '03

29 Oct '03

Hello, I'm trying to write a transparent UDP proxy using TProxy, what I would like to do is to intercept traffic going to a given machine, and only one, and then resend it with the original source IP address, but with a different port number. I'm able to bind to a local socket, and receive traffic originally destinated to the given machine using the ITP_LISTEN flag. My first question is should I also use the ITP_UNIDIR option on this socket ? My problem is when I try to forward the received packet to the originally targeted machine, source and destination addresses are not the one given through the IP_TPROXY_ASSIGN socket option and the connect system call. I took the code from the foreign-udp-connect.c sample given with the patch, but it does not behave correctly within my code whereas it is working fine when tested by itself. Do you have any clue on what I'm doing wrong here ? Thanks.

2 4

Re: Getting Started
by Tim Burress 24 Oct '03

24 Oct '03

Well, the first problem is solved and the iptables rules now work fine. It turned out to be a permissions problem on one of the scripts used during the build. This just leaves the interaction between tproxy and IP masquerade when the latter is defined on a particular interface. Any suggestions for the best way to deal with that? Thanks! Tim __________________________________ Do you Yahoo!? The New Yahoo! Shopping - with improved product search http://shopping.yahoo.com

1 0

Getting Started
by Tim Burress 23 Oct '03

23 Oct '03

Hello! I'm just getting started with tproxy on our local firewall machine, and am running into a couple of problems. The 1.1.2 patches seem to install just fine, and after explicitly loading iptable_proxy, ipt_tproxy, and ipt_TPROXY, I am able to set up rough transparent proxies using the setsockopt() API. The first problem is that the extensions to the iptables command itself do not seem to be recognized: [router] iptables # iptables -t tproxy -A PREROUTING -j TPROXY --on-port 10110 iptables v1.2.9rc1: Unknown arg `--on-port' Try `iptables -h' or 'iptables --help' for more information. Is there some other module that I have to load in order for iptables to recognize the tproxy options? The second problem is that the firewall currently uses a MASQUERADE rule that rewrites address from hosts on the local network (private addresses) to the global address of the outgoing interface. This works fine with non-transparent proxies, but when I set one up in transparent mode (using the setsockopt() calls) the outgoing packets from the local network are not masqueraded. As a result, the server is seeing packets with private source addresses, which of course it cannot reply to. Is there a way around this? Obviously the benefits of transparent proxying are lost if you do masquerading, for all traffic, but in our case it only applies to certain interfaces, while the other networks have routable addresses. It seems as though, in this case, the masquerade rules might take precedence? Thanks for any insight you can provide! Tim __________________________________ Do you Yahoo!? The New Yahoo! Shopping - with improved product search http://shopping.yahoo.com

1 0

tproxy development version 1.1.2
by KOVACS Krisztian 21 Oct '03

21 Oct '03

Hi, Development version 1.1.2 of the transparent proxying patch has been released. This version contains no new features, but has some bugs fixed: - endless loop in related list handling fixed - in some cases, UDP conntrack entries did not get deleted when the socket was unassigned - connection tracking entry deletion comparison functions cleaned up - now all log messages generated by the kernel module begin with IP_TPROXY The experimental NAT entry reuse patch is also in the package, however, you only need it if you experience a lot of unsuccessful NAT mappings (see kernel logs). As always, the package is available from http://www.balabit.com/downloads/tproxy/linux-2.4/devel/ MD5 checksum of cttproxy-2.4.22-1.1.2.tar.gz: 0997c5fe057aa7505cb2dbda2bcb565b -- Regards, Krisztian KOVACS

1 0

(no subject)
by Jon Nelson 10 Oct '03

10 Oct '03

Howdy I have a few questions about tproxy. I'm using cttproxy-2.4.21-23 For both questions I am talking about performing non-local binds using the established procedure: bind locally setsockopt(ASSIGN) setsockopt(LISTEN|CONNECT or'd with ONCE) call listen or connect as appropriate. Problem #1: assume a process has gone through the steps of locally binding, calling setsockopt(ASSIGN) and setsockopt(LISTEN|ONCE) but has /not/ called 'listen' on the socket. If the process ends abruptly, the iptable_tproxy module refuses to unhash the socket: IP_TPROXY_UNASSIGN: not unhashing socket, 0100007f:2080, sr=c083c100, proto=6, sk->state=7, sr->flags=10003 The relevant code is near line 868, and I believe the test: (sk->state != TCP_LISTEN) is too specific. In the above sock, the state was TCP_CLOSE. Should TCP_CLOSE, TCP_CLOSE_WAIT, and/or TCP_CLOSING be added (I'm inclined to think that /just/ TCP_CLOSE)? Issue #2: assume a machine with 4 interfaces (if you include lo). Binding locally to any of the 3 non-lo addresses works just fine. However, why does (the initial local) binding to either 0 (INADDR_ANY) or 127.0.0.1 not work? -- What do you call a fish with no eyes? A fsh. Jon Nelson <jnelson-tproxy(a)securepipe.com>

2 1

tproxy development version 1.1.1
by KOVACS Krisztian 10 Oct '03

10 Oct '03

Hi, The first version from the development branch (1.1) of tproxy has been released. This version has substantially reworked connection tracking entry deletion, and comes with an experimental patch to the Netfilter NAT and connection tracking code to make reusing of addresses used by TIME_WAIT connections possible. The contents of the patch_tree subdirectory: * 01-tproxy-1.1.1.diff - the transparent proxying patch, you should apply at least this one. * 02-nat_conntrack_delete.diff - experimental patch for Netfilter NAT, use if you get a lot of "error applying NAT mapping" errors, and please report experiences to the mailing list. The userspace-kernel interface is unchanged, so it is compatible with the stable versions. The patch is for Linux 2.4.22, and because of submitted changes in Netfilter NAT and conntrack code, may not work with later kernels. Although it has passed basic tests and appears to be working, it is still experimental, so use with care. Testing on heavily loaded and/or SMP boxes would be appreciated, just send bugreports to the tproxy mailing list. (We are interested in all kinds of problems, not just oopses: strange looking error/warning messages in your kernel logs, etc.) The package is available from http://www.balabit.com/downloads/tproxy/linux-2.4/devel/ MD5 checksum of cttproxy-2.4.22-1.1.1.tar.gz: 5b2c505df3a32c7b30ec64193b6bbd72 -- Regards, Krisztian KOVACS

1 0

tproxy 0.25 released
by Kovacs Krisztian 06 Oct '03

06 Oct '03

Hi, The newest version of tproxy has been released. Changes include: * fixes bugs introduced in 0.24 by the new foreign port allocation method * fixed assignment of a socket with unspecified foreign port Workaround for the "socket already assigned" errors is still needed: if you have lots of these messages in your logs, try net_tcp_autobind_fix.diff. While this patch fixes the problem, and we've found no side effects of applying, it's somewhat experimental, handle with care. The patch has been tested on 2.4.22, which has some problems in the Netfilter core, so please apply 63_getorigdst-tuple-zero.patch. This has been included in the tproxy patch tarball to make life easier: you don't have to check it out from the Netfilter CVS tree. As always, the newest patch is available at http://www.balabit.com/downloads/tproxy/linux-2.4/ -- Regards, Krisztian KOVACS

1 0