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? 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? Thanks, Cam
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
Balazs Scheidler wrote:
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.
It's funny, because I have things almost working with the TProxy 2 NAT based code, with the exception of FTP data channel transparency. I'm still not exactly sure why that wasn't working, because I moved to the v4 code.
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.
Which socket lookup are you referring to? It seems that __inet_lookup does use the interface to match against the device the socket was bound to. The routing hash doesn't appear to use the ports for the lookup, but I don't think that's as important.
If you change the client source port to a dynamically allocated one, it should work, as the two sockets will not clash.
I'd prefer not to have to do that, if at all possible. Lastly, do you think brouting around the bridge to keep the transparent traffic locally routed would make any difference with what I'm trying to do? Or am I going to run into the same socket lookup issues I am now with the bridge? Thanks for the help. It is appreciated. Cam
participants (2)
-
Balazs Scheidler
-
Cameron Schaus