- tproxy - lists.balabit.hu

Problem with Tproxy more kernel 2.6.22.9
by Welisson 15 Jan '08

15 Jan '08

Hi all, Somebody it would know to say because of this error in the compilation of kernel 2.6.22.9, in system x86_64 net/netfilter/xt_tproxy.c:48: warning: initialization from incompatible pointer type net/netfilter/xt_tproxy.c:56: warning: initialization from incompatible pointer type I applied patch tproxy-4.0.3-2.6.22, in this kernel, iptables iptables-1-3.8.diff, and compiled squid-2.6STABLE17, and in going up of squid it returns. "Missing needed capability support. Will continue without tproxy support" Parameter of compiled squid Squid Cache: Version 2.6.STABLE17-20080108 configure options: '--sysconfdir=/etc/squid' '--enable-storeio=aufs,coss ,diskd,ufs' '--enable-poll' '--enable-delay-pools' '--enable-linux-tproxy' '--enable-htcp' '--enable-carp' '--with-pthreads' '--enable-underscores' '--enable-external--enable-arp-acl' '--enable-follow-x-forwarded-for' Regards Welisson

5 15

Problem with Tproxy more kernel 2.6.22.9
by Welisson Thiago das Merces Tome 10 Jan '08

10 Jan '08

Hi all I would like help of you. Somebody here compile the version kernel 2.6.22.9, iptables-1.3.8 and squid 2.6STABLE17. Which was patch applied in iptables-1.3.8 iptables-svn.diff or iptables-1.3.8.diff. It would like to also know if the Tproxy is compatible with architecture 64Bits X86_64 in set with technology EM64T of the Intel, or only 32Bits.

2 2

Tproxy on bridge interface
by Ming-Ching Tiew 02 Jan '08

02 Jan '08

Cameron Schaus wrotte :- > > >I think you're not the only one interested in these changes. > > > >Cam, could you post your patch implementing the necessary changes to make > >bridged tproxy work? > > > > > Sure. I'll post them soon. I have to find the code I wrote. I wasn't > able to use tproxy4 due to some other issues I wasn't able to solve, so > I'm not sure where the code went. Any luck on this item ? -------------------------------------------- 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.

3 9

tproxy on centos 5.1
by Kamran Sarkary 31 Dec '07

31 Dec '07

I want to use tproxy on CentOS 5.1 anyone can tell me which patch i should use? Best Regards, Kamran

2 1

Re: [tproxy] Tproxy_on_bridge_interface
by Ming-Ching Tiew 23 Dec '07

23 Dec '07

*Daniel* tooldcas at 163.com <mailto:tproxy%40lists.balabit.hu?Subject=%5Btproxy%5D%0A%09%3D%3Futf-8%3Fq%3Ftproxy4%3D2C_kernel_2%3D2E6%3D2E22_and_squid-2%3D2E6%3F%3D%0A%09%3D%3Futf-8%3Fq%3F%3D2Estable13%3F%3D&In-Reply-To=>wrote :- >> >>The last time I tried the patches by Kovac, I could not find a matching >>iptables patch. And at this moment I am only interested to use it with >>kernel 2.6.22 because I have a few other patches which must go into it. >> >>Do you know any matching tproxy-4.1.0 together with iptables patch for >>kernel 2.6.22 ? I don't mind trying it. :-) > >It's also hidden... > >http://people.netfilter.org/hidden/tproxy/iptables-tproxy-200710091749.diff > >I extracted libxt_socket and libxt_TPROXY from lastest >iptables-tproxy-200710091749.diff patch and compile them independently. > >Good luck :-) What I mentioned earlier still holds, there is ***ACTUALLY*** no matching iptables and kernel patch suitable for kernel 2.6.22. All the iptables patches refers to struct xt_tproxy_target_info info->mark_mask which does not exist in the kernel 2.6.22 patches ( however they exist in other kernel patches ). I think I will stay with tproxy-4.0.3 as I have practically sorted out all the problems which existed in tproxy-4.0.3. 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.

1 0

tproxy4, kernel 2.6.22, squid-2.6.stable16 and our patch with IP_FREEBIND
by Andrey Luzgin 20 Dec '07

20 Dec '07

Squid with this changes is currently work in our server diff -ru squid-2.6.STABLE16.tproxy-freebind/src/comm.c squid-2.6.STABLE16/src/comm.c --- squid-2.6.STABLE16.tproxy-freebind/src/comm.c 2007-12-18 09:31:55.000000000 +0200 +++ squid-2.6.STABLE16/src/comm.c 2007-04-17 12:39:56.000000000 +0300 @@ -162,7 +162,7 @@ int flags, const char *note) { - return comm_openex(sock_type, proto, addr, port, flags, 0, note,0); + return comm_openex(sock_type, proto, addr, port, flags, 0, note); } @@ -175,8 +175,7 @@ u_short port, int flags, unsigned char TOS, - const char *note, - struct in_addr* tproxy) + const char *note) { int new_socket; int tos = 0; @@ -210,16 +209,6 @@ debug(5, 0) ("comm_open: setsockopt(IP_TOS) not supported on this platform\n"); #endif } - { - #define IP_FREEBIND 15 - int x=1; - if (setsockopt(new_socket, SOL_IP, IP_FREEBIND, &x, sizeof(x)) == -1) { - debug(20, 1) ("tproxy ip ,port ERROR ASSIGN\n"); - } else if (tproxy){ - addr.s_addr = tproxy->s_addr; - port=0; - } - } /* update fdstat */ debug(5, 5) ("comm_open: FD %d is a new socket\n", new_socket); fd_open(new_socket, FD_SOCKET, note); diff -ru squid-2.6.STABLE16.tproxy-freebind/src/forward.c squid-2.6.STABLE16/src/forward.c --- squid-2.6.STABLE16.tproxy-freebind/src/forward.c 2007-12-18 14:17:42.000000000 +0200 +++ squid-2.6.STABLE16/src/forward.c 2007-09-06 00:28:34.000000000 +0300 @@ -27,7 +27,7 @@ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the * GNU General Public License for more details. * - * You should have received a copy of theF GNU General Public License + * You should have received a copy of the GNU General Public License * along with this program; if not, write to the Free Software * Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111, USA. * @@ -556,8 +556,7 @@ 0, COMM_NONBLOCKING, tos, - url, - (fwdState->request->flags.tproxy && strcmp(host,"127.0.0.2"))?( &( fwdState->src.sin_addr)):0); + url); if (fd < 0) { debug(50, 4) ("fwdConnectStart: %s\n", xstrerror()); err = errorCon(ERR_SOCKET_FAILURE, HTTP_INTERNAL_SERVER_ERROR, fwdState->request); @@ -588,6 +587,32 @@ if (fs->peer) { hierarchyNote(&fwdState->request->hier, fs->code, fs->peer->name); } else { +#if LINUX_TPROXY + if (fwdState->request->flags.tproxy) { + + itp.v.addr.faddr.s_addr = fwdState->src.sin_addr.s_addr; + itp.v.addr.fport = 0; + + /* If these syscalls fail then we just fallback to connecting + * normally by simply ignoring the errors... + */ + 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); + } + } + } +#endif hierarchyNote(&fwdState->request->hier, fs->code, fwdState->request->host); } commConnectStart(fd, host, port, fwdConnectDone, fwdState); diff -ru squid-2.6.STABLE16.tproxy-freebind/src/main.c squid-2.6.STABLE16/src/main.c --- squid-2.6.STABLE16.tproxy-freebind/src/main.c 2007-12-05 14:21:51.000000000 +0200 +++ squid-2.6.STABLE16/src/main.c 2007-08-31 16:52:10.000000000 +0300 @@ -487,13 +487,13 @@ #ifdef _SQUID_OS2_ return; #endif -/* if (geteuid() == 0) { + if (geteuid() == 0) { debug(0, 0) ("Squid is not safe to run as root! If you must \n"); debug(0, 0) ("start Squid as root, then you must configure\n"); debug(0, 0) ("it to run as a non-priveledged user with the\n"); debug(0, 0) ("'cache_effective_user' option in the config file.\n"); fatal("Don't run Squid as root, set 'cache_effective_user'!"); - }*/ + } } static void diff -ru squid-2.6.STABLE16.tproxy-freebind/src/protos.h squid-2.6.STABLE16/src/protos.h --- squid-2.6.STABLE16.tproxy-freebind/src/protos.h 2007-12-18 09:26:35.000000000 +0200 +++ squid-2.6.STABLE16/src/protos.h 2007-07-15 12:52:17.000000000 +0300 @@ -160,7 +160,7 @@ extern void comm_init(void); extern int comm_listen(int sock); extern int comm_open(int, int, struct in_addr, u_short port, int, const char *note); -extern int comm_openex(int, int, struct in_addr, u_short, int, unsigned char TOS, const char *,struct in_addr* ); +extern int comm_openex(int, int, struct in_addr, u_short, int, unsigned char TOS, const char *); extern u_short comm_local_port(int fd); extern void commDeferFD(int fd); diff -ru squid-2.6.STABLE16.tproxy-freebind/src/ssl.c squid-2.6.STABLE16/src/ssl.c --- squid-2.6.STABLE16.tproxy-freebind/src/ssl.c 2007-12-18 09:27:04.000000000 +0200 +++ squid-2.6.STABLE16/src/ssl.c 2007-02-03 23:53:38.000000000 +0200 @@ -524,8 +524,7 @@ 0, COMM_NONBLOCKING, getOutgoingTOS(request), - url, - 0); + url); if (sock == COMM_ERROR) { debug(26, 4) ("sslStart: Failed because we're out of sockets.\n"); err = errorCon(ERR_SOCKET_FAILURE, HTTP_INTERNAL_SERVER_ERROR, request); -- Andrey Luzgin <andrey(a)icomsw.com> I-com software

2 3

tproxy4, kernel 2.6.22 and squid-2.6.stable13
by Andrey Luzgin 18 Dec '07

18 Dec '07

We tried to modify forward.c in squid source like this: #if LINUX_TPROXY /* hack to allow rewrite to 127.0.0.1: */ if (fwdState->request->flags.tproxy && strcmp(host,"127.0.0.1")) { itp.v.addr.faddr.s_addr = fwdState->src.sin_addr.s_addr; itp.v.addr.fport = 0; /* If these syscalls fail then we just fallback to connecting * normally by simply ignoring the errors... */ #define IP_FREEBIND 15 int x=1; if (setsockopt(fd, SOL_IP, IP_FREEBIND, &x, sizeof(x)) == -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 { static struct sockaddr_in to_addr; bzero(&to_addr, sizeof(struct sockaddr_in)); to_addr.sin_family = AF_INET; to_addr.sin_port = 0; /*statuc IP-adress of the client for testing */ if( inet_aton( "XXX.XXX.XXX.XXX", &to_addr.sin_addr ) == 0 ) { debug(20, 1) ("tproxy fail to set to_addr.sin.addr \n"); } /* Here it falls */ if (bind(fd, (struct sockaddr *) &to_addr, sizeof(to_addr)) == -1) { debug(20, 1) ("tproxy fail to bind\n"); } /* 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); } */ } } #endif We receive the message "tproxy fail to bind". -- Andrey Luzgin <andrey(a)icomsw.com> I-com software(www.icomsw.com)

2 2

Re: [tproxy] tproxy4, kernel 2.6.22 and squid-2.6.stable13
by Ming-Ching Tiew 17 Dec '07

17 Dec '07

From: "Ming-Ching Tiew" <mingching.tiew(a)redtone.com> > > 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. > OK this is my observation after modifying squid-2.6.STABLE.13 to use IP_FREEBIND :- 1. Transparent tproxy is working without NAT. 2. When SNAT is done in the nat table POSTROUTING chain, packets goes out and comes back using public IP ( tcpdump confirms it ) however, squid don't seem to be able to get the return packet. In the tproxy2 case, the packet goes out using spoofed private IP and hence unable to route back but there is a patch created by Arun which fixes this problem. In the case of tproxy4 using IP_FREEBIND, I wonder if there is someone who can work on an equivalent patch. 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.

5 17

tproxy on bridge interface
by Michael Gaisinsky 26 Nov '07

26 Nov '07

Hello. On Wed Nov 14 22:35:19 CET 2007 Cameron Schaus wrote: "I have done some previous investigation around using tproxy4 code on a bridge interface. I found that the bridge code clobbers the dst route entry added by tproxy4 during prerouting, and that packets processed by tproxy destined for the localhost need to be marked with a packet type of PACKET_HOST otherwise they are dropped higher up the stack. I don't have a patch right now, but I can get you a diff of the bridge code changes needed to make this work if you are interested. The changes are fairly minor. Cam" I would like to get an assistance in one of the following ways: 1. If exist, to get the patch for the "the bridge code changes". 2. Diff between original source code and modified one. 3. More guidance for code area(s) that need to be modified. Thanks in advance, Michael Gaisinsky <Mike(a)PineApp.Com>

3 2

tproxy4, kernel 2.6.22 and squid-2.6.stable13
by Ming-Ching Tiew 23 Nov '07

23 Nov '07

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.

3 6