[tproxy] tproxy4 and bridge

[Balazs Scheidler]

On Tue, 2007-08-21 at 15:23 -0600, Cameron Schaus wrote:
> I have managed to resolve the problems that prevented trpoxy4 from 
> working on a bridged interface.  There were 2 issues:
> a) bridge netfilter code was clobbering the skb->dst added by tproxy 
> prerouting
> b) changed bridge ingress packet handling routing to inspect 
> skb->ip_tproxy flag, and if set, change dest mac to that of bridge and 
> set skb->pkt_type to PACKET_HOST
> 
> With these changes, the foreign-connect and foreign-listen test programs 
> are working correctly.  I'll post patches against the bridge code once 
> I've validated the changes I've made -- there are a couple of things I'm 
> still not sure about.
> 
> However, I have once concern with tproxy4 and what I'm ultimately trying 
> to accomplish.  Here is the setup:
> 
> Proxy application bound to a bridge interface (192.168.0.73, port 
> 8180).  Traffic destined to port 80 is redirected to the bridge IP, port 
> 8180 with iptables.
> 
> So, if a client, 192.168.0.139, connects to a server, 192.168.0.121 (all 
> the traffic passes through the proxy bridge), the proxy application will 
> then:
>  - create a socket
>  - setsockopt(sock, IP_FREEBIND)
>  - bind(CLIENT_IP, CLIENT_SOURCE_PORT)
>  - connect(SERVER_IP, port 80)
> 
> However, the connect does not work.  Syn packets are sent from the 
> bridge to the server, the server responds with Syn-Ack, but the Syn-Ack 
> packet triggers an ip_rt_bug message:
> ip_rt_bug: 192.168.0.139 -> 192.168.0.73, ?
> 
> Firstly, is it possible to do what I am trying to do with tproxy4?

To be honest I don't know. TProxy 2 used the NAT framework which was
explicitly supported by the bridging framework, so it worked without
problems.

I guess it must be possible to do with tproxy4 as well, but I'm not that
much into bridging myself.

> 
> I suspect that there may be some confusion when the routing code tries 
> to lookup the socket, since it is using the source IP, dest IP and 
> interface to find the socket in the hash.  Won't the client and server 
> socket look similar in this regard?  How would the routing code know 
> which of the 2 sockets an incoming packet is destined for, since all 
> packets arrive on the bridge interface?

The interface does not matter when looking up the socket, so this can be
a real problem, if you want to keep the source port of the client.

If you change the client source port to a dynamically allocated one, it
should work, as the two sockets will not clash.


-- 
Bazsi