tproxy4, kernel 2.6.22 and squid-2.6.stable13
After checking the mail archive and did some testings, I noticed there are quite many different versions of the stuff floating around. Those in the netfilter web site has given me lots of headaches ( kernel version, iptable version and so on ), so I figured that I would dig more deeply into the version on balabit website, ie tproxy-4.0.3-2.6.22.tgz since they seems to only has minor incompatibility with squid. After installing the patch to a 2.6.22 kernel and compiling iptables 1.3.8, everything went on smoothly. And I testing a version of squid-2.6.stable13 with has been previously working with tproxy2 ( and I did modprobe iptable_tproxy tproxy_any=1 ), I noticed that squid is able to receive the redirected traffic. It's positive so far ! However upon checking the traffic, I noticed that the spoofing is not working, even though the http has been cached by squid. The squid cache.log says :- tproxy ip=192.168.1.5,0x576e4c0,port=0 ERROR ASSIGN That would be quite understandable, because the binary for squid has been compiled with ( ~/src/forward.c ) :- itp.v.addr.faddr.s_addr = fwdState->src.sin_addr.s_addr; itp.v.addr.fport = 0; itp.op = TPROXY_ASSIGN; if (setsockopt(fd, SOL_IP, IP_TPROXY, &itp, sizeof(itp)) == -1) { debug(20, 1) ("tproxy ip=%s,0x%x,port=%d ERROR ASSIGN\n", inet_ntoa(itp.v.addr.faddr), itp.v.addr.faddr.s_addr, itp.v.addr.fport); } else { itp.op = TPROXY_FLAGS; itp.v.flags = ITP_CONNECT; if (setsockopt(fd, SOL_IP, IP_TPROXY, &itp, sizeof(itp)) == -1) debug(20, 1) ("tproxy ip=%x,port=%d ERROR CONNECT\n", itp.v.addr.faddr.s_addr, itp.v.addr.fport); } The tproxy-4.0.3-2.6.22.tgz did not mention how a source should be changed to use the new tproxy, I did try using IP_FREEBIND ( using #define IP_FREEBIND 15 ) and the error goes away, but the spoofing has not been done. Any suggestion where else should I check to convince squid to using the new spoofing mechanism ? Best regards. -------------------------------------------- Important Warning! *************************** This electronic communication (including any attached files) may contain confidential and/or legally privileged information and is only intended for the use of the person to whom it is addressed. If you are not the intended recipient, you do not have permission to read, use, disseminate, distribute, copy or retain any part of this communication or its attachments in any form. If this e-mail was sent to you by mistake, please take the time to notify the sender so that they can identify the problem and avoid any more mistakes in sending e-mail to you. The unauthorised use of information contained in this communication or its attachments may result in legal action against any person who uses it.
From: "Ming-Ching Tiew" <mingching.tiew@redtone.com>
Any suggestion where else should I check to convince squid to using the new spoofing mechanism ?
Looking through the sources for the kernel tproxy patch tproxy-4.0.3-2.6.22.tgz on the balabit website, I am beginning to think that the patch does not include a capability to spoof the source address - which means it does not include the same level of functionalitity as the older tproxy2 patch. Now at the same time I can't get the patches in http://people.netfilter.org/hidden/tproxy/ to compile. A few of them I tried, none of them are matching :- the kernel patch is not matching with iptable patch. And they are to be applied kernel which are too new. Is there something I could use on kernel 2.6.22 ? Kind regards.
On Nov 22 2007 09:02, Ming-Ching Tiew wrote:
Is there something I could use on kernel 2.6.22 ?
The tproxy fluff from ftp://ftp5.gwdg.de/pub/linux/misc/suser-jengelh/kernel/linux-2.6.22.9-ccj56 it's not the newest though, and has not been tested all that much.
From: "Jan Engelhardt" <jengelh@computergmbh.de>
Is there something I could use on kernel 2.6.22 ?
The tproxy fluff from
ftp://ftp5.gwdg.de/pub/linux/misc/suser-jengelh/kernel/linux-2.6.22.9-ccj56
it's not the newest though, and has not been tested all that much.
Thank you very much for the pointer. But I would need an equivalent iptables counter part. Is there one I could use with iptables 1.3.8 ? Regards.
Ming-Ching Tiew írta:
After checking the mail archive and did some testings, I noticed there are quite many different versions of the stuff floating around.
Those in the netfilter web site has given me lots of headaches ( kernel version, iptable version and so on ), so I figured that I would dig more deeply into the version on balabit website, ie tproxy-4.0.3-2.6.22.tgz since they seems to only has minor incompatibility with squid.
After installing the patch to a 2.6.22 kernel and compiling iptables 1.3.8, everything went on smoothly. And I testing a version of squid-2.6.stable13 with has been previously working with tproxy2 ( and I did modprobe iptable_tproxy tproxy_any=1 ), I noticed that squid is able to receive the redirected traffic.
It's positive so far !
However upon checking the traffic, I noticed that the spoofing is not working, even though the http has been cached by squid.
The squid cache.log says :-
tproxy ip=192.168.1.5,0x576e4c0,port=0 ERROR ASSIGN
That would be quite understandable, because the binary for squid has been compiled with ( ~/src/forward.c ) :-
itp.v.addr.faddr.s_addr = fwdState->src.sin_addr.s_addr; itp.v.addr.fport = 0; itp.op = TPROXY_ASSIGN; if (setsockopt(fd, SOL_IP, IP_TPROXY, &itp, sizeof(itp)) == -1) { debug(20, 1) ("tproxy ip=%s,0x%x,port=%d ERROR ASSIGN\n", inet_ntoa(itp.v.addr.faddr), itp.v.addr.faddr.s_addr, itp.v.addr.fport); } else { itp.op = TPROXY_FLAGS; itp.v.flags = ITP_CONNECT; if (setsockopt(fd, SOL_IP, IP_TPROXY, &itp, sizeof(itp)) == -1) debug(20, 1) ("tproxy ip=%x,port=%d ERROR CONNECT\n", itp.v.addr.faddr.s_addr, itp.v.addr.fport); }
The tproxy-4.0.3-2.6.22.tgz did not mention how a source should be changed to use the new tproxy, I did try using IP_FREEBIND ( using #define IP_FREEBIND 15 ) and the error goes away, but the spoofing has not been done.
Hello, basically you don't need that whole code, only the IP_FREEBIND as you did, plus a bind() call with the address itp.v.addr.faddr.s_addr, port itp.v.addr.fport.
Any suggestion where else should I check to convince squid to using the new spoofing mechanism ?
-- Panther
From: Laszlo Attila Toth
basically you don't need that whole code, only the IP_FREEBIND as you did, plus a bind() call with the address itp.v.addr.faddr.s_addr, port itp.v.addr.fport.
Just want to mention that the problem is fixed by doing a bind after setsockopt(....IP_FREEBIND... ). There are some minor changes in behavior as compared to tproxy2, but overall I would think that the tproxy4 behaviour might be considered more correct ! 1. nat SNAT works. It does not require any further patches. 2. squid.conf directive 'tproxy' has no impact anymore. Squid will spoof or not spoof based on whether it gets the redirected traffic from tproxy table or otherwise, ie if it gets the traffic from nat REDIRECT, then there will be no spoofing. Previously squid will spoof the source IP if the directive 'tproxy' has been configured, regardless of whether it gets the traffic from tproxy or nat REDIRECT.
From: "Ming-Ching Tiew" <mingching.tiew@redtone.com>
Just want to mention that the problem is fixed by doing a bind after setsockopt(....IP_FREEBIND... ).
There are some minor changes in behavior as compared to tproxy2, but overall I would think that the tproxy4 behaviour might be considered more correct !
Sorry to contradict my ownself. It seems my testing was not quite conclusive. I will report again as soon as I have conclusion. Please ignore my previous posts. Regards.
participants (3)
-
Jan Engelhardt
-
Laszlo Attila Toth
-
Ming-Ching Tiew