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