November 2010 - tproxy - lists.balabit.hu

tproxy for locally originating connections
by Adriel Gomboc 03 Dec '10

03 Dec '10

Hello, I am new to the list, and couldn't find this discussed in the archives: I would like to use tproxy to proxy locally originating connections (on Linux). AFAIK there is a problem with doing this : the tproxy target is only valid in the mangle table, in the prerouting chain; and locally originating traffic (i.e. traffic originating from some client application running on the same host as the tproxy service) does not pass through the prerouting chain and presumably therefore cannot be tproxied. May I ask, am I right in the above, and if so, can anyone offer a work-around? Kind regards, Adriel Gomboc

2 1

Tproxy Bandwidth limit
by Luiz Biazus 13 Nov '10

13 Nov '10

hello guys, Is it true that tproxy has a bandwidth limit of 80mb/s on linux? bst rgds Luiz

3 3

Re: [tproxy] tproxy Digest, Vol 64, Issue 1
by hugo＠gigared.com 10 Nov '10

10 Nov '10

Dear Mr Biazus: i tested Tproxy patch under linux (2.6.31.6-166) up to 180Mbps. pay attention on the amount of sockets permitted by your tcp config. in linux are under the sysctl.conf , to reach a reasonable bandwith , i have these settings: net.ipv4.netfilter.nf_conntrack_max = 131070 net.ipv4.netfilter.nf_conntrack_expect_max = 131070 net.ipv4.netfilter.ip_conntrack_tcp_timeout_estabilished=600 net.ipv4.netfilter.ip_conntrack_udp_timeout=60 net.ipv4.netfilter.ip_conntrack_udp_timeout_stream=180 net.netfilter.nf_conntrack_max = 131070 net.netfilter.nf_conntrack_expect_max = 131070 net.netfilter.ip_conntrack_tcp_timeout_estabilished=600 net.netfilter.ip_conntrack_udp_timeout=60 net.netfilter.ip_conntrack_udp_timeout_stream=180 >From whoses that dont know or dont like to recompile the kernel , i have it compiled in a rpm for Fedora 12, and the versions 3.1.0.14/3.1.8/3.1.9 of squid patched in rpm format too. i dont post the link to download due my personal server bandwith limitations but from who needs i have those files as the instructions for installing to Regards, Hugo Petrucci Mensaje citado por tproxy-request(a)lists.balabit.hu: > Send tproxy mailing list submissions to > tproxy(a)lists.balabit.hu > > To subscribe or unsubscribe via the World Wide Web, visit > https://lists.balabit.hu/mailman/listinfo/tproxy > or, via email, send a message with subject or body 'help' to > tproxy-request(a)lists.balabit.hu > > You can reach the person managing the list at > tproxy-owner(a)lists.balabit.hu > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of tproxy digest..." > > > Today's Topics: > > 1. Tproxy Bandwidth limit (Luiz Biazus) > 2. Re: Kernel Panic/System Hang when using TPROXY with 2.6.27 or > later (KOVACS Krisztian) > 3. Re: Tproxy Bandwidth limit (KOVACS Krisztian) > > > ---------------------------------------------------------------------- > > Message: 1 > Date: Mon, 8 Nov 2010 20:53:15 -0200 > From: Luiz Biazus <luiz(a)biazus.com> > Subject: [tproxy] Tproxy Bandwidth limit > To: tproxy(a)lists.balabit.hu > Message-ID: > <AANLkTimBWR0tDWca00KWABczF0QOrXfrrGyO2SOwQy+v(a)mail.gmail.com> > Content-Type: text/plain; charset=ISO-8859-1 > > hello guys, > > > Is it true that tproxy has a bandwidth limit of 80mb/s on linux? > > > bst rgds > > Luiz > > > ------------------------------ > > Message: 2 > Date: Tue, 09 Nov 2010 07:47:10 +0100 > From: KOVACS Krisztian <hidden(a)balabit.hu> > Subject: Re: [tproxy] Kernel Panic/System Hang when using TPROXY with > 2.6.27 or later > To: FREY Oliver <FREY.O(a)ikarus.at> > Cc: tproxy(a)lists.balabit.hu > Message-ID: <1289285230.4570.6.camel(a)nienna.balabit> > Content-Type: text/plain; charset="UTF-8" > > Hey Oliver, > > On Thu, 2010-10-28 at 10:26 +0200, FREY Oliver wrote: > > sorry for my late reply, we had some delays in compiling and deploying the > kernel. > > I took the diffs from the Website and created a .patch-File which then > could be applied to to the vanilla 2.6.35.7-Kernel-Source without issues - is > there a more efficient way to retrieve all the diffs for a commit in one > file? > > Sure, you can get the whole patch as-is via the web interface. > > This is the patch you want: > http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h… > > You can get a .patch file containing all the fixes related to these > files by clicking on the 'patch' link at the top of the page: > > http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=patch;h=… > > > Are there any CONFIG_DEBUG-options you can recommend to be set just in case > we run into issues again, or to see if there are any issues left? > > Well, apart from enabling linked list debugging and SLUB debugging I > don't think any of those would be of much use. > > > As the machines previously never survived more than 72 hours without > crashing, by next week I will definitely know if the issue is fixed, and I'll > report back then. > > For now, thanks for your great and very quick support! > > Do you have any update on this? How did your testing go? > > Cheers, > Krisztian > > > > > ------------------------------ > > Message: 3 > Date: Tue, 09 Nov 2010 07:49:03 +0100 > From: KOVACS Krisztian <hidden(a)balabit.hu> > Subject: Re: [tproxy] Tproxy Bandwidth limit > To: Luiz Biazus <luiz(a)biazus.com> > Cc: tproxy(a)lists.balabit.hu > Message-ID: <1289285343.4570.8.camel(a)nienna.balabit> > Content-Type: text/plain; charset="UTF-8" > > Hi, > > On Mon, 2010-11-08 at 20:53 -0200, Luiz Biazus wrote: > > Is it true that tproxy has a bandwidth limit of 80mb/s on linux? > > I don't think that's true -- I'd definitely consider that to be a > problem that should be fixed as soon as possible. > > Cheers, > Krisztian > > > > > ------------------------------ > > _______________________________________________ > tproxy mailing list > tproxy(a)lists.balabit.hu > https://lists.balabit.hu/mailman/listinfo/tproxy > > > End of tproxy Digest, Vol 64, Issue 1 > ************************************* > ------------------------- www.gigared.com

1 0

Re: [tproxy] Kernel Panic/System Hang when using TPROXY with 2.6.27 or later
by KOVACS Krisztian 10 Nov '10

10 Nov '10

Hi, On Tue, 2010-11-09 at 08:54 -0800, Ken Simpson wrote: > >> sorry for my late reply, we had some delays in compiling and deploying the kernel. > >> I took the diffs from the Website and created a .patch-File which then could be applied to to the vanilla 2.6.35.7-Kernel-Source without issues - is there a more efficient way to retrieve all the diffs for a commit in one file? > > > > Sure, you can get the whole patch as-is via the web interface. > > > > This is the patch you want: > > http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h… > > Quick question: now that the patch is in Linus' kernel tree, does this mean it will appear in a mainline kernel release soon? How does that process work? It has been merged in Linus' tree after 2.6.36 was released and it was already present in 2.6.37-rc1, so 2.6.37 will be the first stable release with the patch (and IPv6 support in tproxy) included. Cheers, Krisztian

1 0

Re: [tproxy] Kernel Panic/System Hang when using TPROXY with 2.6.27 or later
by KOVACS Krisztian 09 Nov '10

09 Nov '10

Hey Oliver, On Thu, 2010-10-28 at 10:26 +0200, FREY Oliver wrote: > sorry for my late reply, we had some delays in compiling and deploying the kernel. > I took the diffs from the Website and created a .patch-File which then could be applied to to the vanilla 2.6.35.7-Kernel-Source without issues - is there a more efficient way to retrieve all the diffs for a commit in one file? Sure, you can get the whole patch as-is via the web interface. This is the patch you want: http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h… You can get a .patch file containing all the fixes related to these files by clicking on the 'patch' link at the top of the page: http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=patch;h=… > Are there any CONFIG_DEBUG-options you can recommend to be set just in case we run into issues again, or to see if there are any issues left? Well, apart from enabling linked list debugging and SLUB debugging I don't think any of those would be of much use. > As the machines previously never survived more than 72 hours without crashing, by next week I will definitely know if the issue is fixed, and I'll report back then. > For now, thanks for your great and very quick support! Do you have any update on this? How did your testing go? Cheers, Krisztian

1 0