- tproxy - lists.balabit.hu

Test version 1.2.0.1 released
by KOVACS Krisztian 04 Jun '04

04 Jun '04

Hi, Almost six months has passed since the release of TProxy 1.2.0, and a couple of problems were found in that release. Unfortunately, some of those problems could not be fixed trivially, so that before releasing a stable 1.2.1 version, extensive testing would be needed. This test version is an up-to-date snapshot of the current code, with all known important problems fixed: * introduction of shared sockrefs for mark-only entries, this fixes the "clashing entries" problem which occured in special cases of operation * new method for maintaining the per-sockref related connections list, now connections are added only at confirmation-time * fix order of registration of hooks and the 'tproxy' table, when the iptable_tproxy module was loaded on high traffic sites, it could oops Testing would be highly appreciated, especially since some of these changes are not lightweight at all, and I can't be sure that they don't break anything. This release is available on our website: http://www.balabit.com/downloads/tproxy/linux-2.4/test/ MD5 checksum of cttproxy-2.4.25-1.2.0.1.tar.gz: a5c27546299e7e6f3911994d78ceae37 -- Regards, Krisztian KOVACS

1 0

VLANs with TPROXY
by Robert Monsen 10 May '04

10 May '04

I want to use a single linux server to set up a set of independent proxies on different vlans, using the tproxy module to provide transparency. My question is whether the tproxy module keeps separate mapping tables for different chains, or whether it's a global map. The issues is that I want to support independent ip addressing on each of the vlans. It's a 2.4.26 kernel running a proxy application, similar to squid. Thanks, Bob Monsen

1 0

Development version 1.9.4 released
by KOVACS Krisztian 06 May '04

06 May '04

Hi, A new version of the development branch of TProxy has been released. Major changes include the fix of a possible connection tracking entry leak, and some cleanups in the code handling related list of sockref. The 04-nat_delete patch is optional, and needs Jozsef Kadlecsik's TCP-window-tracking patch, it won't apply otherwise. (Use Netfilter Pathc-o-Matic NG.) The other three patches can be applied with or without the TCP-window-tracking patch. The release can be downloaded from http://www.balabit.com/downloads/tproxy/linux-2.4/devel/ MD5: 726bac8ed91f6958825bc3eb8664cfba cttproxy-2.4.25-1.9.4.tar.gz MD5: 3857307202fa6e77c04882eced634525 cttproxy-2.6.5-1.9.4.tar.gz -- Regards, Krisztian KOVACS

1 0

RE: [tproxy] cttproxy-2.4.25-1.9.3 + nat_delete
by Andrew Ivins 27 Apr '04

27 Apr '04

Thanks Krisztian, you were spot on :) The test program can now connect repeatedly without problems. Thanks also for updating your patch, although I'll hold off on using nat_delete as you suggest. Regards, Andrew -----Original Message----- From: KOVACS Krisztian [mailto:hidden@balabit.hu] Sent: Tuesday, 27 April 2004 4:01 PM To: Andrew Ivins Cc: TProxy mailing list Subject: Re: [tproxy] cttproxy-2.4.25-1.9.3 + nat_delete Hi, On Tue, 2004-04-27 at 09:22, Andrew Ivins wrote: > I have experimented with binding to a foreign source address using > cttproxy-2.4.25-1.9.3 and the foreign-tcp-connect program. However I > skipped the nat_delete part of the patch as I was not able to apply > it. Foreign-tcp-connect actually works perfectly with the peer seeing > the spoofed address. However after working, it will consistently fail > for several minutes. Then it will work once and the cycle will repeat. > I'm guessing this has something to do with the nat_delete patch I > skipped. Actually, 04-nat_delete is not mandatory at all (although could help in your case). The root of your problems is probably that you set the foreign address and port number to the same constant value all the time, and connect to the same server. In this case, when the first TCP session is closed, you'll have to wait two minutes for the conntrack entry to time out. Instead of using 04-nat_delete to be able to delete leftover conntrack entries of TCP connections currently in TIME_WAIT state, I'd recommend not to use constant values when using tproxy for connecting. If you specify 0 for the foreign port, an unused port number will be automatically allocated by Netfilter, and you won't get NAT clashes. The 04-* patch is needed in such cases when this is not an option, which is very rare. > > The nat_delete patch has been adapted to the new TCP window-tracking > > patch by Jozsef Kadlecsik, so this patch needs the current > > tcp-window-tracking module from the Netfilter Patch-o-matic NG > applied. > > If you don't want do do that, 04-nat_delete.patch can be skipped > safely. > > I tried this. The tcp-window-tracking patch seemed to apply to the > vanilla 2.4.25 kernel successfully. However the 04-nat_delete.patch > still fails to apply (included below) > > Any chance of a list of the which patches need to be applied to make > cttproxy-2.4.25-1.9.3 apply cleanly including 4-nat_delete.patch? You're right. Although I wouldn't recommend using that patch, I've created a fixed archive which contains the new 04-nat_delete.diff and replaced the old .tar.gz. The MD5 checksum of the new file is 64eb5a4e72f11fa98d7794ed0bb8ee2a cttproxy-2.4.25-1.9.3.tar.gz -- Regards, Krisztian KOVACS

1 0

cttproxy-2.4.25-1.9.3 + nat_delete
by Andrew Ivins 27 Apr '04

27 Apr '04

Hi, this may be a question for KOVACS Krisztian: I have experimented with binding to a foreign source address using cttproxy-2.4.25-1.9.3 and the foreign-tcp-connect program. However I skipped the nat_delete part of the patch as I was not able to apply it. Foreign-tcp-connect actually works perfectly with the peer seeing the spoofed address. However after working, it will consistently fail for several minutes. Then it will work once and the cycle will repeat. I'm guessing this has something to do with the nat_delete patch I skipped. From the mailing list archives: > The nat_delete patch has been adapted to the new TCP window-tracking > patch by Jozsef Kadlecsik, so this patch needs the current > tcp-window-tracking module from the Netfilter Patch-o-matic NG applied. > If you don't want do do that, 04-nat_delete.patch can be skipped safely. I tried this. The tcp-window-tracking patch seemed to apply to the vanilla 2.4.25 kernel successfully. However the 04-nat_delete.patch still fails to apply (included below) Any chance of a list of the which patches need to be applied to make cttproxy-2.4.25-1.9.3 apply cleanly including 4-nat_delete.patch? Regards, Andrew /usr/src/linux# patch -p1 < ../cttproxy-2.4.25-1.9.3/patch_tree/04-nat_delete.diff patching file net/ipv4/netfilter/ip_conntrack_core.c Hunk #1 FAILED at 357. 1 out of 4 hunks FAILED -- saving rejects to file net/ipv4/netfilter/ip_conntrack_core.c.rej patching file net/ipv4/netfilter/ip_nat_core.c Hunk #2 succeeded at 285 with fuzz 1. patching file net/ipv4/netfilter/ip_conntrack_proto_tcp.c patching file net/ipv4/netfilter/ip_conntrack_standalone.c Hunk #1 FAILED at 508. 1 out of 1 hunk FAILED -- saving rejects to file net/ipv4/netfilter/ip_conntrack_standalone.c.rej patching file include/linux/netfilter_ipv4/ip_conntrack.h Hunk #3 FAILED at 263. 1 out of 3 hunks FAILED -- saving rejects to file include/linux/netfilter_ipv4/ip_conntrack.h.rej

2 1

Re: [tproxy] Patch errors on vanilla kernels?
by David 24 Apr '04

24 Apr '04

(I accidently sent this mail to Balazs earlier today. Was checking the message, and found out I didn't send it to the mailinglist. Sorry to Balazs for that) "for example ..." Do you use any other patch or is this tcp-window-tracking patch the only one? And shouldn't dependencies be in the README file? I have no clue which patches to install before I can use the TProxy patches. David Balazs Scheidler said: >> Applying the patches on my system fails. I've tried several different versions: >> cttproxy-2.4.25-1.2.0 on a vanilla Linux 2.4.25 kernel >> cttproxy-2.4.25-1.9.3 on a vanilla Linux 2.4.25 kernel >> cttproxy-2.6.3-1.9.2 on a vanilla Linux 2.6.3 kernel >> cttproxy-2.6.5-1.9.3 on a vanilla Linux 2.6.3 kernel >> All patches fail. The best option is cttproxy-2.4.25-1.2.0, which only generates one error, that may possibly be fixed by hand (ip_contrack.h). The worst option is cttproxy-2.6.5-1.9.3, which generates dozens of errors. >> >> Do you use pre-patched (red hat, suse) kernels or something? I don't know >> what else could have caused these problems. Does anyone know this problem? > > no, we are using vanilla kernels, but tproxy also has a couple of dependencies. (for example the latest 1.9.3 releases need > tcp-window-tracking from Jozsef Kadlecsik)

2 1

failure to apply snat mapping?
by Lennert Buytenhek 23 Apr '04

23 Apr '04

Hi, Let's say that I have an app that connects to IP address 1.2.3.4, and uses tproxy to fake the source address as 5.6.7.8. Bind the socket, then call into tproxy, and then connect() and ta da -- everything works as expected. Now I decide that that app should not connect to 1.2.3.4, but instead to 1.2.3.5. I don't want to modify the source and restart it, so I add a nat rule in the iptables nat/OUTPUT chain to DNAT the address to 1.2.3.5. The app now (unknowingly) connects to 1.2.3.5, that works fine. But.. the source address used for the connection is now the source address of the box and not anymore 5.6.7.8? :(( Is this a case of "Don't do that, then!!"? I'm using "tproxy-2.4.22-1.1.3.diff" patched into a Red Hat 2.4.20 kernel (2.4.20-20.9 to be exact) on a uniproc P4 2.4GHz, 1G RAM. cheers, Lennert

2 3

Patch errors on vanilla kernels?
by David 22 Apr '04

22 Apr '04

Hi, Applying the patches on my system fails. I've tried several different versions: cttproxy-2.4.25-1.2.0 on a vanilla Linux 2.4.25 kernel cttproxy-2.4.25-1.9.3 on a vanilla Linux 2.4.25 kernel cttproxy-2.6.3-1.9.2 on a vanilla Linux 2.6.3 kernel cttproxy-2.6.5-1.9.3 on a vanilla Linux 2.6.3 kernel All patches fail. The best option is cttproxy-2.4.25-1.2.0, which only generates one error, that may possibly be fixed by hand (ip_contrack.h). The worst option is cttproxy-2.6.5-1.9.3, which generates dozens of errors. Do you use pre-patched (red hat, suse) kernels or something? I don't know what else could have caused these problems. Does anyone know this problem?

2 1

dynamic proxying?
by Qiang zhang 16 Apr '04

16 Apr '04

Hello, List I hope this question is not bothering, Can i use the tproxy with iptables to make a dynamic proxying? by this I mean if an incoming connection is seen not going anywhere (i.e. there is no service/server available), I want to add a proxy rule dynamically so the connection will be redirect to another fixed IP Is this at all do-able by using TPROXY? Please shed some idea, thanks a bunch! Q __________________________________ Do you Yahoo!? Yahoo! Tax Center - File online by April 15th http://taxes.yahoo.com/filing.html

1 0

Development version 1.9.3 released
by KOVACS Krisztian 07 Apr '04

07 Apr '04

Hi, A new version of the current TProxy development branch has been released. Support of Linux 2.4 is back, although through two completely indenpendent patch sets. There were a couple of compilation problems with 1.9.2, and a few ugly initialization bugs, which caused the iptable_tproxy module to cause oopses at load. With the help of James MacLean, these bugs seem to be solved. (For more information, see ChangeLog.) The nat_delete patch has been adapted to the new TCP window-tracking patch by Jozsef Kadlecsik, so this patch needs the current tcp-window-tracking module from the Netfilter Patch-o-matic NG applied. If you don't want do do that, 04-nat_delete.patch can be skipped safely. The documentation is still not up-to-date, unfortunately. The release can be downloaded from http://www.balabit.com/downloads/tproxy/linux-2.4/devel/ MD5: cttproxy-2.4.25-1.9.3.tar.gz eb3b5a4880a68c87e5340643b171ee20 MD5: cttproxy-2.6.5-1.9.3.tar.gz d64c3bcaae81f08b804ce910dbdb752a -- Regards, Krisztian KOVACS

1 0