- tproxy - lists.balabit.hu

Re: [tproxy] MAC and VLAN transparency
by Balazs Scheidler 16 Jul '07

16 Jul '07

On Sun, 2007-07-15 at 18:01 +0200, Jan Engelhardt wrote: > On Jul 15 2007 17:38, Balazs Scheidler wrote: > >On Wed, 2007-07-11 at 14:58 -0600, Cameron Schaus wrote: > >> I am using tproxy to do source IP address transparency on our proxy, > >> and it is working well. I would like to extend the functionality of > >> tproxy to provide source MAC address and VLAN transparency as well. > >> The proxy in question runs as a transparent bridge, so I think that I > >> have to integrate the tproxy framework with ebtables, but I'm not 100% > >> sure how to go about that. > > ebtables -t nat -A POSTROUTING -m <some_condition> > -j snat --to-source <orig_mac> > > Simple :) > (you'd still need arpreply, and something like connmark, so that you can > properly can figure out orig_mac). This is not so much of a tproxy job IMO. Yes, but you don't know 'orig_mac', it depends on the incoming connection. For example, you have two clients, each going through a tproxy based proxy. On the outgoing side, each would need to have its original MAC address, and without having to establish a rule for each client. -- Bazsi

1 0

Re: [tproxy] Compile error with cttproxy-2.6.20-2.0.6, 2.6.20 kernel
by Pranav Desai 30 Jun '07

30 Jun '07

On 6/30/07, Jan Engelhardt <jengelh(a)computergmbh.de> wrote: > > On Jun 29 2007 12:17, Pranav Desai wrote: > > > > =========== ERROR ============ > > CC [M] net/ipv4/netfilter/ip_nat_core.o > > net/ipv4/netfilter/ip_nat_core.c:49: warning: 'kmem_cache_t' is deprecated > > net/ipv4/netfilter/ip_nat_core.c: In function '__ip_nat_reserved_new_hash': > > net/ipv4/netfilter/ip_nat_core.c:322: error: 'hash' undeclared (first > > use in this function) > > net/ipv4/netfilter/ip_nat_core.c:322: error: (Each undeclared > > identifier is reported only once > > net/ipv4/netfilter/ip_nat_core.c:322: error: for each function it appears in.) > > make[3]: *** [net/ipv4/netfilter/ip_nat_core.o] Error 1 > > make[2]: *** [net/ipv4/netfilter] Error 2 > > make[1]: *** [net/ipv4] Error 2 > > make: *** [net] Error 2 > > Replace kmem_cache_t by "struct kmem_cache". > Thats just the warning. The error is with hash being not declared, its 'h' in the code, but the 3rd patch changes that back to 'hash' and does a bunch of other changes, of which I am not sure about. Thanks -- Pranav > > Jan > -- > -- ------------------------------ http://pd.dnsalias.org

1 0

Compile error with cttproxy-2.6.20-2.0.6, 2.6.20 kernel
by Pranav Desai 29 Jun '07

29 Jun '07

Hello, I am trying to compile the cttproxy-2.6.20-2.0.6 with the 2.6.20 kernel, and I get the compile error given below. This is the case only when I apply the following patches. 01-nat_reservations.patch 02-tproxy.patch If I apply the third patch it compiles fine. 03-nat_delete.patch But the README suggests that I probably dont need the third patch. Is the README outdated or am I doing something wrong. Is is ok to add the 03 patch ? I have enabled tproxy as a module and nat reservation is compiled in the kernel. Thank you for your time. -- Pranav =========== ERROR ============ CC [M] net/ipv4/netfilter/ip_nat_core.o net/ipv4/netfilter/ip_nat_core.c:49: warning: 'kmem_cache_t' is deprecated net/ipv4/netfilter/ip_nat_core.c: In function '__ip_nat_reserved_new_hash': net/ipv4/netfilter/ip_nat_core.c:322: error: 'hash' undeclared (first use in this function) net/ipv4/netfilter/ip_nat_core.c:322: error: (Each undeclared identifier is reported only once net/ipv4/netfilter/ip_nat_core.c:322: error: for each function it appears in.) make[3]: *** [net/ipv4/netfilter/ip_nat_core.o] Error 1 make[2]: *** [net/ipv4/netfilter] Error 2 make[1]: *** [net/ipv4] Error 2 make: *** [net] Error 2 -- ------------------------------ http://pd.dnsalias.org

1 0

sockref leak problem
by Daniel 29 Jun '07

29 Jun '07

hi, Recently I tested tproxy with Avanlanche (about 800M/s stress) and some result below: 1. deadlock when ip_conntrack_ftp loaded. Plz see my last post and explaination from Balazs Scheidler. 2. I tested again without nat_reservation(deadlock disappeared). After 10 hours' stress test, kernel kept giving out exactly the same messages repeatedly: IP_TPROXY: socket already assigned, reuse=1, 0a0ba8c0:4c86, sr->faddr=e80ba8c0:0000, flags=10000, sr->tv_hashed=1181425010:475244912 My questions: Is this sockref leaked? and, what is the situation when a sockref is leaked? Thanks! Daniel 2007-06-10

3 8

tproxy patching error
by Dharam Paul 21 Jun '07

21 Jun '07

I am running slackware11. (kernel : 2.4.33.3 I have downloaded the cttproxy-2.4.33-2.0.5.tar.gz I am trying to patch the above mentioned tproxy patch to the above mentioned kernel. I have followed the following steps: Extracted cttproxy patch to a folder. Then I passed the following commands: #cd /usr/src/linux #for i in <pathtocttproxy>/patch_tree/*.diff; do cat $i | patch -p1; done. The patching is done but it gave some errors with the message that rejects are saved to file net/ip4/netfilter/ip_conntrack_core.core. Being a Linux noob and enthuasist, I have the following questions, Have I passed the command correctly? Is tproxy patch installed, and can I proceed further? If not how to get rid of these errors? Secondly as suggested in the readme, I can not find the Directory /usr/src/iptables-1.3.5 Please help me solve the issue. Best Regards

1 0

Check if kernal has inbuildt Tproxy support
by Dharam Paul 20 Jun '07

20 Jun '07

OS: Fedora 7 Can I check if the linux kernel has tproxy patch built into it? If yes how? TIA. Regards

2 1

Re: tproxy Digest, Vol 24, Issue 4
by Lior Dotan 12 Jun '07

12 Jun '07

Hi, I'm having the same problem with sockref leak with tproxy 2.0.6 running on kernel 2.4.33, with nat reservation patch applied. > Date: Tue, 12 Jun 2007 11:21:17 +0800 > From: "Daniel" <tooldcas(a)163.com> > Subject: Re: Re: [tproxy] sockref leak problem > To: "tproxy" <tproxy(a)lists.balabit.hu> > Message-ID: <200706121121174100198(a)163.com> > Content-Type: text/plain; charset="gb2312" > > > >>On Sun, 2007-06-10 at 20:25 +0800, Daniel wrote: > >> hi, > >> > >> Recently I tested tproxy with Avanlanche (about 800M/s stress) and some result below: > >> > >> 1. deadlock when ip_conntrack_ftp loaded. Plz see my last post and explaination from Balazs Scheidler. > >> 2. I tested again without nat_reservation(deadlock disappeared). After 10 hours' stress test, kernel kept giving out exactly the same messages repeatedly: > >> > >> IP_TPROXY: socket already assigned, reuse=1, 0a0ba8c0:4c86, sr->faddr=e80ba8c0:0000, flags=10000, sr->tv_hashed=1181425010:475244912 > >> > >> My questions: > >> Is this sockref leaked? > >> and, what is the situation when a sockref is leaked? > > > >can you tell me your kernel/tproxy version? > > > >The error message above means that the application tries to an address > >that already is in the tproxy hash table (e.g. which was allocated > >before). This should never happen, as this would indicate that > >you have two sockets bound to the same local ip:port > > > >The details of the already registered entry is included in the log > >message. > > > >The conflicting local address is 192.168.11.10:34380 and you wanted to > >assign 192.168.11.232 with a random port (0 port). > > > >Your flags has ITP_ONCE set, and nothing else, and the entry in the > >table was registered at 1181425010.475 secs after the UNIX epoch. > > > >A minor note: > >* ITP_ONCE was removed from the latest versions of tproxy, you should > >not use that (I don't think removing that would help in your case > >however) > > > >Please give me the exact versions you are testing with. > > > > > > > >-- > >Bazsi > > > > > Sorry about my last encoded email. > > I use tproxy-2.0.1 and kernel 2.6.9 and a http proxy, and I cann't move forward to new > versions for some reason. > > > Today when I stop stress and check /proc/net/tproxy later, I found 3 entries always there: > cat /proc/net/tproxy > 00006 470ba8c0:0000 0a0ba8c0:0581 00000000:0000 00010000 00000 000001 1181498811:997708128 > 00006 700ba8c0:0000 0a0ba8c0:5a9e 00000000:0000 00010000 00000 000001 1181489066:124306088 > 00006 e80ba8c0:0000 0a0ba8c0:4c86 00000000:0000 00010000 00000 000001 1181425010:475244912 > > Maybe I missed some important fix? > > Thanks for your quick reply. > > ¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡Daniel > ¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡tooldcas(a)163.com > ¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡2007-06-12

1 0

Deadlock in tproxy
by Daniel 07 Jun '07

07 Jun '07

I think there is deadlock in tproxy. Two CPUs will wait for each other, ip_conntrack_lock and ip_nat_lock will never be unlocked. To reproduce this deadlock, we need ftp traffic(or other traffic which yields expect) and iptable_tproxy loaded. Plz see call trace below: CPU0 call trace: run_timer_softirq <-- invoked by timer death_by_timeout <-- write_lock_bh(&ip_conntrack_lock) clean_from_lists remove_expectations unexpect_related __unexpect_related ip_conntrack_expect_put ip_conntrack_expect_destroyed <-- hooked by nat_reservation patch ####### #ifdef CONFIG_IP_NF_NAT_NRES ip_conntrack_expect_destroyed = &ip_nat_reserved_cleanup_expect; #endif ####### ip_nat_reserved_cleanup_expect ip_nat_reserved_unregister_all <-- write_lock_bh(&ip_nat_lock) ##failed## [waiting...] CPU1 call trace: ip_tproxy_fn ip_tproxy_setup_nat ip_tproxy_setup_nat_bidir <-- write_lock_bh(&ip_nat_lock) ip_nat_setup_info ip_conntrack_alter_reply <-- write_lock_bh(&ip_conntrack_lock) ##failed## [waiting...]

2 1

Re: [tproxy] Tproxy + squid + Wccp verion 2 + FC5 Does it really work
by Logu 29 May '07

29 May '07

> Dear Logu, > > Currently my setup is as follows : - > > Wan Link Coming in my router --> With 2 Ethernet Port > E0/1 ------> Connected to my squid with a valid > Public IP > My Squid has only 1 Interface > configured, with no outgoing address in squid.conf > Wccp2_router & subsequent > parameters, my router detects my wccp squid verywell > E0/0 ------> Connected to my local lan > with valid public IP > I have configured the Gre tunnel and set all the parameters correct on my > linux box. I am not sure if this is the correct bi-directional path. > >>From what I read and understand I might be wrong "please correct" this is > what u mean: > Wan-->Router--->squid with 2 interface ---> My Linux box (gateway) ---> > client ? Nevermind about the bidirectional flow, I missed your WCCP setup during my initial post. Since you are using WCCP and gre tunnel both incoming and outgoing traffic should go through squid box. The culprit should be the "outgoing address", set the outgoing IP address (same as the IP of the box) and it should work for you. And infact the error does mean it. -logu

1 0

[Fwd: RE: [tproxy] Tproxy + squid + Wccp verion 2 + FC5 Does it really work]
by Balazs Scheidler 28 May '07

28 May '07

forgot to cc the list with the answer. -- Bazsi

1 0