Re: [tproxy] Squid with tproxy extra brief FAQ - take 2
Thanks for the FAQ. I'm using the (B) Version Tproxy 4.0.x. However, I haven't found the patch for squid in the site http://www.balabit.hu/downloads/files/tproxy/. I'm using SQUID-2.6.17 with "--enable-linux-tproxy". But this compile options activates suppor for tproxy2 instead tproxy4.0.x, right ? How can I found the patch ? Thanks in advance! Best Regads, Eduardo Schoedler. -------------------------------------------------- From: "Ming-Ching Tiew" <mingching.tiew@redtone.com> Subject: [tproxy] Squid with tproxy extra brief FAQ - take 2 1. There are at least 3 different versions of tproxy kernel patches. Each tproxy kernel patch is quite strongly tied to a kernel version, (A) Version Tproxy2 ============= For kernel 2.6.18 URL: http://www.balabit.hu/downloads/files/tproxy/obsolete/ (B) Version Tproxy 4.0.x ================ For kernel 2.6.22 URL: http://www.balabit.hu/downloads/files/tproxy/ (C) Version Tproxy-4.1.0 ================= For kernel 2.6.25 URL: The "official website" is for kernel <=2.6.24 http://people.netfilter.org/hidden/tproxy but the actual version of tproxy 4.1 for 2.6.25 is here: http://people.balabit.hu/panther/tproxy The kernel patch might work with nearby kernel versions, for example, tproxy2 might work with kernel 2.6.19; however it will not work will kernel 2.6.22 ( unless you port it ). 2. Do not confuse tproxy kernel patch mentioned above with squid user-space patches. So far the Squid ( 3.0 and 2.6 ) is only supporting on tproxy2 - the userspace code is integrated. If you managed to compile Squid without changing the source, perhaps with only minor changes in header files, meaning you are likely either did not successfully link in tproxy support or at best it is using tproxy2, and it will not work with tproxy-4.0.x and tproxy-4.1.0 kernel counterpart. However, if you patch the squid source, you should be able to get squid to work with tproxy-4.0.x and tproxy-4.1.0. You can look through the archive of this maillist to look at how to port squid versions to support tproxy-4.0.x and tproxy-4.1.0. Most of the patches floating around are not fully satisfactory, but it could work, at least; but perhaps it will require you to have some programming knowledge. Here maybe a good start :- 3. All the tproxy kernel patches are not compatible with one another. Each requires it's own way of setup and usage. So before doing anything, check if you have gotten the correct info/tproxy version/patches. These are some of the info :- (A) Version Tproxy2 ============ The Squid documentation recommends this :- ebtables -t broute -A BROUTING -p ipv4 --ip-protocol tcp \ --ip-destination-port 80 -j redirect --redirect-target ACCEPT This rule will "broute" bridge traffic from br0 to netfilter. The iptables rule will bring http traffic into local process :- iptables -t tproxy -A PREROUTING -i br0 -p tcp --dport 80 \ -j TPROXY --on-port 3128 To get SNAT working for tproxy2, there is a need for double NAT, and here was the discussion and patch :- https://lists.balabit.hu/pipermail/tproxy/2007-October/000537.html (B) Version tproxy-4.0.x ================ Requires additional patches for SNAT and FWMARK. Some hurdles with bridge. Bridge problem is to do with packets must be marked PACKET_HOST when heading for br0 as discussed in this tproxy maillist. There have been people saying they will post the patch for it but yet to date, there is none. This problem can be worked around by brouting the traffic into the real devices instead of br0 :- INSIDE_DEV=eth0 OUTSIDE_DEV=eth1 ebtables -t broute -A BROUTING -i $INSIDE_DEV -p ipv4 \ --ip-protocol tcp --ip-destination-port 80 \ -j redirect --redirect-target DROP ebtables -t broute -A BROUTING -i $OUTSIDE_DEV -p ipv4 \ --ip-protocol tcp --ip-source-port 80 \ -j redirect --redirect-target DROP Please note for real interfaces, it's redirect-target DROP and not redirect-target ACCEPT, while doing it on br0, it's redirect-target ACCEPT ! Remember to adjust your iptables rule accordingly since now packets entering and leaving real interfaces instead of br0. Example :- iptables -t tproxy -A PREROUTING -i $INSIDE_DEV \ -p tcp --dport 80 -j TPROXY --on-port 3128 For tproxy-4.0.3 remember to apply the additional kernel patches mentioned in this maillist or else the kernel will panic accessing null pointer. (C) Version tproxy-4.1.0 ================ The ebtables/bridge notes above is equally applicable. However the iptables rules are totally different. Something like this will be required :- iptables -t mangle -A PREROUTING -p tcp --dport 80 -j TPROXY \ --tproxy-mark 0x1/0x1 -on-port 3128 iptables -t mangle -N DIVERT iptables -t mangle -A PREROUTING -p tcp -m socket -j DIVERT iptables -t mangle -A DIVERT -j MARK --set-mark 1 iptables -t mangle -A DIVERT -j ACCEPT ip rule add fwmark 1 lookup 100 ip route add local 0.0.0.0/0 dev lo table 100 _______________________________________________ tproxy mailing list tproxy@lists.balabit.hu https://lists.balabit.hu/mailman/listinfo/tproxy
Eduardo, On Wed, Feb 27, 2008 at 3:33 PM, Eduardo Schoedler <eschoedler@viavale.com.br> wrote:
Thanks for the FAQ.
I'm using the (B) Version Tproxy 4.0.x. However, I haven't found the patch for squid in the site http://www.balabit.hu/downloads/files/tproxy/.
I'm using SQUID-2.6.17 with "--enable-linux-tproxy". But this compile options activates suppor for tproxy2 instead tproxy4.0.x, right ? How can I found the patch ?
Try the patch located in http://www.squid-cache.org/bugs/show_bug.cgi?id=2129 Please, note that this is still unofficial path. Any feedback about it is much appreciated. HTH, -- Gonzalo A. Arana
Hi Gonzalo! Thanks for the support! I've tried the patch from the site. Here's the output: ===> Sources of squid-2.6.STABLE16 # cat patch-tproxy-squid.diff | patch -p1 patching file client_side.c Hunk #1 FAILED at 4822. 1 out of 1 hunk FAILED -- saving rejects to file client_side.c.rej patching file comm.c Hunk #3 succeeded at 227 (offset -24 lines). Hunk #4 succeeded at 377 (offset -58 lines). Hunk #5 succeeded at 944 (offset -58 lines). patching file defines.h patching file forward.c Hunk #1 FAILED at 524. Hunk #2 FAILED at 577. Hunk #3 FAILED at 626. Hunk #4 FAILED at 678. 4 out of 4 hunks FAILED -- saving rejects to file forward.c.rej patching file structs.h Hunk #1 FAILED at 895. 1 out of 1 hunk FAILED -- saving rejects to file structs.h.rej patching file tools.c Hunk #1 FAILED at 1364. 1 out of 1 hunk FAILED -- saving rejects to file tools.c.rej ===> Sources of squid-2.6.STABLE17 # cat patch-tproxy-squid.diff | patch -p1 patching file client_side.c Hunk #1 FAILED at 4822. 1 out of 1 hunk FAILED -- saving rejects to file client_side.c.rej patching file comm.c Hunk #3 succeeded at 227 (offset -24 lines). Hunk #4 succeeded at 377 (offset -58 lines). Hunk #5 succeeded at 944 (offset -58 lines). patching file defines.h patching file forward.c Hunk #1 FAILED at 524. Hunk #2 FAILED at 577. Hunk #3 FAILED at 626. Hunk #4 FAILED at 678. 4 out of 4 hunks FAILED -- saving rejects to file forward.c.rej patching file structs.h Hunk #1 FAILED at 895. 1 out of 1 hunk FAILED -- saving rejects to file structs.h.rej patching file tools.c Hunk #1 FAILED at 1364. 1 out of 1 hunk FAILED -- saving rejects to file tools.c.rej ===> Sources of squid-2.6.STABLE18 # cat patch-tproxy-squid.diff | patch -p1 patching file client_side.c Hunk #1 FAILED at 4822. 1 out of 1 hunk FAILED -- saving rejects to file client_side.c.rej patching file comm.c Hunk #3 succeeded at 227 (offset -24 lines). Hunk #4 succeeded at 377 (offset -58 lines). Hunk #5 succeeded at 944 (offset -58 lines). patching file defines.h patching file forward.c Hunk #1 FAILED at 524. Hunk #2 FAILED at 577. Hunk #3 FAILED at 626. Hunk #4 FAILED at 678. 4 out of 4 hunks FAILED -- saving rejects to file forward.c.rej patching file structs.h Hunk #1 FAILED at 895. 1 out of 1 hunk FAILED -- saving rejects to file structs.h.rej patching file tools.c Hunk #1 FAILED at 1364. 1 out of 1 hunk FAILED -- saving rejects to file tools.c.rej Best Regards, Eduardo Schoedler. -------------------------------------------------- From: "Gonzalo Arana" <gonzalo.arana@gmail.com> Subject: Re: [tproxy] Squid with tproxy extra brief FAQ - take 2 Eduardo, On Wed, Feb 27, 2008 at 3:33 PM, Eduardo Schoedler <eschoedler@viavale.com.br> wrote:
Thanks for the FAQ.
I'm using the (B) Version Tproxy 4.0.x. However, I haven't found the patch for squid in the site http://www.balabit.hu/downloads/files/tproxy/.
I'm using SQUID-2.6.17 with "--enable-linux-tproxy". But this compile options activates suppor for tproxy2 instead tproxy4.0.x, right ? How can I found the patch ?
Try the patch located in http://www.squid-cache.org/bugs/show_bug.cgi?id=2129 Please, note that this is still unofficial path. Any feedback about it is much appreciated. HTH, -- Gonzalo A. Arana _______________________________________________ tproxy mailing list tproxy@lists.balabit.hu https://lists.balabit.hu/mailman/listinfo/tproxy
Hi, Gonzalo Arana wrote:
Try the patch located in http://www.squid-cache.org/bugs/show_bug.cgi?id=2129 Please, note that this is still unofficial path. Any feedback about it is much appreciated.
Does the foreign bind work with this patch? I rewrote the patch for 2.6-STABLE18 and perhaps I missed something. What I see on the webserver is that the squid connects with its own IP address instead of the client's address. Config: http_port 3128 tproxy When the new patch will work, I publish it. The changes: the --enable-tproxy option is dropped, --enable-linux-netfilter is used only. Also both REDIRECT and TPROXY target can be used in this case. If the tproxy patch isn't in the kernel, it is ignored in squid. -- Panther
Hi, On Mon, Mar 3, 2008 at 12:33 PM, Laszlo Attila Toth <panther@balabit.hu> wrote:
Hi,
Gonzalo Arana wrote:
Try the patch located in http://www.squid-cache.org/bugs/show_bug.cgi?id=2129 Please, note that this is still unofficial path. Any feedback about it is much appreciated.
Does the foreign bind work with this patch? I rewrote the patch for
Indeed. I believe it is called freebind.
2.6-STABLE18 and perhaps I missed something. What I see on the webserver is that the squid connects with its own IP address instead of the client's address. Config: http_port 3128 tproxy
Odd. My patch requires that comm_fdopenex be called with COMM_FREEBIND, so that setsockopt(fd, SOL_IP, IP_FREEBIND, &on, ...) is called before bind(2) is. In my patch: 1) "http_port XXX tproxy" implies that http_port_list->tproxy is set (in clientHttpConnectionsOpen), and that COMM_FREEBIND is passed to comm_fdopenex. 2) fwdConnectStart calls comm_openex(...) with COMM_FREEBIND set if the request is received through a 'tproxy' squid socket. 3) (not patched by me) clientTryParseRequest copies tproxy flag from passive socket to the request. Perhaps strace may shed some light to this (ioctl should be called before bind).
When the new patch will work, I publish it. The changes: the --enable-tproxy option is dropped, --enable-linux-netfilter is used only. Also both REDIRECT and TPROXY target can be used in this case. If the tproxy patch isn't in the kernel, it is ignored in squid.
HTH, -- Gonzalo A. Arana
Gonzalo Arana wrote:
Hi,
On Mon, Mar 3, 2008 at 12:33 PM, Laszlo Attila Toth <panther@balabit.hu> wrote:
Hi,
Gonzalo Arana wrote:
Try the patch located in http://www.squid-cache.org/bugs/show_bug.cgi?id=2129 Please, note that this is still unofficial path. Any feedback about it is much appreciated.
Does the foreign bind work with this patch? I rewrote the patch for
Indeed. I believe it is called freebind.
2.6-STABLE18 and perhaps I missed something. What I see on the webserver is that the squid connects with its own IP address instead of the client's address. Config: http_port 3128 tproxy
Odd. My patch requires that comm_fdopenex be called with COMM_FREEBIND, so that setsockopt(fd, SOL_IP, IP_FREEBIND, &on, ...) is called before bind(2) is.
Sorry if I mentioned something inaccurate, as this is based on my reading of the patch ( and not based on actual testing ) :- 1. The patch requires LINUX_TPROXY to be defined. 2. The patch requires --enable-tproxy to be specified at 'configure'. 3. However, on a machine supporting tproxy-4.0.x, there is no such include file :- #include <linux/netfilter_ipv4/ip_tproxy.h> 4. 'configure' detected the absence of this file, and it silently ignore '--enable-tproxy'. 5. therefore the program has been compiled without LINUX_TPROXY defined. Does it explain why tproxy has not been honoured ? Cheers
Laszlo Attila Toth wrote:
Hi,
Gonzalo Arana wrote:
Try the patch located in http://www.squid-cache.org/bugs/show_bug.cgi?id=2129 Please, note that this is still unofficial path. Any feedback about it is much appreciated.
Does the foreign bind work with this patch? I rewrote the patch for 2.6-STABLE18 and perhaps I missed something. What I see on the webserver is that the squid connects with its own IP address instead of the client's address. Config: http_port 3128 tproxy
When the new patch will work, I publish it. The changes: the --enable-tproxy option is dropped, --enable-linux-netfilter is used only. Also both REDIRECT and TPROXY target can be used in this case. If the tproxy patch isn't in the kernel, it is ignored in squid.
Not answering to this post specifically however I have two comments on squid tproxy patch :- 1. To have two different version of patches and binaries for squid with tproxy 4.0.x and tproxy 4.1.0 is a nuisance and administratively unfortunate. It will be great if the patch can be one, and if there is a way to determine at runtime, whether to pass IP_FREEBIND or IP_TRANSPARENT to setsockopt that will be great. The other way is to adjust the kernel patch for tproxy 4.1.0 to use IP_FREEBIND. But it seems this option has been explored and the kernel folks disagreed with it though ! 2. Removing NET_ADMIN capability for IP_FREEBIND isn't quite necessary for :- (A) the kernel did not enforce NET_ADMIN for IP_FREEBIND is probably by "accident" only. (B) it will have to be re-stored when doing IP_TRANSPARENT. So this going back and forth is just, again administratively unfortunate. Regards.
Ming-Ching Tiew wrote:
Laszlo Attila Toth wrote:
Gonzalo Arana wrote:
Try the patch located in http://www.squid-cache.org/bugs/show_bug.cgi?id=2129 Please, note that this is still unofficial path. Any feedback about it is much appreciated.
Does the foreign bind work with this patch? I rewrote the patch for 2.6-STABLE18 and perhaps I missed something. What I see on the webserver is that the squid connects with its own IP address instead of the client's address. Config: http_port 3128 tproxy
When the new patch will work, I publish it. The changes: the --enable-tproxy option is dropped, --enable-linux-netfilter is used only. Also both REDIRECT and TPROXY target can be used in this case. If the tproxy patch isn't in the kernel, it is ignored in squid.
Not answering to this post specifically however I have two comments on squid tproxy patch :-
1. To have two different version of patches and binaries for squid with tproxy 4.0.x and tproxy 4.1.0 is a nuisance and administratively unfortunate. It will be great if the patch can be one, and if there is a way to determine at runtime, whether to pass IP_FREEBIND or IP_TRANSPARENT to setsockopt that will be great.
As I wrote, it is only for tproxy 4.1. This is because it is pointless to maintain multiple versions. We hope that tproxy 4.1 will be a part of the mainline kernel which is the cleanest version and easiest to use.
The other way is to adjust the kernel patch for tproxy 4.1.0 to use IP_FREEBIND. But it seems this option has been explored and the kernel folks disagreed with it though !
2. Removing NET_ADMIN capability for IP_FREEBIND isn't quite necessary for :-
The new patch is based on the other but I keep this part, for instance. IP_TRANSPARENT socket option requires CAP_NET_ADMIN capability also it cannot be removed. -- Panther
Lazlo, Is it possible to use tproxy 4.1 without conntrack or any other extra state-table? i.e. Do IP_TRANSPARENT requires nat? If that's the case, it involves an extra table (conntrack) to maintain. Freebind only uses filedescriptor table, so it uses less resources I believe. Am I right? Is freebind not accepted by kernel guys? Regards, -- Gonzalo A. Arana
Hello, Gonzalo Arana wrote:
Lazlo,
Is it possible to use tproxy 4.1 without conntrack or any other extra state-table? i.e. Do IP_TRANSPARENT requires nat? If that's the case, it involves an extra table (conntrack) to maintain. Freebind only uses filedescriptor table, so it uses less resources I believe. Am I right? Is freebind not accepted by kernel guys? Regards,
Both IP_TRANPARENT and IP_FREEBIND has administrative purpose: enables/disables specific binds also no extra resource is necessary, and they are not related to the netfilter code. IP_TRANSPARENT is a new socket option for tproxy. It sets/unsets a bit inside struct inet_sock. TProxy 4.1 doesn't require NAT or connection tracking it is independent from it. But if the conntrack is enabled, the socket match has different code to let the SNAT works with it. -- Panther
I have tried the patch for IP_freebind proposed here https://lists.balabit.hu/pipermail/tproxy/2007-December/000638.html and my squid could work with the tproxy4. Before that it loaded the tproxy2 when compiled with --enable-linux-tproxy I hope it can help you. Rivo On mer, 2008-02-27 at 14:33 -0300, Eduardo Schoedler wrote:
Thanks for the FAQ.
I'm using the (B) Version Tproxy 4.0.x. However, I haven't found the patch for squid in the site http://www.balabit.hu/downloads/files/tproxy/.
I'm using SQUID-2.6.17 with "--enable-linux-tproxy". But this compile options activates suppor for tproxy2 instead tproxy4.0.x, right ? How can I found the patch ?
Thanks in advance!
Best Regads,
Eduardo Schoedler.
-------------------------------------------------- From: "Ming-Ching Tiew" <mingching.tiew@redtone.com> Subject: [tproxy] Squid with tproxy extra brief FAQ - take 2
1. There are at least 3 different versions of tproxy kernel patches.
Each tproxy kernel patch is quite strongly tied to a kernel version,
(A) Version Tproxy2 ============= For kernel 2.6.18 URL: http://www.balabit.hu/downloads/files/tproxy/obsolete/
(B) Version Tproxy 4.0.x ================ For kernel 2.6.22 URL: http://www.balabit.hu/downloads/files/tproxy/
(C) Version Tproxy-4.1.0 ================= For kernel 2.6.25 URL: The "official website" is for kernel <=2.6.24 http://people.netfilter.org/hidden/tproxy
but the actual version of tproxy 4.1 for 2.6.25 is here: http://people.balabit.hu/panther/tproxy
The kernel patch might work with nearby kernel versions, for example, tproxy2 might work with kernel 2.6.19; however it will not work will kernel 2.6.22 ( unless you port it ).
2. Do not confuse tproxy kernel patch mentioned above with squid user-space patches.
So far the Squid ( 3.0 and 2.6 ) is only supporting on tproxy2 - the userspace code is integrated.
If you managed to compile Squid without changing the source, perhaps with only minor changes in header files, meaning you are likely either did not successfully link in tproxy support or at best it is using tproxy2, and it will not work with tproxy-4.0.x and tproxy-4.1.0 kernel counterpart.
However, if you patch the squid source, you should be able to get squid to work with tproxy-4.0.x and tproxy-4.1.0.
You can look through the archive of this maillist to look at how to port squid versions to support tproxy-4.0.x and tproxy-4.1.0. Most of the patches floating around are not fully satisfactory, but it could work, at least; but perhaps it will require you to have some programming knowledge.
Here maybe a good start :-
3. All the tproxy kernel patches are not compatible with one another. Each requires it's own way of setup and usage. So before doing anything, check if you have gotten the correct info/tproxy version/patches.
These are some of the info :-
(A) Version Tproxy2 ============ The Squid documentation recommends this :-
ebtables -t broute -A BROUTING -p ipv4 --ip-protocol tcp \ --ip-destination-port 80 -j redirect --redirect-target ACCEPT
This rule will "broute" bridge traffic from br0 to netfilter.
The iptables rule will bring http traffic into local process :-
iptables -t tproxy -A PREROUTING -i br0 -p tcp --dport 80 \ -j TPROXY --on-port 3128
To get SNAT working for tproxy2, there is a need for double NAT, and here was the discussion and patch :-
https://lists.balabit.hu/pipermail/tproxy/2007-October/000537.html
(B) Version tproxy-4.0.x ================ Requires additional patches for SNAT and FWMARK. Some hurdles with bridge.
Bridge problem is to do with packets must be marked PACKET_HOST when heading for br0 as discussed in this tproxy maillist. There have been people saying they will post the patch for it but yet to date, there is none.
This problem can be worked around by brouting the traffic into the real devices instead of br0 :-
INSIDE_DEV=eth0 OUTSIDE_DEV=eth1 ebtables -t broute -A BROUTING -i $INSIDE_DEV -p ipv4 \ --ip-protocol tcp --ip-destination-port 80 \ -j redirect --redirect-target DROP ebtables -t broute -A BROUTING -i $OUTSIDE_DEV -p ipv4 \ --ip-protocol tcp --ip-source-port 80 \ -j redirect --redirect-target DROP
Please note for real interfaces, it's redirect-target DROP and not redirect-target ACCEPT, while doing it on br0, it's redirect-target ACCEPT !
Remember to adjust your iptables rule accordingly since now packets entering and leaving real interfaces instead of br0.
Example :-
iptables -t tproxy -A PREROUTING -i $INSIDE_DEV \ -p tcp --dport 80 -j TPROXY --on-port 3128
For tproxy-4.0.3 remember to apply the additional kernel patches mentioned in this maillist or else the kernel will panic accessing null pointer.
(C) Version tproxy-4.1.0 ================ The ebtables/bridge notes above is equally applicable. However the iptables rules are totally different.
Something like this will be required :-
iptables -t mangle -A PREROUTING -p tcp --dport 80 -j TPROXY \ --tproxy-mark 0x1/0x1 -on-port 3128 iptables -t mangle -N DIVERT iptables -t mangle -A PREROUTING -p tcp -m socket -j DIVERT iptables -t mangle -A DIVERT -j MARK --set-mark 1 iptables -t mangle -A DIVERT -j ACCEPT
ip rule add fwmark 1 lookup 100 ip route add local 0.0.0.0/0 dev lo table 100
_______________________________________________ tproxy mailing list tproxy@lists.balabit.hu https://lists.balabit.hu/mailman/listinfo/tproxy
_______________________________________________ tproxy mailing list tproxy@lists.balabit.hu https://lists.balabit.hu/mailman/listinfo/tproxy
Hello nantenaina Tianarivo !!! Thanks for the link. But, I'm having some troubles to apply it, as you can see below. In your link is another link, to get the the patch as an attachment. http://lists.balabit.hu/pipermail/tproxy/attachments/20071220/c6c74b7c/attac... I've tried it (without the html tags, of course), and did'nt work. # cat squid-tproxy.patch | patch -p1 patching file src/comm.c patch: **** malformed patch at line 7: { Any ideas? Thanks! Best Regards, Eduardo Schoedler. From: nantenaina Tianarivo Subject: Re: [tproxy] Squid with tproxy extra brief FAQ - take 2 I have tried the patch for IP_freebind proposed here https://lists.balabit.hu/pipermail/tproxy/2007-December/000638.html and my squid could work with the tproxy4. Before that it loaded the tproxy2 when compiled with --enable-linux-tproxy I hope it can help you. Rivo On mer, 2008-02-27 at 14:33 -0300, Eduardo Schoedler wrote: Thanks for the FAQ. I'm using the (B) Version Tproxy 4.0.x. However, I haven't found the patch for squid in the site http://www.balabit.hu/downloads/files/tproxy/. I'm using SQUID-2.6.17 with "--enable-linux-tproxy". But this compile options activates suppor for tproxy2 instead tproxy4.0.x, right ? How can I found the patch ? Thanks in advance! Best Regads, Eduardo Schoedler. -------------------------------------------------- From: "Ming-Ching Tiew" <mingching.tiew@redtone.com> Subject: [tproxy] Squid with tproxy extra brief FAQ - take 2 1. There are at least 3 different versions of tproxy kernel patches. Each tproxy kernel patch is quite strongly tied to a kernel version, (A) Version Tproxy2 ============= For kernel 2.6.18 URL: http://www.balabit.hu/downloads/files/tproxy/obsolete/ (B) Version Tproxy 4.0.x ================ For kernel 2.6.22 URL: http://www.balabit.hu/downloads/files/tproxy/ (C) Version Tproxy-4.1.0 ================= For kernel 2.6.25 URL: The "official website" is for kernel <=2.6.24 http://people.netfilter.org/hidden/tproxy but the actual version of tproxy 4.1 for 2.6.25 is here: http://people.balabit.hu/panther/tproxy The kernel patch might work with nearby kernel versions, for example, tproxy2 might work with kernel 2.6.19; however it will not work will kernel 2.6.22 ( unless you port it ). 2. Do not confuse tproxy kernel patch mentioned above with squid user-space patches. So far the Squid ( 3.0 and 2.6 ) is only supporting on tproxy2 - the userspace code is integrated. If you managed to compile Squid without changing the source, perhaps with only minor changes in header files, meaning you are likely either did not successfully link in tproxy support or at best it is using tproxy2, and it will not work with tproxy-4.0.x and tproxy-4.1.0 kernel counterpart. However, if you patch the squid source, you should be able to get squid to work with tproxy-4.0.x and tproxy-4.1.0. You can look through the archive of this maillist to look at how to port squid versions to support tproxy-4.0.x and tproxy-4.1.0. Most of the patches floating around are not fully satisfactory, but it could work, at least; but perhaps it will require you to have some programming knowledge. Here maybe a good start :- 3. All the tproxy kernel patches are not compatible with one another. Each requires it's own way of setup and usage. So before doing anything, check if you have gotten the correct info/tproxy version/patches. These are some of the info :- (A) Version Tproxy2 ============ The Squid documentation recommends this :- ebtables -t broute -A BROUTING -p ipv4 --ip-protocol tcp \ --ip-destination-port 80 -j redirect --redirect-target ACCEPT This rule will "broute" bridge traffic from br0 to netfilter. The iptables rule will bring http traffic into local process :- iptables -t tproxy -A PREROUTING -i br0 -p tcp --dport 80 \ -j TPROXY --on-port 3128 To get SNAT working for tproxy2, there is a need for double NAT, and here was the discussion and patch :- https://lists.balabit.hu/pipermail/tproxy/2007-October/000537.html (B) Version tproxy-4.0.x ================ Requires additional patches for SNAT and FWMARK. Some hurdles with bridge. Bridge problem is to do with packets must be marked PACKET_HOST when heading for br0 as discussed in this tproxy maillist. There have been people saying they will post the patch for it but yet to date, there is none. This problem can be worked around by brouting the traffic into the real devices instead of br0 :- INSIDE_DEV=eth0 OUTSIDE_DEV=eth1 ebtables -t broute -A BROUTING -i $INSIDE_DEV -p ipv4 \ --ip-protocol tcp --ip-destination-port 80 \ -j redirect --redirect-target DROP ebtables -t broute -A BROUTING -i $OUTSIDE_DEV -p ipv4 \ --ip-protocol tcp --ip-source-port 80 \ -j redirect --redirect-target DROP Please note for real interfaces, it's redirect-target DROP and not redirect-target ACCEPT, while doing it on br0, it's redirect-target ACCEPT ! Remember to adjust your iptables rule accordingly since now packets entering and leaving real interfaces instead of br0. Example :- iptables -t tproxy -A PREROUTING -i $INSIDE_DEV \ -p tcp --dport 80 -j TPROXY --on-port 3128 For tproxy-4.0.3 remember to apply the additional kernel patches mentioned in this maillist or else the kernel will panic accessing null pointer. (C) Version tproxy-4.1.0 ================ The ebtables/bridge notes above is equally applicable. However the iptables rules are totally different. Something like this will be required :- iptables -t mangle -A PREROUTING -p tcp --dport 80 -j TPROXY \ --tproxy-mark 0x1/0x1 -on-port 3128 iptables -t mangle -N DIVERT iptables -t mangle -A PREROUTING -p tcp -m socket -j DIVERT iptables -t mangle -A DIVERT -j MARK --set-mark 1 iptables -t mangle -A DIVERT -j ACCEPT ip rule add fwmark 1 lookup 100 ip route add local 0.0.0.0/0 dev lo table 100
Hello, Eduardo Schoedler:
Hello nantenaina Tianarivo !!!
Thanks for the link. But, I'm having some troubles to apply it, as you can see below.
In your link is another link, to get the the patch as an attachment. http://lists.balabit.hu/pipermail/tproxy/attachments/20071220/c6c74b7c/attac... I've tried it (without the html tags, of course), and did'nt work.
# cat squid-tproxy.patch | patch -p1 patching file src/comm.c patch: **** malformed patch at line 7: { Any ideas?
Thanks!
Best Regards,
Eduardo Schoedler.
In the next few days I'll try to fix the squid patch. It will be for tproxy 4.1 but it can be easily used with 4.0.x since the only difference is the socket option: IP_TRANSPARENT for 4.1 and IP_FREEBIND for 4.0. -- Panther
I had this problem also when I patched my squid package. I didn't find any link where you can get this patch as. For me, I have done manually all changes described in this patch and it worked. On jeu, 2008-02-28 at 08:58 -0300, Eduardo Schoedler wrote:
Hello nantenaina Tianarivo !!!
Thanks for the link. But, I'm having some troubles to apply it, as you can see below.
In your link is another link, to get the the patch as an attachment. http://lists.balabit.hu/pipermail/tproxy/attachments/20071220/c6c74b7c/attac... I've tried it (without the html tags, of course), and did'nt work.
# cat squid-tproxy.patch | patch -p1 patching file src/comm.c patch: **** malformed patch at line 7: {
Any ideas?
Thanks!
Best Regards,
Eduardo Schoedler.
From: nantenaina Tianarivo Subject: Re: [tproxy] Squid with tproxy extra brief FAQ - take 2
I have tried the patch for IP_freebind proposed here https://lists.balabit.hu/pipermail/tproxy/2007-December/000638.html and my squid could work with the tproxy4. Before that it loaded the tproxy2 when compiled with --enable-linux-tproxy
I hope it can help you. Rivo On mer, 2008-02-27 at 14:33 -0300, Eduardo Schoedler wrote:
Thanks for the FAQ.
I'm using the (B) Version Tproxy 4.0.x. However, I haven't found the patch for squid in the site http://www.balabit.hu/downloads/files/tproxy/.
I'm using SQUID-2.6.17 with "--enable-linux-tproxy". But this compile options activates suppor for tproxy2 instead tproxy4.0.x, right ? How can I found the patch ?
Thanks in advance!
Best Regads,
Eduardo Schoedler.
-------------------------------------------------- From: "Ming-Ching Tiew" <mingching.tiew@redtone.com> Subject: [tproxy] Squid with tproxy extra brief FAQ - take 2
1. There are at least 3 different versions of tproxy kernel patches.
Each tproxy kernel patch is quite strongly tied to a kernel version,
(A) Version Tproxy2 ============= For kernel 2.6.18 URL: http://www.balabit.hu/downloads/files/tproxy/obsolete/
(B) Version Tproxy 4.0.x ================ For kernel 2.6.22 URL: http://www.balabit.hu/downloads/files/tproxy/
(C) Version Tproxy-4.1.0 ================= For kernel 2.6.25 URL: The "official website" is for kernel <=2.6.24 http://people.netfilter.org/hidden/tproxy
but the actual version of tproxy 4.1 for 2.6.25 is here: http://people.balabit.hu/panther/tproxy
The kernel patch might work with nearby kernel versions, for example, tproxy2 might work with kernel 2.6.19; however it will not work will kernel 2.6.22 ( unless you port it ).
2. Do not confuse tproxy kernel patch mentioned above with squid user-space patches.
So far the Squid ( 3.0 and 2.6 ) is only supporting on tproxy2 - the userspace code is integrated.
If you managed to compile Squid without changing the source, perhaps with only minor changes in header files, meaning you are likely either did not successfully link in tproxy support or at best it is using tproxy2, and it will not work with tproxy-4.0.x and tproxy-4.1.0 kernel counterpart.
However, if you patch the squid source, you should be able to get squid to work with tproxy-4.0.x and tproxy-4.1.0.
You can look through the archive of this maillist to look at how to port squid versions to support tproxy-4.0.x and tproxy-4.1.0. Most of the patches floating around are not fully satisfactory, but it could work, at least; but perhaps it will require you to have some programming knowledge.
Here maybe a good start :-
3. All the tproxy kernel patches are not compatible with one another. Each requires it's own way of setup and usage. So before doing anything, check if you have gotten the correct info/tproxy version/patches.
These are some of the info :-
(A) Version Tproxy2 ============ The Squid documentation recommends this :-
ebtables -t broute -A BROUTING -p ipv4 --ip-protocol tcp \ --ip-destination-port 80 -j redirect --redirect-target ACCEPT
This rule will "broute" bridge traffic from br0 to netfilter.
The iptables rule will bring http traffic into local process :-
iptables -t tproxy -A PREROUTING -i br0 -p tcp --dport 80 \ -j TPROXY --on-port 3128
To get SNAT working for tproxy2, there is a need for double NAT, and here was the discussion and patch :-
https://lists.balabit.hu/pipermail/tproxy/2007-October/000537.html
(B) Version tproxy-4.0.x ================ Requires additional patches for SNAT and FWMARK. Some hurdles with bridge.
Bridge problem is to do with packets must be marked PACKET_HOST when heading for br0 as discussed in this tproxy maillist. There have been people saying they will post the patch for it but yet to date, there is none.
This problem can be worked around by brouting the traffic into the real devices instead of br0 :-
INSIDE_DEV=eth0 OUTSIDE_DEV=eth1 ebtables -t broute -A BROUTING -i $INSIDE_DEV -p ipv4 \ --ip-protocol tcp --ip-destination-port 80 \ -j redirect --redirect-target DROP ebtables -t broute -A BROUTING -i $OUTSIDE_DEV -p ipv4 \ --ip-protocol tcp --ip-source-port 80 \ -j redirect --redirect-target DROP
Please note for real interfaces, it's redirect-target DROP and not redirect-target ACCEPT, while doing it on br0, it's redirect-target ACCEPT !
Remember to adjust your iptables rule accordingly since now packets entering and leaving real interfaces instead of br0.
Example :-
iptables -t tproxy -A PREROUTING -i $INSIDE_DEV \ -p tcp --dport 80 -j TPROXY --on-port 3128
For tproxy-4.0.3 remember to apply the additional kernel patches mentioned in this maillist or else the kernel will panic accessing null pointer.
(C) Version tproxy-4.1.0 ================ The ebtables/bridge notes above is equally applicable. However the iptables rules are totally different.
Something like this will be required :-
iptables -t mangle -A PREROUTING -p tcp --dport 80 -j TPROXY \ --tproxy-mark 0x1/0x1 -on-port 3128 iptables -t mangle -N DIVERT iptables -t mangle -A PREROUTING -p tcp -m socket -j DIVERT iptables -t mangle -A DIVERT -j MARK --set-mark 1 iptables -t mangle -A DIVERT -j ACCEPT
ip rule add fwmark 1 lookup 100 ip route add local 0.0.0.0/0 dev lo table 100
_______________________________________________ tproxy mailing list tproxy@lists.balabit.hu https://lists.balabit.hu/mailman/listinfo/tproxy
Hey people!!! Good news!!! It worked !!! \o/ I've installed the new patch tproxy-4.0.4-2.6.22 in kernel-2.6.22-r10 and iptables-1.3.8-r2. My problem was exactly the patch for squid-2.6.STABLE16. So, how I sad, I've done it by hand, using the patch from https://lists.balabit.hu/pipermail/tproxy/2007-December/000638.html. I've generated a patch file, so if everyone want's it, just contact me. Thanks for all !!! Sorry my bad english... =) Best Regards, Eduardo Schoedler. -------------------------------------------------------------------------------------- From: nantenaina Tianarivo Subject: Re: [tproxy] Squid with tproxy extra brief FAQ - take 2 I had this problem also when I patched my squid package. I didn't find any link where you can get this patch as. For me, I have done manually all changes described in this patch and it worked. On jeu, 2008-02-28 at 08:58 -0300, Eduardo Schoedler wrote: Hello nantenaina Tianarivo !!! Thanks for the link. But, I'm having some troubles to apply it, as you can see below. In your link is another link, to get the the patch as an attachment. http://lists.balabit.hu/pipermail/tproxy/attachments/20071220/c6c74b7c/attac... I've tried it (without the html tags, of course), and did'nt work. # cat squid-tproxy.patch | patch -p1 patching file src/comm.c patch: **** malformed patch at line 7: { Any ideas? Thanks! Best Regards, Eduardo Schoedler. From: nantenaina Tianarivo Subject: Re: [tproxy] Squid with tproxy extra brief FAQ - take 2 I have tried the patch for IP_freebind proposed here https://lists.balabit.hu/pipermail/tproxy/2007-December/000638.html and my squid could work with the tproxy4. Before that it loaded the tproxy2 when compiled with --enable-linux-tproxy I hope it can help you. Rivo On mer, 2008-02-27 at 14:33 -0300, Eduardo Schoedler wrote: Thanks for the FAQ. I'm using the (B) Version Tproxy 4.0.x. However, I haven't found the patch for squid in the site http://www.balabit.hu/downloads/files/tproxy/. I'm using SQUID-2.6.17 with "--enable-linux-tproxy". But this compile options activates suppor for tproxy2 instead tproxy4.0.x, right ? How can I found the patch ? Thanks in advance! Best Regads, Eduardo Schoedler. -------------------------------------------------- From: "Ming-Ching Tiew" <mingching.tiew@redtone.com> Subject: [tproxy] Squid with tproxy extra brief FAQ - take 2 1. There are at least 3 different versions of tproxy kernel patches. Each tproxy kernel patch is quite strongly tied to a kernel version, (A) Version Tproxy2 ============= For kernel 2.6.18 URL: http://www.balabit.hu/downloads/files/tproxy/obsolete/ (B) Version Tproxy 4.0.x ================ For kernel 2.6.22 URL: http://www.balabit.hu/downloads/files/tproxy/ (C) Version Tproxy-4.1.0 ================= For kernel 2.6.25 URL: The "official website" is for kernel <=2.6.24 http://people.netfilter.org/hidden/tproxy but the actual version of tproxy 4.1 for 2.6.25 is here: http://people.balabit.hu/panther/tproxy The kernel patch might work with nearby kernel versions, for example, tproxy2 might work with kernel 2.6.19; however it will not work will kernel 2.6.22 ( unless you port it ). 2. Do not confuse tproxy kernel patch mentioned above with squid user-space patches. So far the Squid ( 3.0 and 2.6 ) is only supporting on tproxy2 - the userspace code is integrated. If you managed to compile Squid without changing the source, perhaps with only minor changes in header files, meaning you are likely either did not successfully link in tproxy support or at best it is using tproxy2, and it will not work with tproxy-4.0.x and tproxy-4.1.0 kernel counterpart. However, if you patch the squid source, you should be able to get squid to work with tproxy-4.0.x and tproxy-4.1.0. You can look through the archive of this maillist to look at how to port squid versions to support tproxy-4.0.x and tproxy-4.1.0. Most of the patches floating around are not fully satisfactory, but it could work, at least; but perhaps it will require you to have some programming knowledge. Here maybe a good start :- 3. All the tproxy kernel patches are not compatible with one another. Each requires it's own way of setup and usage. So before doing anything, check if you have gotten the correct info/tproxy version/patches. These are some of the info :- (A) Version Tproxy2 ============ The Squid documentation recommends this :- ebtables -t broute -A BROUTING -p ipv4 --ip-protocol tcp \ --ip-destination-port 80 -j redirect --redirect-target ACCEPT This rule will "broute" bridge traffic from br0 to netfilter. The iptables rule will bring http traffic into local process :- iptables -t tproxy -A PREROUTING -i br0 -p tcp --dport 80 \ -j TPROXY --on-port 3128 To get SNAT working for tproxy2, there is a need for double NAT, and here was the discussion and patch :- https://lists.balabit.hu/pipermail/tproxy/2007-October/000537.html (B) Version tproxy-4.0.x ================ Requires additional patches for SNAT and FWMARK. Some hurdles with bridge. Bridge problem is to do with packets must be marked PACKET_HOST when heading for br0 as discussed in this tproxy maillist. There have been people saying they will post the patch for it but yet to date, there is none. This problem can be worked around by brouting the traffic into the real devices instead of br0 :- INSIDE_DEV=eth0 OUTSIDE_DEV=eth1 ebtables -t broute -A BROUTING -i $INSIDE_DEV -p ipv4 \ --ip-protocol tcp --ip-destination-port 80 \ -j redirect --redirect-target DROP ebtables -t broute -A BROUTING -i $OUTSIDE_DEV -p ipv4 \ --ip-protocol tcp --ip-source-port 80 \ -j redirect --redirect-target DROP Please note for real interfaces, it's redirect-target DROP and not redirect-target ACCEPT, while doing it on br0, it's redirect-target ACCEPT ! Remember to adjust your iptables rule accordingly since now packets entering and leaving real interfaces instead of br0. Example :- iptables -t tproxy -A PREROUTING -i $INSIDE_DEV \ -p tcp --dport 80 -j TPROXY --on-port 3128 For tproxy-4.0.3 remember to apply the additional kernel patches mentioned in this maillist or else the kernel will panic accessing null pointer. (C) Version tproxy-4.1.0 ================ The ebtables/bridge notes above is equally applicable. However the iptables rules are totally different. Something like this will be required :- iptables -t mangle -A PREROUTING -p tcp --dport 80 -j TPROXY \ --tproxy-mark 0x1/0x1 -on-port 3128 iptables -t mangle -N DIVERT iptables -t mangle -A PREROUTING -p tcp -m socket -j DIVERT iptables -t mangle -A DIVERT -j MARK --set-mark 1 iptables -t mangle -A DIVERT -j ACCEPT ip rule add fwmark 1 lookup 100 ip route add local 0.0.0.0/0 dev lo table 100
Just one thing I've forgot... Why can't I download from inside my linux/tproxy/squid box ? # wget http://gentoo.osuosl.org/snapshots/portage-20080229.tar.bz2 --19:59:40-- http://gentoo.osuosl.org/snapshots/portage-20080229.tar.bz2 => `portage-20080229.tar.bz2' Resolving gentoo.osuosl.org... 140.211.166.134 Connecting to gentoo.osuosl.org|140.211.166.134|:80... failed: Connection timed out. Retrying. --19:59:43-- http://gentoo.osuosl.org/snapshots/portage-20080229.tar.bz2 (try: 2) => `portage-20080229.tar.bz2' Connecting to gentoo.osuosl.org|140.211.166.134|:80... Here's my ebtables rules: Bridge chain: BROUTING, entries: 2, policy: ACCEPT -p IPv4 -i eth1 --ip-proto tcp --ip-dport 80 -j redirect --redirect-target DROP -p IPv4 -i eth0 --ip-proto tcp --ip-sport 80 -j redirect --redirect-target DROP ... and here my iptables rules: Chain PREROUTING (policy ACCEPT) target prot opt source destination TPROXY tcp -- anywhere anywhere tcp dpt:http TPROXY redirect 0.0.0.0:3128 Any idea? Thanks in advance. Best Regards, Eduardo Schoedler. -------------------------------------------------- From: "Eduardo Schoedler" <eschoedler@viavale.com.br> Subject: Re: [tproxy] Squid with tproxy extra brief FAQ - take 2 Hey people!!! Good news!!! It worked !!! \o/ I've installed the new patch tproxy-4.0.4-2.6.22 in kernel-2.6.22-r10 and iptables-1.3.8-r2. My problem was exactly the patch for squid-2.6.STABLE16. So, how I sad, I've done it by hand, using the patch from https://lists.balabit.hu/pipermail/tproxy/2007-December/000638.html. I've generated a patch file, so if everyone want's it, just contact me. Thanks for all !!! Sorry my bad english... =) Best Regards, Eduardo Schoedler. -------------------------------------------------------------------------------------- From: nantenaina Tianarivo Subject: Re: [tproxy] Squid with tproxy extra brief FAQ - take 2 I had this problem also when I patched my squid package. I didn't find any link where you can get this patch as. For me, I have done manually all changes described in this patch and it worked. On jeu, 2008-02-28 at 08:58 -0300, Eduardo Schoedler wrote: Hello nantenaina Tianarivo !!! Thanks for the link. But, I'm having some troubles to apply it, as you can see below. In your link is another link, to get the the patch as an attachment. http://lists.balabit.hu/pipermail/tproxy/attachments/20071220/c6c74b7c/attac... I've tried it (without the html tags, of course), and did'nt work. # cat squid-tproxy.patch | patch -p1 patching file src/comm.c patch: **** malformed patch at line 7: { Any ideas? Thanks! Best Regards, Eduardo Schoedler. From: nantenaina Tianarivo Subject: Re: [tproxy] Squid with tproxy extra brief FAQ - take 2 I have tried the patch for IP_freebind proposed here https://lists.balabit.hu/pipermail/tproxy/2007-December/000638.html and my squid could work with the tproxy4. Before that it loaded the tproxy2 when compiled with --enable-linux-tproxy I hope it can help you. Rivo On mer, 2008-02-27 at 14:33 -0300, Eduardo Schoedler wrote: Thanks for the FAQ. I'm using the (B) Version Tproxy 4.0.x. However, I haven't found the patch for squid in the site http://www.balabit.hu/downloads/files/tproxy/. I'm using SQUID-2.6.17 with "--enable-linux-tproxy". But this compile options activates suppor for tproxy2 instead tproxy4.0.x, right ? How can I found the patch ? Thanks in advance! Best Regads, Eduardo Schoedler. -------------------------------------------------- From: "Ming-Ching Tiew" <mingching.tiew@redtone.com> Subject: [tproxy] Squid with tproxy extra brief FAQ - take 2 1. There are at least 3 different versions of tproxy kernel patches. Each tproxy kernel patch is quite strongly tied to a kernel version, (A) Version Tproxy2 ============= For kernel 2.6.18 URL: http://www.balabit.hu/downloads/files/tproxy/obsolete/ (B) Version Tproxy 4.0.x ================ For kernel 2.6.22 URL: http://www.balabit.hu/downloads/files/tproxy/ (C) Version Tproxy-4.1.0 ================= For kernel 2.6.25 URL: The "official website" is for kernel <=2.6.24 http://people.netfilter.org/hidden/tproxy but the actual version of tproxy 4.1 for 2.6.25 is here: http://people.balabit.hu/panther/tproxy The kernel patch might work with nearby kernel versions, for example, tproxy2 might work with kernel 2.6.19; however it will not work will kernel 2.6.22 ( unless you port it ). 2. Do not confuse tproxy kernel patch mentioned above with squid user-space patches. So far the Squid ( 3.0 and 2.6 ) is only supporting on tproxy2 - the userspace code is integrated. If you managed to compile Squid without changing the source, perhaps with only minor changes in header files, meaning you are likely either did not successfully link in tproxy support or at best it is using tproxy2, and it will not work with tproxy-4.0.x and tproxy-4.1.0 kernel counterpart. However, if you patch the squid source, you should be able to get squid to work with tproxy-4.0.x and tproxy-4.1.0. You can look through the archive of this maillist to look at how to port squid versions to support tproxy-4.0.x and tproxy-4.1.0. Most of the patches floating around are not fully satisfactory, but it could work, at least; but perhaps it will require you to have some programming knowledge. Here maybe a good start :- 3. All the tproxy kernel patches are not compatible with one another. Each requires it's own way of setup and usage. So before doing anything, check if you have gotten the correct info/tproxy version/patches. These are some of the info :- (A) Version Tproxy2 ============ The Squid documentation recommends this :- ebtables -t broute -A BROUTING -p ipv4 --ip-protocol tcp \ --ip-destination-port 80 -j redirect --redirect-target ACCEPT This rule will "broute" bridge traffic from br0 to netfilter. The iptables rule will bring http traffic into local process :- iptables -t tproxy -A PREROUTING -i br0 -p tcp --dport 80 \ -j TPROXY --on-port 3128 To get SNAT working for tproxy2, there is a need for double NAT, and here was the discussion and patch :- https://lists.balabit.hu/pipermail/tproxy/2007-October/000537.html (B) Version tproxy-4.0.x ================ Requires additional patches for SNAT and FWMARK. Some hurdles with bridge. Bridge problem is to do with packets must be marked PACKET_HOST when heading for br0 as discussed in this tproxy maillist. There have been people saying they will post the patch for it but yet to date, there is none. This problem can be worked around by brouting the traffic into the real devices instead of br0 :- INSIDE_DEV=eth0 OUTSIDE_DEV=eth1 ebtables -t broute -A BROUTING -i $INSIDE_DEV -p ipv4 \ --ip-protocol tcp --ip-destination-port 80 \ -j redirect --redirect-target DROP ebtables -t broute -A BROUTING -i $OUTSIDE_DEV -p ipv4 \ --ip-protocol tcp --ip-source-port 80 \ -j redirect --redirect-target DROP Please note for real interfaces, it's redirect-target DROP and not redirect-target ACCEPT, while doing it on br0, it's redirect-target ACCEPT ! Remember to adjust your iptables rule accordingly since now packets entering and leaving real interfaces instead of br0. Example :- iptables -t tproxy -A PREROUTING -i $INSIDE_DEV \ -p tcp --dport 80 -j TPROXY --on-port 3128 For tproxy-4.0.3 remember to apply the additional kernel patches mentioned in this maillist or else the kernel will panic accessing null pointer. (C) Version tproxy-4.1.0 ================ The ebtables/bridge notes above is equally applicable. However the iptables rules are totally different. Something like this will be required :- iptables -t mangle -A PREROUTING -p tcp --dport 80 -j TPROXY \ --tproxy-mark 0x1/0x1 -on-port 3128 iptables -t mangle -N DIVERT iptables -t mangle -A PREROUTING -p tcp -m socket -j DIVERT iptables -t mangle -A DIVERT -j MARK --set-mark 1 iptables -t mangle -A DIVERT -j ACCEPT ip rule add fwmark 1 lookup 100 ip route add local 0.0.0.0/0 dev lo table 100
Just one thing I've forgot... Why can't I download from inside my linux/tproxy/squid box ? # wget http://gentoo.osuosl.org/snapshots/portage-20080229.tar.bz2 --19:59:40-- http://gentoo.osuosl.org/snapshots/portage-20080229.tar.bz2 => `portage-20080229.tar.bz2' Resolving gentoo.osuosl.org... 140.211.166.134 Connecting to gentoo.osuosl.org|140.211.166.134|:80... failed: Connection timed out. Retrying. --19:59:43-- http://gentoo.osuosl.org/snapshots/portage-20080229.tar.bz2 (try: 2) => `portage-20080229.tar.bz2' Connecting to gentoo.osuosl.org|140.211.166.134|:80... Here's my ebtables rules: Bridge chain: BROUTING, entries: 2, policy: ACCEPT -p IPv4 -i eth1 --ip-proto tcp --ip-dport 80 -j redirect --redirect-target DROP -p IPv4 -i eth0 --ip-proto tcp --ip-sport 80 -j redirect --redirect-target DROP ... and here my iptables rules: Chain PREROUTING (policy ACCEPT) target prot opt source destination TPROXY tcp -- anywhere anywhere tcp dpt:http TPROXY redirect 0.0.0.0:3128 Any idea? Thanks in advance. Best Regards, Eduardo Schoedler.
participants (5)
-
Eduardo Schoedler
-
Gonzalo Arana
-
Laszlo Attila Toth
-
Ming-Ching Tiew
-
nantenaina Tianarivo