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