Ethernet-layer NAT (userspace queueing for ebtables)?

[Gabriel Somlo]

On Sun, Apr 02, 2023 at 07:26:04AM -0600, Sean Reifschneider wrote:
> Did you look into Proxy ARP as a solution?

Yeah. If my container's mac address is *not* a clone of the
outside-facing host-VM interface mac, then having it offer its own mac
address as response for arp requests won't help.

If it *does* clone the publicly-visible mac, then the (outer) bridge
will drop inbound traffic from the outside targeted at that mac
(because of the permanent fdb entry).

I don't think proxy arp can be configured to offer up someone *else's*
mac address in reply to a "who-has" broadcast request. If I'm wrong
about that one, there might be something worth following up here :)

Thanks again,
--Gabriel
 
> 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
>