<div dir="ltr">Did you look into Proxy ARP as a solution?</div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Sat, Apr 1, 2023 at 2:13 PM Gabriel L. Somlo <<a href="mailto:gsomlo@gmail.com">gsomlo@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Sean, Stephen,<br>
<br>
Since I asked, and you tried to help me, I figured I'd link you to the<br>
solution I came up with so far (because no matter how much I try to<br>
turn off learning on a linux bridge, the mac addresses of a physical<br>
interface that acts as one of its ports will still always be in the<br>
bridge FDB, and will prevent frames with that address as a destination<br>
from actually being forwarded *through* the bridge (after all, one of<br>
its local ports *has* that mac address, so the bridge *just knows*<br>
that frame doesn't need to leave :)<br>
<br>
I asked on the netfilter list as well, got told to go set up a layer-2<br>
VPN there as well, so I came up with a *double* NAT scheme that<br>
actually works:<br>
<br>
<a href="https://marc.info/?l=netfilter&m=168037556509521&w=2" rel="noreferrer" target="_blank">https://marc.info/?l=netfilter&m=168037556509521&w=2</a><br>
<br>
TLDR; it's two bridges in series, each of them NAT-ing the "shared"<br>
mac address to something else while traveling over the veth pair<br>
connecting the two bridges... :)<br>
<br>
I feel I shouldn't have to do this, as there ought to be a way to tell<br>
a linux bridge to stop thinking and just act like a dumb hub in cases<br>
where the admin knows what they're doing :) But at least I don't have<br>
to butcher the kernel-level bridge code to get what I want :)<br>
<br>
Thanks again for all your help brainstorming,<br>
--Gabriel<br>
</blockquote></div>