Hello everybody, I am tring to make tproxy work with our squid but I have a problem with the iptable to redirect traffic to squid now. I have compiled a linux kernel 2.6.22.18 patched with tproxy-4.0.3-2.6.22. and iptable 1.3.8. For squid, i'am using Version 2.6.STABLE5. I think my kernel is well compiled because I see all the tproxy module loaded : proxy:/usr/src/linux# lsmod | grep -i proxy xt_tproxy 1984 0 xt_TPROXY 1984 1 iptable_tproxy 6468 2 xt_TPROXY ip_tables 12420 2 iptable_filter,iptable_tproxy x_tables 14564 5 ipt_LOG,xt_tcpudp,xt_tproxy,xt_TPROXY,ip_tables My iptables rules is like this : iptables -t tproxy -A PREROUTING -p tcp -m tcp -i gre1 --dport 80 -j LOG iptables -t tproxy -A PREROUTING -p tcp -m tcp -i gre1 --dport 80 -j TPROXY --on-port 80 when I check it with tcpdump, I see traffic for http port on the gre1 interface proxy:/usr/src/linux# tcpdump -n -i gre1 tcpdump: WARNING: arptype 778 not supported by libpcap - falling back to cooked socket tcpdump: verbose output suppressed, use -v or -vv for full protocol decode listening on gre1, link-type LINUX_SLL (Linux cooked), capture size 96 bytes 13:10:51.437856 IP 62.56.240.17.3200 > 84.16.80.10.80: . ack 3247536657 win 2264 <nop,nop,timestamp 24199037 1582152> 13:10:51.492666 IP 62.56.240.17.3199 > 84.16.80.10.80: . ack 3204902926 win 3604 <nop,nop,timestamp 24199051 1582156> 13:10:51.523999 IP 62.56.240.17.3198 > 84.16.80.10.80: . ack 3189913679 win 16022 <nop,nop,timestamp 24199058 1582173> when I check it on access.log of my squid, my requests are actually sent to the squid. But it is not the client ip which is sent to the Internet but the squid box IP. when I issue iptables-save -c command to check if there are traffic that enter my iptables rule, the counter so zero traffic. proxy:/usr/src/linux# iptables-save -t tproxy -c # Generated by iptables-save v1.3.8 on Wed Feb 20 13:07:45 2008 *tproxy :PREROUTING ACCEPT [128:11992] [0:0] -A PREROUTING -i gre1 -p tcp -m tcp --dport 80 -j LOG [0:0] -A PREROUTING -i gre1 -p tcp -m tcp --dport 80 -j TPROXY --on-port 80 --on-ip 0.0.0.0 COMMIT even the LOG don't tell me anything about traffic in gre1 interfaces. what I see in the log is this error that appear from time to time: Feb 20 13:08:31 proxy squid[2353]: parseHttpRequest: NF getsockopt(SO_ORIGINAL_DST) failed: (92) Protocol not available Feb 20 13:08:31 proxy squid[2353]: tproxy ip=62.56.240.17,0x11f0383e,port=0 ERROR ASSIGN Can anyone tell me why my iptables don't redirect the traffic to the squid? Best Regards Nantenaina Tianarivo Sys Admin Blueline ------------------- Today is what happened to yesterday.
Hello, nantenaina Tianarivo írta:
Hello everybody,
I am tring to make tproxy work with our squid but I have a problem with the iptable to redirect traffic to squid now. I have compiled a linux kernel 2.6.22.18 patched with tproxy-4.0.3-2.6.22. and iptable 1.3.8. For squid, i'am using Version 2.6.STABLE5. I think my kernel is well compiled because I see all the tproxy module loaded :
proxy:/usr/src/linux# lsmod | grep -i proxy xt_tproxy 1984 0 xt_TPROXY 1984 1 iptable_tproxy 6468 2 xt_TPROXY ip_tables 12420 2 iptable_filter,iptable_tproxy x_tables 14564 5 ipt_LOG,xt_tcpudp,xt_tproxy,xt_TPROXY,ip_tables
My iptables rules is like this :
iptables -t tproxy -A PREROUTING -p tcp -m tcp -i gre1 --dport 80 -j LOG iptables -t tproxy -A PREROUTING -p tcp -m tcp -i gre1 --dport 80 -j TPROXY --on-port 80
when I check it with tcpdump, I see traffic for http port on the gre1 interface
proxy:/usr/src/linux# tcpdump -n -i gre1 tcpdump: WARNING: arptype 778 not supported by libpcap - falling back to cooked socket tcpdump: verbose output suppressed, use -v or -vv for full protocol decode listening on gre1, link-type LINUX_SLL (Linux cooked), capture size 96 bytes 13:10:51.437856 IP 62.56.240.17.3200 > 84.16.80.10.80: . ack 3247536657 win 2264 <nop,nop,timestamp 24199037 1582152> 13:10:51.492666 IP 62.56.240.17.3199 > 84.16.80.10.80: . ack 3204902926 win 3604 <nop,nop,timestamp 24199051 1582156> 13:10:51.523999 IP 62.56.240.17.3198 > 84.16.80.10.80: . ack 3189913679 win 16022 <nop,nop,timestamp 24199058 1582173>
when I check it on access.log of my squid, my requests are actually sent to the squid.
But it is not the client ip which is sent to the Internet but the squid box IP.
when I issue iptables-save -c command to check if there are traffic that enter my iptables rule, the counter so zero traffic.
proxy:/usr/src/linux# iptables-save -t tproxy -c # Generated by iptables-save v1.3.8 on Wed Feb 20 13:07:45 2008 *tproxy :PREROUTING ACCEPT [128:11992] [0:0] -A PREROUTING -i gre1 -p tcp -m tcp --dport 80 -j LOG [0:0] -A PREROUTING -i gre1 -p tcp -m tcp --dport 80 -j TPROXY --on-port 80 --on-ip 0.0.0.0 COMMIT
even the LOG don't tell me anything about traffic in gre1 interfaces.
what I see in the log is this error that appear from time to time:
Feb 20 13:08:31 proxy squid[2353]: parseHttpRequest: NF getsockopt(SO_ORIGINAL_DST) failed: (92) Protocol not available Feb 20 13:08:31 proxy squid[2353]: tproxy ip=62.56.240.17,0x11f0383e,port=0 ERROR ASSIGN
It seems you want to use the squid with tproxy patch for tproxyv2 but you use tproxyv4. They are incompatible. The iptables commands are the same but the tproxy4 kernel code is different. When the squid uses tproxy-specific commands, there should be only one clall: set the socket option IP_FREEBIND, _or_ load the tproxy table with the tproxy_any parameter: modprobe iptable_tproxy tproxy_any=1 -- Panther
I have already tried to load the tproxy table with the tproxy_any parameter as you describe because I have seen this in the archive but it didn't solve the problem On mer, 2008-02-20 at 11:45 +0100, Laszlo Attila Toth wrote:
Hello,
nantenaina Tianarivo írta:
Hello everybody,
I am tring to make tproxy work with our squid but I have a problem with the iptable to redirect traffic to squid now. I have compiled a linux kernel 2.6.22.18 patched with tproxy-4.0.3-2.6.22. and iptable 1.3.8. For squid, i'am using Version 2.6.STABLE5. I think my kernel is well compiled because I see all the tproxy module loaded :
proxy:/usr/src/linux# lsmod | grep -i proxy xt_tproxy 1984 0 xt_TPROXY 1984 1 iptable_tproxy 6468 2 xt_TPROXY ip_tables 12420 2 iptable_filter,iptable_tproxy x_tables 14564 5 ipt_LOG,xt_tcpudp,xt_tproxy,xt_TPROXY,ip_tables
My iptables rules is like this :
iptables -t tproxy -A PREROUTING -p tcp -m tcp -i gre1 --dport 80 -j LOG iptables -t tproxy -A PREROUTING -p tcp -m tcp -i gre1 --dport 80 -j TPROXY --on-port 80
when I check it with tcpdump, I see traffic for http port on the gre1 interface
proxy:/usr/src/linux# tcpdump -n -i gre1 tcpdump: WARNING: arptype 778 not supported by libpcap - falling back to cooked socket tcpdump: verbose output suppressed, use -v or -vv for full protocol decode listening on gre1, link-type LINUX_SLL (Linux cooked), capture size 96 bytes 13:10:51.437856 IP 62.56.240.17.3200 > 84.16.80.10.80: . ack 3247536657 win 2264 <nop,nop,timestamp 24199037 1582152> 13:10:51.492666 IP 62.56.240.17.3199 > 84.16.80.10.80: . ack 3204902926 win 3604 <nop,nop,timestamp 24199051 1582156> 13:10:51.523999 IP 62.56.240.17.3198 > 84.16.80.10.80: . ack 3189913679 win 16022 <nop,nop,timestamp 24199058 1582173>
when I check it on access.log of my squid, my requests are actually sent to the squid.
But it is not the client ip which is sent to the Internet but the squid box IP.
when I issue iptables-save -c command to check if there are traffic that enter my iptables rule, the counter so zero traffic.
proxy:/usr/src/linux# iptables-save -t tproxy -c # Generated by iptables-save v1.3.8 on Wed Feb 20 13:07:45 2008 *tproxy :PREROUTING ACCEPT [128:11992] [0:0] -A PREROUTING -i gre1 -p tcp -m tcp --dport 80 -j LOG [0:0] -A PREROUTING -i gre1 -p tcp -m tcp --dport 80 -j TPROXY --on-port 80 --on-ip 0.0.0.0 COMMIT
even the LOG don't tell me anything about traffic in gre1 interfaces.
what I see in the log is this error that appear from time to time:
Feb 20 13:08:31 proxy squid[2353]: parseHttpRequest: NF getsockopt(SO_ORIGINAL_DST) failed: (92) Protocol not available Feb 20 13:08:31 proxy squid[2353]: tproxy ip=62.56.240.17,0x11f0383e,port=0 ERROR ASSIGN
It seems you want to use the squid with tproxy patch for tproxyv2 but you use tproxyv4. They are incompatible. The iptables commands are the same but the tproxy4 kernel code is different.
When the squid uses tproxy-specific commands, there should be only one clall: set the socket option IP_FREEBIND, _or_ load the tproxy table with the tproxy_any parameter:
modprobe iptable_tproxy tproxy_any=1
Hi, nantenaina Tianarivo wrote:
I have already tried to load the tproxy table with the tproxy_any parameter as you describe because I have seen this in the archive but it didn't solve the problem
Strange. It works for me with netcat: On 192.168.10.1 as in 4.0.3's README: echo 1 >/proc/sys/net/ipv4/ip_nonlocal_bind modprobe iptable_tproxy tproxy_any=1 nc -s 192.168.4.7 -p 55 192.168.10.2 678 On 192.168.10.2: ip route add 192.168.4.0/24 via 192.168.10.1 nc -lp 678 The TCP connection is established and data arrive to the other side as expected.
On mer, 2008-02-20 at 11:45 +0100, Laszlo Attila Toth wrote:
Hello,
nantenaina Tianarivo írta:
Hello everybody,
I am tring to make tproxy work with our squid but I have a problem with the iptable to redirect traffic to squid now. I have compiled a linux kernel 2.6.22.18 patched with tproxy-4.0.3-2.6.22. and iptable 1.3.8. For squid, i'am using Version 2.6.STABLE5. I think my kernel is well compiled because I see all the tproxy module loaded :
proxy:/usr/src/linux# lsmod | grep -i proxy xt_tproxy 1984 0 xt_TPROXY 1984 1 iptable_tproxy 6468 2 xt_TPROXY ip_tables 12420 2 iptable_filter,iptable_tproxy x_tables 14564 5 ipt_LOG,xt_tcpudp,xt_tproxy,xt_TPROXY,ip_tables
My iptables rules is like this :
iptables -t tproxy -A PREROUTING -p tcp -m tcp -i gre1 --dport 80 -j LOG iptables -t tproxy -A PREROUTING -p tcp -m tcp -i gre1 --dport 80 -j TPROXY --on-port 80
when I check it with tcpdump, I see traffic for http port on the gre1 interface
proxy:/usr/src/linux# tcpdump -n -i gre1 tcpdump: WARNING: arptype 778 not supported by libpcap - falling back to cooked socket tcpdump: verbose output suppressed, use -v or -vv for full protocol decode listening on gre1, link-type LINUX_SLL (Linux cooked), capture size 96 bytes 13:10:51.437856 IP 62.56.240.17.3200 > 84.16.80.10.80: . ack 3247536657 win 2264 <nop,nop,timestamp 24199037 1582152> 13:10:51.492666 IP 62.56.240.17.3199 > 84.16.80.10.80: . ack 3204902926 win 3604 <nop,nop,timestamp 24199051 1582156> 13:10:51.523999 IP 62.56.240.17.3198 > 84.16.80.10.80: . ack 3189913679 win 16022 <nop,nop,timestamp 24199058 1582173>
when I check it on access.log of my squid, my requests are actually sent to the squid.
But it is not the client ip which is sent to the Internet but the squid box IP.
when I issue iptables-save -c command to check if there are traffic that enter my iptables rule, the counter so zero traffic.
proxy:/usr/src/linux# iptables-save -t tproxy -c # Generated by iptables-save v1.3.8 on Wed Feb 20 13:07:45 2008 *tproxy :PREROUTING ACCEPT [128:11992] [0:0] -A PREROUTING -i gre1 -p tcp -m tcp --dport 80 -j LOG [0:0] -A PREROUTING -i gre1 -p tcp -m tcp --dport 80 -j TPROXY --on-port 80 --on-ip 0.0.0.0 COMMIT
even the LOG don't tell me anything about traffic in gre1 interfaces.
what I see in the log is this error that appear from time to time:
Feb 20 13:08:31 proxy squid[2353]: parseHttpRequest: NF getsockopt(SO_ORIGINAL_DST) failed: (92) Protocol not available Feb 20 13:08:31 proxy squid[2353]: tproxy ip=62.56.240.17,0x11f0383e,port=0 ERROR ASSIGN
It seems you want to use the squid with tproxy patch for tproxyv2 but you use tproxyv4. They are incompatible. The iptables commands are the same but the tproxy4 kernel code is different.
When the squid uses tproxy-specific commands, there should be only one clall: set the socket option IP_FREEBIND, _or_ load the tproxy table with the tproxy_any parameter:
modprobe iptable_tproxy tproxy_any=1
-- Panther
1. There are at least 3 different versions of tproxy kernel patches. Each tproxy kernel patch is quite strongly tied to a kernel version, tproxy2 - kernel 2.6.18 - don't know where it is now, google for it. tproxy-4.0.x - kernel 2.6.22 - balabit website tproxy-4.1.0 - kernel 2.6.25 - netfilter website or balabit website 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. So far Squid ( 3.0 and 2.6 ) is only supporting on tproxy2. If you managed to compile Squid without changing the source, meaning you are likely either did not successfully link in tproxy support or at best it is using tproxy2. 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 entirely satisfactory, but it could work, at least ! There is no one-stop-shop for getting tproxy-4.0.x and tproxy-4.1.0 working right now. 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 :- tproxy2 - Requires additional patch to get SNAT working Don't seem to have problem with bridge tproxy4.0.x - Requires additional patches for SNAT and FWMARK. Some hurdles with bridge. tproxy4.1.0 - Still in the cooking. Some hurdles with bridge.
It works only for when I patched my squid with IP_FREEBIND, I mean the client ip spoofing works. I don't know why modprobe iptable_tproxy tproxy_any=1 didn't work for me. Anywhy thanks guys for your advise were very helpful for me. On jeu, 2008-02-21 at 15:05 +0100, Laszlo Attila Toth wrote:
Hi,
nantenaina Tianarivo wrote:
I have already tried to load the tproxy table with the tproxy_any parameter as you describe because I have seen this in the archive but it didn't solve the problem
Strange. It works for me with netcat:
On 192.168.10.1 as in 4.0.3's README: echo 1 >/proc/sys/net/ipv4/ip_nonlocal_bind modprobe iptable_tproxy tproxy_any=1
nc -s 192.168.4.7 -p 55 192.168.10.2 678
On 192.168.10.2:
ip route add 192.168.4.0/24 via 192.168.10.1 nc -lp 678
The TCP connection is established and data arrive to the other side as expected.
On mer, 2008-02-20 at 11:45 +0100, Laszlo Attila Toth wrote:
Hello,
nantenaina Tianarivo írta:
Hello everybody,
I am tring to make tproxy work with our squid but I have a problem with the iptable to redirect traffic to squid now. I have compiled a linux kernel 2.6.22.18 patched with tproxy-4.0.3-2.6.22. and iptable 1.3.8. For squid, i'am using Version 2.6.STABLE5. I think my kernel is well compiled because I see all the tproxy module loaded :
proxy:/usr/src/linux# lsmod | grep -i proxy xt_tproxy 1984 0 xt_TPROXY 1984 1 iptable_tproxy 6468 2 xt_TPROXY ip_tables 12420 2 iptable_filter,iptable_tproxy x_tables 14564 5 ipt_LOG,xt_tcpudp,xt_tproxy,xt_TPROXY,ip_tables
My iptables rules is like this :
iptables -t tproxy -A PREROUTING -p tcp -m tcp -i gre1 --dport 80 -j LOG iptables -t tproxy -A PREROUTING -p tcp -m tcp -i gre1 --dport 80 -j TPROXY --on-port 80
when I check it with tcpdump, I see traffic for http port on the gre1 interface
proxy:/usr/src/linux# tcpdump -n -i gre1 tcpdump: WARNING: arptype 778 not supported by libpcap - falling back to cooked socket tcpdump: verbose output suppressed, use -v or -vv for full protocol decode listening on gre1, link-type LINUX_SLL (Linux cooked), capture size 96 bytes 13:10:51.437856 IP 62.56.240.17.3200 > 84.16.80.10.80: . ack 3247536657 win 2264 <nop,nop,timestamp 24199037 1582152> 13:10:51.492666 IP 62.56.240.17.3199 > 84.16.80.10.80: . ack 3204902926 win 3604 <nop,nop,timestamp 24199051 1582156> 13:10:51.523999 IP 62.56.240.17.3198 > 84.16.80.10.80: . ack 3189913679 win 16022 <nop,nop,timestamp 24199058 1582173>
when I check it on access.log of my squid, my requests are actually sent to the squid.
But it is not the client ip which is sent to the Internet but the squid box IP.
when I issue iptables-save -c command to check if there are traffic that enter my iptables rule, the counter so zero traffic.
proxy:/usr/src/linux# iptables-save -t tproxy -c # Generated by iptables-save v1.3.8 on Wed Feb 20 13:07:45 2008 *tproxy :PREROUTING ACCEPT [128:11992] [0:0] -A PREROUTING -i gre1 -p tcp -m tcp --dport 80 -j LOG [0:0] -A PREROUTING -i gre1 -p tcp -m tcp --dport 80 -j TPROXY --on-port 80 --on-ip 0.0.0.0 COMMIT
even the LOG don't tell me anything about traffic in gre1 interfaces.
what I see in the log is this error that appear from time to time:
Feb 20 13:08:31 proxy squid[2353]: parseHttpRequest: NF getsockopt(SO_ORIGINAL_DST) failed: (92) Protocol not available Feb 20 13:08:31 proxy squid[2353]: tproxy ip=62.56.240.17,0x11f0383e,port=0 ERROR ASSIGN
It seems you want to use the squid with tproxy patch for tproxyv2 but you use tproxyv4. They are incompatible. The iptables commands are the same but the tproxy4 kernel code is different.
When the squid uses tproxy-specific commands, there should be only one clall: set the socket option IP_FREEBIND, _or_ load the tproxy table with the tproxy_any parameter:
modprobe iptable_tproxy tproxy_any=1
-- nantenaina Tianarivo <rivo@gulfsat.mg>
Hi Ming-Ching Tiew, <These are some of the info :- < < tproxy2 - Requires additional patch to get SNAT working < Don't seem to have problem with bridge Where is the additional patch to get SNAT working ? -- Thanks, -Bin
Bin Liang wrote:
Hi Ming-Ching Tiew,
<These are some of the info :- < < tproxy2 - Requires additional patch to get SNAT working < Don't seem to have problem with bridge
Where is the additional patch to get SNAT working ?
There isn't any, because tproxy2 uses nat and snat would do the same. -- Panther
Hello, thanks for this FAQ. Some additional comments: Ming-Ching Tiew wrote:
1. There are at least 3 different versions of tproxy kernel patches.
Each tproxy kernel patch is quite strongly tied to a kernel version,
tproxy2 - kernel 2.6.18 - don't know where it is now, google for it.
The url is: http://www.balabit.hu/downloads/files/tproxy/obsolete/
tproxy-4.0.x - kernel 2.6.22 - balabit website
http://www.balabit.hu/downloads/files/tproxy/
tproxy-4.1.0 - kernel 2.6.25 - netfilter website or balabit website
AFAIK 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 ).
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 :-
tproxy2 - Requires additional patch to get SNAT working Don't seem to have problem with bridge
tproxy4.0.x - Requires additional patches for SNAT and FWMARK. Some hurdles with bridge.
tproxy4.1.0 - Still in the cooking. Some hurdles with bridge.
Currently the latter version is under testing in bridge environment (when I have enough time for it), but I have no idea yet why it is not working. -- Panther
participants (4)
-
Bin Liang
-
Laszlo Attila Toth
-
Ming-Ching Tiew
-
nantenaina Tianarivo