December 2009 - tproxy - lists.balabit.hu

TPROXY behavior when there is no listening socket at the target port
by Ashwani Wason 15 Apr '10

15 Apr '10

Hi All, If one has a TPROXY rule that redirects the packets to a local socket on which there is no one listening then the SYN packets keep getting dropped silently. Is this expected? Without knowing that this would happen my natural expectation was that a RST would be sent by local TCP. Is this by design or a bug? Thanks, - Ashwani

2 1

How does 'dev lo' in tproxy routing rule really work?
by Ashwani Wason 15 Apr '10

15 Apr '10

I want to understand the tproxy rules that have been kindly written for us in http://www.balabit.com/downloads/files/tproxy/README.txt. I understand every aspect of those rules, iptables and iproute2, except this one small highlighted bit in the last rule. ip route add local 0.0.0.0/0 *dev lo* table 100 # ip route show table 100 local default dev lo scope host So packets with fwmark 1 get selected for this routing table, which assumes that all destinations are assigned to this host and hence delivers the packets locally. But the output device is set to 'lo', which is the local loopback device. However even if the proxy is not listening on the IP of lo (say it only has the socket for eth0 and the packet came in on eth0), it still receives the packet. So is the 'lo' here just a way to indicate local delivery to the associated physical interface and does not really represent the actual output interface? Can someone please shed some light on this that is more than a simple yes/no answer? Thank you, - Ashwani

2 1

squid between ciscos using wccp2
by hugo＠gigared.com 03 Dec '09

03 Dec '09

hi, im working on a wccp2+tproxy4+squid transparent cache platform. my issue is trying to put two or more squids receiving the clients packet from clients via a cisco 3560 using wccp2 but the output if squids boxes to the internet are via other 3560. the question is: its reasonable configure wccp2 on the output of squids to the second cisco? a mininal diagram: -> squid1 <- clients <-> cisco(wccpv2) <--> squidn <-->cisco(wccp2)<--> internet regards Hugo Petrucci ------------------------- www.gigared.com

1 0

Re: [tproxy] [tproxy,regression] tproxy broken in 2.6.32
by KOVACS Krisztian 03 Dec '09

03 Dec '09

Hi, On Thu, 2009-12-03 at 14:55 +0100, Patrick McHardy wrote: > jamal wrote: > > BTW, it should be noted that the change from Patrick to fib_validate > > which allows to accept local routes from will also solve this problem. > > My suggestion below is to restore old expected behavior.. > > Agreed, the accept_local sysctl should not be misused for this, > otherwise TPROXY setups wouldn't have source validation anymore. Absolutely agreed. Cheers, Krisztian

1 0

[HELP] Tproxy server Can't receive any client packet
by 박제호 02 Dec '09

02 Dec '09

Hello everyone i have a problem in my transparent proxy test, i recently made up the testbed as below to run the tproxy patched apache proxy [mod_proxy], and i applied all iptables and routing rules with referencing the readme file [http://www.balabit.com/downloads/files/tproxy/README.txt, http://www.mjmwired.net/kernel/Documentation/networking/tproxy.txt] the proxy server listening the port 3128 and i checked there were no problem. but when the client tried to connect the web server, the packets reached to the box and i found the usage counts of filter rules in the mangle table incresed but my tproxy server could not receive any corresponding packet from the socket I want to know why my proxy server can't receive any packet through the socket, Do i need some more DNAT rules ? ---------------- testbed --------------- [client ] <-----> [tproxy patched apache mod_proxy] <-----> [web server] --------------------------------------------------- proxybox [Environment of the tproxy server] 1. kernel kernel 2.6.24 + tproxy-kernel-2.6.24-20080602-165651-1212418611.tar.bz2 [http://www.balabit.com/downloads/files/tproxy/tproxy-kernel-2.6.24-20080602…] 2. iptables iptables 4.0 + tproxy-iptables-1.4.0-20080521-113954-1211362794.patc [http://www.balabit.com/downloads/files/tproxy/tproxy-iptables-1.4.0-2008052…] 3. apache apache 2.2.9 + httpd-2.2.9-tproxy.patch [i got this patch from google and ported it to this version ] here are the config files of the kernel and apache proxy

3 3

Re: [tproxy] SO_BINDTODEVICE and IP_TRANSPARENT (TPROXY)
by Ashwani Wason 02 Dec '09

02 Dec '09

After debugging a bit into how nf_tproxy_get_sock_v4() looks up a listener for foreign connections using __inet_lookup_listener() and compute_score() I found that the problem was happening because of the way I had the TPROXY rules setup. Those rules work if the proxy has a single listening socket for INADDR_ANY. If multiple listening sockets must be used, one for each local address, which is the case for using SO_BINDTODEVICE then the TPROXY rules must also be "fully qualified" (with interface name [-i] and IP address thereof [--on-ip]). So the rules in my example change as follows... Instead of using: > iptables -t mangle -A PREROUTING -p tcp --dport 80 -j TPROXY --tproxy-mark 0x1/0x1 --on-port 4002 Use: iptables -t mangle -A PREROUTING *-i eth0* -p tcp --dport 80 -j TPROXY --tproxy-mark 0x1/0x1 *--on-ip 192.168.0.65* --on-port 4002 iptables -t mangle -A PREROUTING *-i eth1* -p tcp --dport 80 -j TPROXY --tproxy-mark 0x1/0x1 *--on-ip 192.168.1.65* --on-port 4002 With these rules the listening socket was looked up correctly and the sk_bound_dev_if of the socket was honored. - Ashwani PS: Sorry to anyone (Jamal) who already spent any time on this. PPS: Copying the tproxy list in case someone else is looking for this stuff in the future. On Mon, Nov 30, 2009 at 3:15 PM, Ashwani Wason <ashwas(a)gmail.com> wrote: > It appears that SO_BINDTODEVICE is not working when used along with > IP_TRANSPARENT of TPROXY. The use case is for a transparent proxy that > has to handle clients with overlapping IP addresses coming in on > different interfaces (VLANs or physical). Each such interface has a > unique next hop gateway. > > Setup: Kernel 2.6.30.9 built with required TPROXY configuration. A > system with three interfaces, eth0 (192.168.0.65/24), eth0.1 > (10.0.7.65/16), and eth1 (192.168.1.65/24), each with its own default > router and a fairly standard set of TPROXY rules: > > default via 192.168.1.62 dev eth1 > default via 192.168.0.62 dev eth0 > default via 10.0.0.9 dev eth0.1 > > iptables -t mangle -N DIVERT > iptables -t mangle -A DIVERT -j MARK --set-mark 1 > iptables -t mangle -A DIVERT -j ACCEPT > iptables -t mangle -A PREROUTING -p tcp -m socket -j DIVERT > iptables -t mangle -A PREROUTING -p tcp --dport 80 -j TPROXY > --tproxy-mark 0x1/0x1 --on-port 4002 > > ip rule add fwmark 1 iif eth0 lookup 101 > ip rule add fwmark 1 iif eth1 lookup 101 > > ip route add local 0.0.0.0/0 dev lo table 101 > > Additional information: > > * The proxy has a separate listening socket for each interface. > > * On each listening socket the proxy sets the IP_TRANSPARENT option. > It also sets the SO_BINDTODEVICE option (on each socket) to the > associated interface. (I have experimented with the ordering of these > options and setting one before the other has no change in behavior.) > > * The proxy works perfectly fine in "transparent mode" when > SO_BINDTODEVICE is not used. > > * The proxy works perfectly fine in "explicit mode" when > SO_BINDTODEVICE *is used*. > > Now my test is very simple with the expectation that when a SYN comes > in on, say, interface eth0 then the SYN/ACK must go out back on that > interface to the MAC address of the designated next hop router. That > does not seem to happen however. The SYN/ACK is not being sent out at > all, from any interface. It seems that either the SYN or the SYN/ACK > is being eaten up somewhere. No one 'netstat -s' seems to be updated > either. (Since even 'netstat -ant' does not show the TCP connection > state, I suspect that the SYN is being eaten up.) > > When I reconfigure the proxy to be in explicit mode, i.e. not set the > IP_TRANSPARENT option, and have the clients connect directly to the IP > address and port of the proxy then the system works as expected, i.e. > the SYN/ACK (and all subsequent packets) go out on the associated > interface. > > Thank you, > Ashwani >

1 0