[PATCH nf-next] netfilter: nft_meta_bridge: introduce NFT_META_BRI_IIFHWADDR support

[PATCH nf-next] netfilter: nft_meta_bridge: introduce NFT_META_BRI_IIFHWADDR support

[Fernando Fernandez Mancera]

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.

Signed-off-by: Fernando Fernandez Mancera <fmancera@suse.de>
---
v0: this requires a follow-up patch on nft and libnftnl which is ready.
I have tested the result and it matches the behavior of ebtables -j
redirect
---
 include/uapi/linux/netfilter/nf_tables.h |  2 ++
 net/bridge/netfilter/nft_meta_bridge.c   | 11 +++++++++++
 2 files changed, 13 insertions(+)

diff --git a/include/uapi/linux/netfilter/nf_tables.h b/include/uapi/linux/netfilter/nf_tables.h
index 2beb30be2c5f..a0d9daa05a8f 100644
--- a/include/uapi/linux/netfilter/nf_tables.h
+++ b/include/uapi/linux/netfilter/nf_tables.h
@@ -959,6 +959,7 @@ enum nft_exthdr_attributes {
  * @NFT_META_SDIF: slave device interface index
  * @NFT_META_SDIFNAME: slave device interface name
  * @NFT_META_BRI_BROUTE: packet br_netfilter_broute bit
+ * @NFT_META_BRI_IIFHWADDR: packet input bridge interface ethernet address
  */
 enum nft_meta_keys {
 	NFT_META_LEN,
@@ -999,6 +1000,7 @@ enum nft_meta_keys {
 	NFT_META_SDIFNAME,
 	NFT_META_BRI_BROUTE,
 	__NFT_META_IIFTYPE,
+	NFT_META_BRI_IIFHWADDR,
 };
 
 /**
diff --git a/net/bridge/netfilter/nft_meta_bridge.c b/net/bridge/netfilter/nft_meta_bridge.c
index 5adced1e7d0c..b7af36bbd306 100644
--- a/net/bridge/netfilter/nft_meta_bridge.c
+++ b/net/bridge/netfilter/nft_meta_bridge.c
@@ -59,6 +59,13 @@ static void nft_meta_bridge_get_eval(const struct nft_expr *expr,
 		nft_reg_store_be16(dest, htons(p_proto));
 		return;
 	}
+	case NFT_META_BRI_IIFHWADDR:
+		br_dev = nft_meta_get_bridge(in);
+		if (!br_dev)
+			goto err;
+
+		memcpy(dest, br_dev->dev_addr, ETH_ALEN);
+		return;
 	default:
 		return nft_meta_get_eval(expr, regs, pkt);
 	}
@@ -86,6 +93,9 @@ static int nft_meta_bridge_get_init(const struct nft_ctx *ctx,
 	case NFT_META_BRI_IIFVPROTO:
 		len = sizeof(u16);
 		break;
+	case NFT_META_BRI_IIFHWADDR:
+		len = ETH_ALEN;
+		break;
 	default:
 		return nft_meta_get_init(ctx, expr, tb);
 	}
@@ -175,6 +185,7 @@ static int nft_meta_bridge_set_validate(const struct nft_ctx *ctx,
 
 	switch (priv->key) {
 	case NFT_META_BRI_BROUTE:
+	case NFT_META_BRI_IIFHWADDR:
 		hooks = 1 << NF_BR_PRE_ROUTING;
 		break;
 	default:
-- 
2.51.0

Re: [PATCH nf-next] netfilter: nft_meta_bridge: introduce NFT_META_BRI_IIFHWADDR support

[Florian Westphal]

Fernando Fernandez Mancera <fmancera@suse.de> 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.

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.

That said, if it doesn't work or the ibrhwdr has another advantage
I'm missing then I'm fine with this patch.

Re: [PATCH nf-next] netfilter: nft_meta_bridge: introduce NFT_META_BRI_IIFHWADDR support

[Pablo Neira Ayuso]

On Tue, Sep 02, 2025 at 02:08:54PM +0200, Florian Westphal wrote:
> Fernando Fernandez Mancera <fmancera@suse.de> 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.

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.
>
> 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.

Re: [PATCH nf-next] netfilter: nft_meta_bridge: introduce NFT_META_BRI_IIFHWADDR support

[Fernando Fernandez Mancera]

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@suse.de> 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.

Re: [PATCH nf-next] netfilter: nft_meta_bridge: introduce NFT_META_BRI_IIFHWADDR support

[Pablo Neira Ayuso]

On Tue, Sep 02, 2025 at 05:34:02PM +0200, Fernando Fernandez Mancera wrote:
> 
> 
> 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@suse.de> 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..

Thanks for confirming.

But this is going to be a bit strange from usability point of view?

It is easier to explain to users that by setting the br0 mac address
(as we do now) packets are passed up to the local stack.

Maybe both can be added? But I don't have a use-case for iifhwdr apart
from this scenario.

Re: [PATCH nf-next] netfilter: nft_meta_bridge: introduce NFT_META_BRI_IIFHWADDR support

[Fernando Fernandez Mancera]

On 9/2/25 5:58 PM, Pablo Neira Ayuso wrote:
> On Tue, Sep 02, 2025 at 05:34:02PM +0200, Fernando Fernandez Mancera wrote:
>>
>>
>> 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@suse.de> 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..
> 
> Thanks for confirming.
> 
> But this is going to be a bit strange from usability point of view?
> 
> It is easier to explain to users that by setting the br0 mac address
> (as we do now) packets are passed up to the local stack.
> 


That is a good point. I also do not have a different use-case for iifhwdr..

> Maybe both can be added? But I don't have a use-case for iifhwdr apart
> from this scenario.
> 

I guess it won't hurt to implement ibrhwdr now and in the future, if 
needed, implement iifhwdr although they share a use-case? To be honest, 
I was not aware of this detail and I knew about using the bridge mac 
address before.

What do you think Florian?

Re: [PATCH nf-next] netfilter: nft_meta_bridge: introduce NFT_META_BRI_IIFHWADDR support

[Florian Westphal]

Pablo Neira Ayuso <pablo@netfilter.org> wrote:
> >                      +----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..
> 
> Thanks for confirming.
> 
> But this is going to be a bit strange from usability point of view?
> 
> It is easier to explain to users that by setting the br0 mac address
> (as we do now) packets are passed up to the local stack.

Fair point.
So lets just go with this patch set, forget I said anything :-)

Fernando, if you have some cycles, would you make a packetpath shell test
for this to exercise the datapath?

Thanks!

Re: [PATCH nf-next] netfilter: nft_meta_bridge: introduce NFT_META_BRI_IIFHWADDR support

[Fernando Fernandez Mancera]

On 9/2/25 6:33 PM, Florian Westphal wrote:
> Pablo Neira Ayuso <pablo@netfilter.org> wrote:
>>>                       +----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..
>>
>> Thanks for confirming.
>>
>> But this is going to be a bit strange from usability point of view?
>>
>> It is easier to explain to users that by setting the br0 mac address
>> (as we do now) packets are passed up to the local stack.
> 
> Fair point.
> So lets just go with this patch set, forget I said anything :-)
> 
> Fernando, if you have some cycles, would you make a packetpath shell test
> for this to exercise the datapath?
> 

Sure, I can do it. I will create a new test on selftests covering this. 
Should I send a v2 series including the new commit or just send an 
independent series with the selftest changes?

Thanks,
Fernando.

> Thanks!
> 

Re: [PATCH nf-next] netfilter: nft_meta_bridge: introduce NFT_META_BRI_IIFHWADDR support

[Florian Westphal]

Fernando Fernandez Mancera <fmancera@suse.de> wrote:
> On 9/2/25 6:33 PM, Florian Westphal wrote:
> > Fernando, if you have some cycles, would you make a packetpath shell test
> > for this to exercise the datapath?
> > 
> Sure, I can do it. I will create a new test on selftests covering this.
> Should I send a v2 series including the new commit or just send an
> independent series with the selftest changes?

You can send the shell-test as standalone item.
No need to resend.