Ethernet-layer NAT (userspace queueing for ebtables)?

Sean Reifschneider jafo00 at gmail.com
Sun Apr 2 13:26:04 UTC 2023


Did you look into Proxy ARP as a solution?

On Sat, Apr 1, 2023 at 2:13 PM Gabriel L. Somlo <gsomlo at gmail.com> wrote:

> Sean, Stephen,
>
> Since I asked, and you tried to help me, I figured I'd link you to the
> solution I came up with so far (because no matter how much I try to
> turn off learning on a linux bridge, the mac addresses of a physical
> interface that acts as one of its ports will still always be in the
> bridge FDB, and will prevent frames with that address as a destination
> from actually being forwarded *through* the bridge (after all, one of
> its local ports *has* that mac address, so the bridge *just knows*
> that frame doesn't need to leave :)
>
> I asked on the netfilter list as well, got told to go set up a layer-2
> VPN there as well, so I came up with a *double* NAT scheme that
> actually works:
>
> https://marc.info/?l=netfilter&m=168037556509521&w=2
>
> TLDR; it's two bridges in series, each of them NAT-ing the "shared"
> mac address to something else while traveling over the veth pair
> connecting the two bridges... :)
>
> I feel I shouldn't have to do this, as there ought to be a way to tell
> a linux bridge to stop thinking and just act like a dumb hub in cases
> where the admin knows what they're doing :) But at least I don't have
> to butcher the kernel-level bridge code to get what I want :)
>
> Thanks again for all your help brainstorming,
> --Gabriel
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.nclug.org/pipermail/nclug/attachments/20230402/1c37b643/attachment.htm>


More information about the NCLUG mailing list