Jan Engelhardt wrote:
How can I make sure packets get routed instead of bridged? Does this involve using the brouting feature of ebtables?
Yes.
In some network layouts, you can use a half-bridge (which is a cool thing but probably requires the same number of steps) to reduce the number of needed ebt rules.
Thanks, using ebtables brouting does appear to work. However, it may be cumbersome for my application to use ebtables rules to keep certain traffic off the bridge while allowing unproxied traffic across the bridge. I have a proxy application running on the bridge IP address, and iptables rules currently direct traffic of interest to the proxy. I want to use the tproxy code to perform a foreign connect using the client's IP address. So the client's and server's addresses are more or less arbitrary. This makes generating ebtables brouting rules that preserve the bridge behavior for non-proxied traffic difficult. What is currently stopping the packets from being diverted locally once they enter the bridge? As I understand it now, the packets destined for the foreign IP address should enter the bridge, and since they are destined for the bridge MAC address they should enter the correct protocol handler. At some point the frames should enter IP tables PREROUTING where the tproxy code is invoked. However, something isn't right. Perhaps it's because the packet device is replaced with the bridge device and this doesn't match the socket information? I'd like to understand what isn't working in this case. One way around this is to add a check in br_handle_frame to get the socket and check if inet->freebind is set, similar to the tproxy prerouting code. One drawback of this is that fragmented IP packets cannot be reassembled to obtain the IP addresses and ports, and would end up lost in the stack. An ebtables module could likely be written to avoid modifying the bridge code. Are there better ways of getting these foreign packets into the network stack when they are destined for a local bridge interface? Thanks, Cam