I configured three machines in a static proxy_arp like manner:
----------------------+ +-----------------------------------------------+ +---------------------- Machine A | | Machine B | | Machine C ----------------------+ +-----------------------------------------------+ +---------------------- eth0|---|tap0 tap1|---|eth0 mac: 52:54:00:12:34:56| |mac: b6:e0:11:97:fd:5f mac: 36:46:74:b1:92:71| |mac: 52:54:00:22:22:22 ip: 192.168.12.2/24| |ip: 0.0.0.0 ip: 0.0.0.0| |ip: 192.168.12.4/24 | |promisc up promisc up| | Machine A: arp -i eth0 -s 192.168.12.4 b6:e0:11:97:fd:5f Machine C: arp -i eth0 -s 192.168.12.2 36:46:74:b1:92:71 Machine B: echo 1 > /proc/sys/net/ipv4/ip_forward route add 192.168.12.4 dev tap1 route add 192.168.12.2 dev tap0
With this configuration, I can ping 192.168.12.4 successfully from machine A.
The question is, if I replace the static arp route on machine C with:
arp -i eth0 -s 192.168.12.2 22:22:22:22:22:22
Why does it stop working?
the ping reply is received by tap1 on machine B (appears on wireshark), but for some reason, although tap1 is is promiscuous mode, the packet is not transmitted to the IP layer, and not forwarded to tap0 as it should!
Do you know which component of the kernel is responsible for dropping such incoming packet based on the destination mac address, even when the interface is in promiscuous mode?
Best Answer
The networking layer receives the packet for MAC 22:22:22:22:22, but since the MAC address does not belong to tap1, the packet is ignored. Setting the interface to promiscuous does not disable that check, it only moves it to later in the network code.
Forwarding packets that have a MAC destination that is not that of the interface the packet is received on is called bridging. If you bridge packets over machine B, you would be able to configure machines A and C normally without static ARP routes, and it seems that is what you want to do.