tproxy on bridge interface
Hello there, we have working machine with kernel 2.6.17.14, tproxy-4.0.1 and zorp 3.0.8. Network configuration of this router is: eth0: 192.168.0.1/24 eth1.10: 192.168.1.1/24 (eth1 vlan 10) eth1.11: 192.168.2.1/24 (eth1 vlan 11) dummy0: 192.168.3.1/32 Testing client is at 192.168.0.2 and testing http server at 192.168.2.2 (on vlan 11). When I load tproxy module with tproxy_any=1 and configure zorp for transparent proxying, everything works fine. But when I bind eth1.10 and eth1.11 to a bridge (br1): brctl addbr br1 brctl addif br1 eth1.10 brctl addif br1 eth1.11 ifconfig br1 192.168.1.1 netmask 255.255.255.0 ifconfig br1:0 192.168.2.1 netmask 255.255.255.0 then I can reach 192.168.2.2 from the route and from client, but zorp cannot. Communication flows from the client to the router, is redirected to zorp, zorp catches it, binds to clients ip address and sends SYN packet to the http server. But communication from the http server passes thru tproxy box without being catched by tproxy mechanisms. In the other words - client sees responses from zorp and responses from http server to zorp. Zorp never gets a packet from http server. I don't know what is wrong. Is it known issue? Is there any workaround for this problem? Thank you for any idea Ondrej Kraus
Ondrej Kraus wrote:
I don't know what is wrong. Is it known issue? Is there any workaround for this problem?
I have done some previous investigation around using tproxy4 code on a bridge interface. I found that the bridge code clobbers the dst route entry added by tproxy4 during prerouting, and that packets processed by tproxy destined for the localhost need to be marked with a packet type of PACKET_HOST otherwise they are dropped higher up the stack. I don't have a patch right now, but I can get you a diff of the bridge code changes needed to make this work if you are interested. The changes are fairly minor. Cam
participants (2)
-
Cameron Schaus
-
Ondrej Kraus