Linux community tunneling through VXLAN or Geneve [closed]

I’m attempting to tunnel from a "digital interface" on Machine A to a bodily interface on Machine B. All concerned programs are Linux-based and have bridge instruments, iproute2 and related kernel choices put in. All networks depicted under are /24. I can not change any community settings on C and D, nor can I set up software program on them.

Machine A is behind a masquerading NAT however can attain Machine B. Machine B can not attain Machine A. Machine B has a second NIC on a subnet along with Machines C, D (and a few others).

What I plan to realize is to have a brand new community interface on Machine A that’s in the identical subnet as Machines C and D so I can ping them. Ideally a layer 2 tunnel.

Most guides I discovered assume some software program outlined switching, VMs or Kubernetes. Nothing is concerned in my case.

First thought was to create a Wireguard tunnel between Machines A and B and to bridge it to eth1 on Machine B. I have not tried that but since I learn that wireguard is layer 3 solely and thus would not assist bridging.

Subsequent I learn on layer 2 tunneling potentialities: GRE, VXLAN and Geneve.

Since all appear to require that Machines A and B can discuss to one another (= in each instructions), I created a Wireguard community between them. That is working and Machine A and B can ping one another on their wireguard IPs (192.168.66.0/24)

Then (on Machine B), I arrange a bridge interface br0, eliminated the IP from eth1, added eth1 to br0 and configured the IP from eth1 on br0. Pinging from B to C and D nonetheless works.

Then I attempted organising a Geneve tunnel between Machines A and B (utilizing the wireguard interfaces for "distant"), including interface geneve0 on Machine B to br0 and giving geneve0 on Machine A an IPv4 in the identical subnet as br0 on B. I don´t keep in mind the precise instructions however I believe Machine A was capable of ping B (within the 192.168.0.0/24 subnet) however not Machines C and D and B was not capable of ping A (surprisingly).

So I attempted to do the identical with VXLAN as an alternative. Instructions used:

Machine A:

ip hyperlink add vxlan0 sort vxlan id 6666 dstport 4789
ip addr add 192.168.0.210/24 dev vxlan0
ip hyperlink arrange vxlan0
bridge fdb add 00:00:00:00:00:00 dev vxlan0 dst 192.168.66.1

Machine B:

ip hyperlink add vxlan0 sort vxlan id 6666 dstport 4789
ip hyperlink arrange vxlan0
bridge fdb add 00:00:00:00:00:00 dev vxlan0 dst 192.168.66.2
brctl addif br0 vxlan0

At this level, Machine B can nonetheless ping C and D. Machine B also can ping Machine A on 192.168.0.210 (which tells me that the VXLAN appears to be working).
Machine A can ping Machine B on 192.168.0.200. Nevertheless, Machine A CAN NOT ping Machines C and D. Machine B has proxy_arp and ipv4.ip_forward enabled.
Utilizing "tcpdump -i vxlan0" on B I can see the ping requests from A to C however no replies. Nevertheless, the ARP requests are forwarded and the ARP desk on A incorporates the entries with the right IPs and MACs. Utilizing "tcpdump -i eth1", I can see that the ping requests from C don’t make it out to C and D.

Someway bridging the vxlan0 to br0 works however packets aren’t forwarded to eth1 regardless that it’s on the identical bridge as nicely however I can not see what I’m lacking. Why does ARP work however ICMP not?
How would Machine A know that the MAC addresses of C and D are behind B and never another machine that may be a part of the identical VXLAN? Do I would like to inform or ought to it auto-learn (like a change that remembers which MAC addresses are on every port)?

Any thought what I may strive subsequent? Or would there be a better strategy to realize what I need? Thanks!