Hello, I have problems with Zorp 3.0.8 (Debian Etch) with tproxy 4.0.0. I compiled kernel 2.6.22.1 without problems. But then I found that the patch is incomplete. There is file .tproxy-test in iptables patch: #!/bin/sh [ -f $KERNEL_DIR/include/linux/netfilter_ipv4/ipt_TPROXY.h ] && echo TPROXY [ -f $KERNEL_DIR/net/ipv4/netfilter/ipt_tproxy.c ] && echo tproxy Tested files are not included in kernel patch. I found ipt_TPROXY.h in patch for Ubuntu kernel and ipt_TPROXY.c in the same patch, but not ipt_tproxy.c. After successfull compilation (I have changed ipt_tproxy.c in .tproxy-test to ipt_TPROXY.c) I tried to follow README instructions, but system behaves very strangely. # iptables -t tproxy -A PREROUTING -p tcp --dport 80 -j TPROXY --on-port 50080 works well, counters increases as traffic flow thru firewall, but Zorp sees nothing and when I stop Zorp, nothing changes, so I think that everything is just routed. # iptables -A INPUT -m tproxy -j ACCEPT produces 'Invalid argument' and if I add: # iptables -t nat -A PREROUTING -p tcp --dport 80 -j DNAT --to-dest IP:50080 Zorp gets connection, but it hangs and no connection comes out from firewall. I think that it is obvious that I am new in Zorp/tproxy and these problems might be very trivial to resolve, but I cannot find anything useful to find resolusion. Thank you for any help. Ondrej Kraus
Hello, The Linux kernel 2.6.17 and 2.6.22 differs in the netfilter code, also tproxy patch differs a little bit too. The tproxy target is ipt_TPROXY in 2.6.17 and xt_TPROXY in 2.6.22, but both version will be xt_TPROXY. On Thursday 09 August 2007 09.16.40 Ondrej Kraus wrote:
#!/bin/sh [ -f $KERNEL_DIR/include/linux/netfilter_ipv4/ipt_TPROXY.h ] && echo TPROXY [ -f $KERNEL_DIR/net/ipv4/netfilter/ipt_tproxy.c ] && echo tproxy
Tested files are not included in kernel patch. I found ipt_TPROXY.h in patch for Ubuntu kernel and ipt_TPROXY.c in the same patch, but not ipt_tproxy.c.
The current files: * tproxy table net/ipv4/netfilter/iptable_tproxy.c * tproxy target In ubuntu-2.6.17 (it will be the same as in 2.6.22) net/ipv4/netfilter/ipt_TPROXY.c include/linux/netfilter_ipv4/ipt_TPROXY.h in 2.6.22 net/netfilter/xt_TPROXY.c include/linux/netfilter/xt_TPROXY.h * tproxy match net/netfilter/xt_tproxy.c
# iptables -A INPUT -m tproxy -j ACCEPT produces 'Invalid argument'
Strange. 2.6.17 works well. I will check it.
I think that it is obvious that I am new in Zorp/tproxy and these problems might be very trivial to resolve, but I cannot find anything useful to find resolusion.
TProxy 4 is new and the 2.6.22 is not fully tested: when INPUT chain empty in the filter table and its default policy is accept it works. -- Regards, Laszlo Attila Toth
Hello, thanks for your quick reply. After compiling with 2.6.17 kernel it works better, but still have problems :). Zorp gets the connection, but connection is immediately closed (reset by peer) after sending anything. Zorp then timeoutes after 10s. My iptables rules: # iptables -t tproxy -A PREROUTING -p tcp --dport 80 -j TPROXY --on-port 50080 # iptables -A INPUT -m tproxy -j ACCEPT Ondrej Laszlo Attila Toth napsal(a):
Hello,
The Linux kernel 2.6.17 and 2.6.22 differs in the netfilter code, also tproxy patch differs a little bit too. The tproxy target is ipt_TPROXY in 2.6.17 and xt_TPROXY in 2.6.22, but both version will be xt_TPROXY.
On Thursday 09 August 2007 09.16.40 Ondrej Kraus wrote:
#!/bin/sh [ -f $KERNEL_DIR/include/linux/netfilter_ipv4/ipt_TPROXY.h ] && echo TPROXY [ -f $KERNEL_DIR/net/ipv4/netfilter/ipt_tproxy.c ] && echo tproxy
Tested files are not included in kernel patch. I found ipt_TPROXY.h in patch for Ubuntu kernel and ipt_TPROXY.c in the same patch, but not ipt_tproxy.c.
The current files: * tproxy table net/ipv4/netfilter/iptable_tproxy.c * tproxy target In ubuntu-2.6.17 (it will be the same as in 2.6.22) net/ipv4/netfilter/ipt_TPROXY.c include/linux/netfilter_ipv4/ipt_TPROXY.h in 2.6.22 net/netfilter/xt_TPROXY.c include/linux/netfilter/xt_TPROXY.h * tproxy match net/netfilter/xt_tproxy.c
# iptables -A INPUT -m tproxy -j ACCEPT produces 'Invalid argument'
Strange. 2.6.17 works well. I will check it.
I think that it is obvious that I am new in Zorp/tproxy and these problems might be very trivial to resolve, but I cannot find anything useful to find resolusion.
TProxy 4 is new and the 2.6.22 is not fully tested: when INPUT chain empty in the filter table and its default policy is accept it works.
-- Ondrej Kraus vedouci oddeleni technickych sluzeb Explorer a.s.
On Thursday 09 August 2007 16.48.13 Ondrej Kraus wrote:
thanks for your quick reply. After compiling with 2.6.17 kernel it works better, but still have problems :).
Zorp gets the connection, but connection is immediately closed (reset by peer) after sending anything. Zorp then timeoutes after 10s.
Hello, By default if you use the TPROXY target to redirect packages to another port, the program, that is listening on the other port, should use IP_FREEBIND socket option because without it the packages don't reach the program. If a program doesn't use this option because it is older such as Zorp 3.0.8 or compiled by someone else such as netcat, IP_FREEBIND cannot be used also a module parameter is the solution: to set tproxy_any to 1. Also try to load iptable_tproxy with tproxy_any=1. It should work. -- Regards, Laszlo Attila Toth
Hello, great, proxy works now - but just in normal transparent fashion. Ip addres of outgoing connection is firewall IP. Thanks Ondrej Laszlo Attila Toth napsal(a):
On Thursday 09 August 2007 16.48.13 Ondrej Kraus wrote:
thanks for your quick reply. After compiling with 2.6.17 kernel it works better, but still have problems :).
Zorp gets the connection, but connection is immediately closed (reset by peer) after sending anything. Zorp then timeoutes after 10s.
Hello,
By default if you use the TPROXY target to redirect packages to another port, the program, that is listening on the other port, should use IP_FREEBIND socket option because without it the packages don't reach the program. If a program doesn't use this option because it is older such as Zorp 3.0.8 or compiled by someone else such as netcat, IP_FREEBIND cannot be used also a module parameter is the solution: to set tproxy_any to 1.
Also try to load iptable_tproxy with tproxy_any=1. It should work.
On Aug 10 2007 13:21, Ondrej Kraus wrote:
Hello,
great, proxy works now - but just in normal transparent fashion.
...which is equivalent to having used REDIRECT instead of TPROXY. (Seriously, what is xt_TPROXY good for?) Jan --
On Friday 10 August 2007 13.23.39 Jan Engelhardt wrote:
On Aug 10 2007 13:21, Ondrej Kraus wrote:
Hello,
great, proxy works now - but just in normal transparent fashion.
...which is equivalent to having used REDIRECT instead of TPROXY. (Seriously, what is xt_TPROXY good for?)
No, not at all. If you use REDIRECT, you must add at least one rule per listening port to accept connections but with the TProxy patch one rule is enough in the INPUT chain. The TRPOXY target marks the packet and the tproxy match accepts marked packets no matter what the original and the new destination port is. It can be simoultaneously used with the MARK target of the mangle table. -- Regards, Laszlo Attila Toth
Hello Jan, yes, you are right, now it works like REDIRECT target. And I hope that it will work as REAL transparent proxy. I think that xt_TPROXY module is just selector which works like STATE module, but selects traffic of connections, made by proxy process (here Zorp). Am I right? Ondrej Jan Engelhardt napsal(a):
On Aug 10 2007 13:21, Ondrej Kraus wrote:
Hello,
great, proxy works now - but just in normal transparent fashion.
...which is equivalent to having used REDIRECT instead of TPROXY. (Seriously, what is xt_TPROXY good for?)
Jan
-- Ondrej Kraus vedouci oddeleni technickych sluzeb Explorer a.s.
On Aug 10 2007 14:01, Ondrej Kraus wrote:
Hello Jan,
yes, you are right, now it works like REDIRECT target. And I hope that it will work as REAL transparent proxy.
I think that xt_TPROXY module is just selector which works like STATE module, but selects traffic of connections, made by proxy process (here Zorp). Am I right?
Hm, I was under the impression that connections which are -j TPROXYied only match -m tproxy. Jan --
Hi, On p, aug 10, 2007 at 01:23:39 +0200, Jan Engelhardt wrote:
(Seriously, what is xt_TPROXY good for?)
The TPROXY and the REDIRECT target used to be quite similar before tproxy v4: both did a simple DNAT to the given address, and TPROXY had magic added to 'mark' packets as tproxy-ed plus some hack to save the original destination address. (Saving the destination address was necessary because we DNAT-ting.) In v4 TPROXY has nothing to do with REDIRECT: in fact it doesn't need NAT at all. Instead, it just assigns the destination socket matching the "redirection address" to the packet, and the TCP and UDP socket lookup code is hacked to use this associated socket instead of doing a (re)lookup with the proper data. Sounds horrible, doesn't it? ;) -- KOVACS Krisztian
participants (4)
-
Jan Engelhardt
-
KOVACS Krisztian
-
Laszlo Attila Toth
-
Ondrej Kraus