- tproxy - lists.balabit.hu

Crashing kernel
by Michal Pokrywka 29 Nov '06

29 Nov '06

Hello, I used successfully tproxy patch with squid and 2.6.12 kernel. Recently I tried to consolidate my boxes using xen, I used new upcoming debian kernel (2.6.18) and patched it with tproxy. I also enabled TPROXY feature in debian's squid (2.6.STABLE5). TProxy seems working - rewrites source ip, but kernel crashes frequently - few times a day, under light - only testing usage. TProxy is run in unpriviledged xen domain. I managed to capture few oopses, attached. Only iptables rules used on this box: iptables -t tproxy -F * iptables -t tproxy -X iptables -t tproxy -N redir-to-squid iptables -t tproxy -A redir-to-squid -j TPROXY --on-port 3128 --on-ip 192.168.1.100 iptables -t tproxy -N check-ip iptables -t tproxy -A check-ip -s 192.168.0.0/16 -j redir-to-squid iptables -t tproxy -A PREROUTING -i eth0 -p tcp --dport 80 -j check-ip Let me know if you have any ideas how to prevent crashes, or if any other info is needed. Thanks Michal Pokrywka

2 1

Some patch for libipt_TPROXY.c
by Jan Engelhardt 15 Nov '06

15 Nov '06

I put it short, Index: iptables-1.3.6/extensions/libipt_TPROXY.c =================================================================== --- iptables-1.3.6.orig/extensions/libipt_TPROXY.c +++ iptables-1.3.6/extensions/libipt_TPROXY.c @@ -131,7 +131,7 @@ static struct iptables_target tproxy = { .extra_opts = opts, }; -static void _init(void) +static __attribute__((constructor)) void _init(void) { register_target(&tproxy); } Index: iptables-1.3.6/extensions/libipt_tproxy.c =================================================================== --- iptables-1.3.6.orig/extensions/libipt_tproxy.c +++ iptables-1.3.6/extensions/libipt_tproxy.c @@ -69,7 +69,7 @@ static struct iptables_match tproxy = { .extra_opts = opts, }; -void _init(void) +static __attribute__((constructor)) void _init(void) { register_match(&tproxy); } #<EOF> -`J' --

2 1

Re: Request: including tproxy patch to official iptables/kernel.
by KOVACS Krisztian 17 Oct '06

17 Oct '06

Hi, On Monday 16 October 2006 07:48, Patrick McHardy wrote: > > So, I would like to suggest to include tproxy patch to official > > iptables/kernel release. > > These look quite old (2.4). The TPROXY developers were working on > a new approach last year at the netfilter workshop, but I don't > know if there was any further progress. Please talk to them directly > and ask them if they want to merge it upstream, and if so to submit > patches. Yes, there was significant progress since then, we're testing the patches at the moment. There still are a couple of problems with the new approach, but it certainly looks promising. I'll post the patches on netfilter-devel for review and comments as soon as things have settled down a bit. Instead of trying to get the 2.0 branch of tproxy merged into mainline we're concentrating our efforts on getting the new code working. As the maintainer of the current tproxy patchset, I do not consider it clean and safe enough to have it merged upstream. Moreover, I think there's no general consensus between networking maintainers whether or not the features tproxy provides are worth the hassles. Transparent proxying features have been removed during the 2.3 development as there seemed little interest in those. Of course there are a handful of companies interested in having the feature in mainline, but let's face the facts: the majority of users do not care about tproxy. That's why I don't even try to get it merged. -- Regards, Krisztian Kovacs

3 2

Merging tproxy patch to official netfilter/kernel release ?
by Yoshioka Tsuneo 16 Oct '06

16 Oct '06

Hello TProxy patch is very convenience patch to make transparent proxy keeping source IP address. I think that tproxy is almost only solution to keep source IP address, at now. So, I hope that tproxy patch is included to the official netfilter/kernel release. I have asked to include tproxy to official netfilter/kernel release. But, they want that developer submit the patch like following. http://lists.netfilter.org/pipermail/netfilter-devel/2006-October/025812.ht… How do you think about merging tproxy patch to official netfilter/kernel release ? And, can you submit the patch to netfilter team, if possible ? Thank you ! -- Nihon F-Secure Corporation (Yoshioka Tsuneo) E-MAIL: Tsuneo.Yoshioka(a)f-secure.com

1 0

Re: Re: [tproxy] Tproxy + Squid 2.6
by Enrico Demarin (home) 15 Sep '06

15 Sep '06

>/ However Squid doesnt seem to able to spoof the original IP: / > tproxy needs CAP_NET_ADMIN. Which you do not have when running in > unprivileged mode. And running in privileged mode (root) is inhibited by > squid. >/ Did any one get squid+cttproxy to work on a bridge ? What am I missing />/ ? / > Something that gives your squid user the CAP_NET_ADMIN capability. Doesnt this do it ( squid 2.6, tools.c ) ? I added a debug message and it's printed during init however i still get the ERROR ASSIGN messages. #if LINUX_TPROXY if (need_linux_tproxy) { cap_user_header_t head = (cap_user_header_t) xcalloc(1, sizeof(cap_user_header_t)); cap_user_data_t cap = (cap_user_data_t) xcalloc(1, sizeof(cap_user_data_t)); head->version = _LINUX_CAPABILITY_VERSION; head->pid = 0; cap->inheritable = cap->permitted = cap->effective = (1 << CAP_NET_ADMIN) + (1 << CAP_NET_BIND_SERVICE) + (1 << CAP_NET_BROADCAST); if (capset(head, cap) != 0) { xfree(head); xfree(cap); fatal("Error giving up capabilities"); } debug(50,0) ("Caps set to %x",cap->effective); xfree(head); xfree(cap); } #endif

2 4

Tproxy + Squid 2.6
by Enrico Demarin (home) 14 Sep '06

14 Sep '06

( re-sending, sent it from an unsubscribed address ) Hi everyone, I posted this on squid.users , but maybe someone here can be helpful as well ( especially in clarifying wether cttproxy will or not work with a bridge ). I am using a vanilla 2.4.33.3 kernel, with the last 2.4.33 cttproxy patch 2.0.5 and the latest ebtables patch. I am trying to get squid 2.6 + cttproxy to work on a transparently bridged environment, with scarce results. The bridging works fine, squid is compiled with tproxy support , and has the following directives ( among the others): http_port 3128 transparent tproxy vhost vport=80 always_direct allow all I enable the redirection as follows: ebtables -t broute -A BROUTING -p IPv4 --ip-protocol-6 --ip-destination-port 80 -j redirect --redirect-target ACCEPT iptables -t tproxy -A PREROUTING -i br0 -p tcp --dport 80 -j TPROXY --on-port 3128 However Squid doesnt seem to able to spoof the original IP: all i get is a bunch of: 2006/09/13 01:01:55| tproxy ip=10.0.0.200,0xc800000a,port=0 ERROR ASSIGN 2006/09/13 01:01:55| tproxy ip=10.0.0.200,0xc800000a,port=0 ERROR ASSIGN 2006/09/13 01:01:55| tproxy ip=10.0.0.200,0xc800000a,port=0 ERROR ASSIGN 2006/09/13 01:03:16| tproxy ip=10.0.0.200,0xc800000a,port=0 ERROR ASSIGN 2006/09/13 01:03:29| tproxy ip=10.0.0.200,0xc800000a,port=0 ERROR ASSIGN The br0 interface has an ip assigned of 10.0.0.254 in the same subnet of 10.0.0.200 ( the client ). Did any one get squid+cttproxy to work on a bridge ? What am I missing ? thanks for your answer, Enrico

2 1

Virtual Private Connection crash kernel 2.6.17 with cttproxt 2.0.5
by Zhou Li 13 Sep '06

13 Sep '06

Sadly, this bug still exist in new cttproxy-2.0.5 Environment: Windows 2000 <--> Linux with tproxy <--> VPN server. Linux kernel is 2.6.17 with cttproxy-2.6.17-2.0.5 all four patch. When I do Virtual Private Connectio from Win2000 to VPN server, the linux box will be crash, the following are crashing messages: BUG: unable to handle kernel paging request at virtual address 00003f0a printing eip: *pde = 00000000 Oops: 0002 [#1] Modules linked in: ebt_vlan ebtable_broute ebtables ipt_TPROXY iptable_tproxy iptable_nat iptable_mangle iptable_filter ipt_hashlimit ipt_connlimit xt_state xt_pkttype xt_multiport xt_mark xt_length xt_conntrack ipt_REJECT ipt_LOG ip_queue ip_nat_snmp_basic ip_nat_pptp ip_nat_irc ip_nat_ftp ip_nat ip_conntrack_pptp ip_conntrack_irc ip_conntrack_ftp ip_conntrack nfnetlink ip_tables e100 mii bridge llc usbhid dm_mod sd_mod isofs ide_cd cdrom ide_disk pcspkr i2c_i801 piix ide_core shpchp ehci_hcd uhci_hcd usbcore i2c_i810 i2c_algo_bit i2c_core CPU: 0 EIP: 0060:[<e0a0773d>] Not tainted VLI EFLAGS: 00010212 (2.6.17.11-3tr #1) EIP is at ip_nat_reserved_unregister_all+0x2c/0x6f [ip_nat] eax: d76146e8 ebx: d76146f0 ecx: 00000000 edx: 00003f06 esi: d76146f0 edi: d7614630 ebp: e0a04e20 esp: c0345cf0 ds: 007b es: 007b ss: 0068 Process swapper (pid: 0, threadinfo=c0344000 task=c02eef80) Stack: d7614630 d7614630 d7614694 e09f883e d7614630 d7614630 e09f962f d7614630 d7614630 d76a305c e09f50a0 d7614630 df6d0f40 d76a3000 00000000 0000002d c213e7dc c034e103 a658a8c0 c02f3f06 d76a305c d7614694 c0345d78 e0a03053 Call Trace: <e09f883e> ip_ct_unlink_expect+0x34/0x3f [ip_conntrack] <e09f962f> ip_conntrack_unexpect_related+0xbb/0xdb [ip_conntrack] <e09f50a0> pptp_nat_expected+0xa0/0x153 [ip_nat_pptp] <c034e103> init_cyrix+0xcb/0x29c <e0a03053> pptp_expectfn+0x53/0x5a [ip_conntrack_pptp] <e09f8989> find_expectation+0x87/0x98 [ip_conntrack] <e09f935c> init_conntrack+0xf9/0x112 [ip_conntrack] <c034e103> init_cyrix+0xcb/0x29c <e09f9453> ip_conntrack_in+0xde/0x1de [ip_conntrack] <e08ba69f> br_nf_pre_routing_finish+0x0/0x2a5 [bridge] <c0262a80> nf_iterate+0x3f/0x5f <e08ba69f> br_nf_pre_routing_finish+0x0/0x2a5 [bridge] <c0262ae7> nf_hook_slow+0x47/0xa7 <e08ba69f> br_nf_pre_routing_finish+0x0/0x2a5 [bridge] <e08b76e2> br_handle_frame_finish+0x0/0xe0 [bridge] <e08baf03> br_nf_pre_routing+0x2f4/0x312 [bridge] <e08ba69f> br_nf_pre_routing_finish+0x0/0x2a5 [bridge] <c0262a80> nf_iterate+0x3f/0x5f <e08b76e2> br_handle_frame_finish+0x0/0xe0 [bridge] <c0262ae7> nf_hook_slow+0x47/0xa7 <e08b76e2> br_handle_frame_finish+0x0/0xe0 [bridge] <e08b7921> br_handle_frame+0x133/0x162 [bridge] <e08b76e2> br_handle_frame_finish+0x0/0xe0 [bridge] <c025506c> netif_receive_skb+0x149/0x1f9 <e09dc8eb> e100_rx_indicate+0x128/0x14b [e100] <e09dc949> e100_rx_clean+0x3b/0xdf [e100] <e09dcc13> e100_poll+0x33/0xab [e100] <c025524c> net_rx_action+0x59/0xbf <c0116e3c> __do_softirq+0x34/0x7d <c0116ea7> do_softirq+0x22/0x26 <c01049c7> do_IRQ+0x47/0x4f <c01033ca> common_interrupt+0x1a/0x20 <c0100ab7> default_idle+0x2b/0x53 <c0100b2c> cpu_idle+0x39/0x4e <c034660a> start_kernel+0x180/0x182 Code: 56 53 b8 00 e0 ff ff 8b 7c 24 10 21 e0 81 40 14 00 01 00 00 8b 77 5c 8d 47 5c 39 c6 74 48 8d 46 f8 8b 36 8b 48 04 8b 10 8d 58 08 <89> 4a 04 89 11 c7 40 04 00 02 20 00 8b 50 08 8b 4b 04 c7 00 00 EIP: [<e0a0773d>] ip_nat_reserved_unregister_all+0x2c/0x6f [ip_nat] SS:ESP 0068:c0345cf0 <0>Kernel panic - not syncing: Fatal exception in interrupt It is seem crash by nat reserved, so I disable NAT reservations in kernel config and recompile it then test it again, It will not be crash, but I don't konw if tproxy will work well without 01-nat_reservations? // Zhou Li

2 1

TProxy version 2.0.5 released
by KOVACS Krisztian 12 Sep '06

12 Sep '06

Hi, TProxy version 2.0.5 has been released for Linux 2.4.32, 2.4.33, 2.6.16, 2.6.17, and 2.6.18-rc6. This release fixes a serious bug leading to connections being NAT-ted to invalid addresses on SMP systems. Other less significant fixes are: * a typo leading to NAT reservations not being allocated for certain connections has been corrected * the ITP_ONCE flag has no effect anymore: there are certain situations when TProxy sees a single TCP connection as NEW multiple times, thus setting ITP_ONCE on a socket could lead to problems * on 2.6 kernels, reading /proc/net/tproxy did cause a deadlock on SMP systems; this has been fixed The release tarballs are available here: http://www.balabit.com/downloads/tproxy/ MD5 checksums of the release tarballs: b9f7894d636bcb3bb58c463a2ab5b242 cttproxy-2.4.32-2.0.5.tar.gz f9149858df07f8d41aea2a6c752fba44 cttproxy-2.4.33-2.0.5.tar.gz 52c45445ce4fd268bec986d94438a07b cttproxy-2.6.16-2.0.5.tar.gz 8017be4c03856061ba804de15cd51104 cttproxy-2.6.17-2.0.5.tar.gz 7fb22ee1617fa1c0e4e83f459cae2826 cttproxy-2.6.18-2.0.5.tar.gz -- Regards, Krisztian Kovacs

2 2

[tprox] Re: New Linux 2.6 tproxy snapshots
by Jan Engelhardt 12 Sep '06

12 Sep '06

>http://people.balabit.hu/hidden/tproxy2-2.6.17_20060908.tar.bz2 One remains: 09:20 gwdg-wb04A:../BUILD/linux-2.6.17.13 > quilt refresh Warning: trailing whitespace in line 350 of net/ipv4/netfilter/ip_nat_core.c Refreshed patch patches/tproxy2-01-nat_reservations.diff Jan Engelhardt --

1 0

tproxy performance issues on different 2.6 kernels
by ferents zvika 06 Sep '06

06 Sep '06

Hi, I'm working on a firewall (reveresed-proxy) that needs to provide the "foreign connection" feature , my firewall read the requests from clients, and passes on the requests to the server , so i'm using the foreign-connect so that the server sees the real client's IP It seems that i have some performance problems: - On kernel 2.6.15 , even without the TPROXY patches i get lousy performance , it seems that this is a well known bug with E1000 drivers , so i can't use this kernel - On kernel 2.6.10 + tproxy 2.0.1 , i got nice results without the tproxy patch, but when i added the tproxy - i got lousy performance - On kernel 2.6.14.7 + tproxy 2.0.3 , i got great results without the tproxy patch (4500 trans/sec) , but when i added the tproxy - it was 3 times slower (1500 trans/sec) with many "failed to create a socket" errors Now, since i would like to stick with the (almost) latest versions, i believe that 2.6.14.7 is enough for me, but i would appreciate to know : 1. are there any knows performance issues with the 2.6.14.7 kernel or with the tproxy-2.0.3 ? 2. my "kernel config" uses the following settings: CONFIG_NETFILTER=y CONFIG_IP_NF_CONNTRACK=y CONFIG_IP_NF_TPROXY=y CONFIG_IP_NF_IPTABLES=y CONFIG_IP_NF_NAT=y CONFIG_IP_NF_NAT_NEEDED=y do i need all these settings to get the "foreign-connect" or can i skip some and gain better results ? thank you very much, zvi ferents

3 5