On 9/2/25 4:37 PM, Pablo Neira Ayuso wrote:
On Tue, Sep 02, 2025 at 02:08:54PM +0200, Florian Westphal wrote:
Fernando Fernandez Mancera <fmancera@xxxxxxx> wrote:
Expose the input bridge interface ethernet address so it can be used to
redirect the packet to the receiving physical device for processing.
Tested with nft command line tool.
table bridge nat {
chain PREROUTING {
type filter hook prerouting priority 0; policy accept;
ether daddr de:ad:00:00:be:ef meta pkttype set host ether daddr set meta ibrhwdr accept
}
}
Joint work with Pablo Neira.
Sorry for crashing the party.
Can you check if its enough to use the mac address of the port (rather
than the bridge address)?
i.e. add veth0,1 to br0 like this:
br0
a -> [ veth0|veth1 ] -> b
Then check br0 address.
If br0 has address of veth1, then try to redirect
redirect by setting a rule like 'ether daddr set <*veth0 address*>
AFAICS the bridge FDB should treat this as local, just as if one would
have used the bridges mac address.
You are right Florian, I have tested this on the following setup.
1. ping from veth0_a on netns_a to veth1_b on netns_b
+----br0----+
| |
veth0_a------------veth0 veth1--------veth1_b
(192.168.10.10/24) (192.168.10.20/24)
Using the MAC of the port, the packet is consumed by the bridge too and
not forwarded. So, no need for it to be the MAC address of the bridge
itself..
That sounds more generic if it works, yes.
This patch was just mocking the existing behaviour in
net/bridge/netfilter/ebt_redirect.c for this case.
If it works i think it would be better to place a 'fetch device mac
address' in nft_meta rather than this ibrhwdr in bridge meta, because
the former is more generic, even though I don't have a use case other
than bridge-to-local redirects.
I am going to send a new patch implementing a "fetch device mac address"
in nft_meta directly.
Thank you!
That said, if it doesn't work or the ibrhwdr has another advantage
I'm missing then I'm fine with this patch.
Unknown to me, but I am fine with reviewing the existing approach and
understand why this bridge redirect was done like this back in 1999.
