Rich Freeman <[email protected]> writes: > On Fri, Dec 25, 2015 at 9:00 PM, Adam Carter <[email protected]> wrote: >>> grandstream.yagibdah.de (192.168.3.80) auf 00:0b:82:16:ed:9e [ether] auf >>> enp2s0 >>> grandstream.yagibdah.de (192.168.3.80) auf 00:0b:82:16:ed:9e [ether] auf >>> enp1s0 >>> spa.yagibdah.de (192.168.3.81) auf 88:75:56:07:44:c8 [ether] auf enp2s0 >>> spa.yagibdah.de (192.168.3.81) auf 88:75:56:07:44:c8 [ether] auf enp1s0 >>> >>> >>> enp2s0 is an interface dedicated to a PPPoE connection, and enp1s0 >>> connects to the LAN. >>> >>> IIUC, this is bound to cause problems. >>> >>> How is it possible for the wrong entries to be created, and what can I >>> do to prevent them? >>> >> >> arp mappings are untrusted so your machine will accept anything is sees on >> the network. That's what makes MITM so easy on a connected subnet. What >> makes you think they are wrong? Also, the output of ifconfig would be >> helpful. > > I suspect those interfaces are getting bridged or something, but I'm > not an expert on such things.
No physical interface is connected to the bridge interface, though selected traffic from the devices can reach one of the VMs that are connected to the bridge. > If a given IP has a MAC on more than one interface, the interface the > packets go out to is still controlled by the routing rules. If the > routing rule says that 1.1.1.1 is on eth0 it doesn't matter that eth0 > doesn't have an ARP entry and eth1 does - I believe it will just be > undelivered or sent to the gateway for eth0 if it isn't on a local > subnet for that interface. There are no arp entries created for interfaces of the host. No traffic from the devices can make it to enp2s0. > If you have some kind of routing loop it could actually make its way > back to the interface on eth1. The traffic would have to be routed back via enp2s0 from somewhere. Since traffic from the devices doesn't go over enp2s0, it cannot be routed back there. > ARP doesn't come into play until the kernel goes to send something on > an interface and determines it is on a subnet for that interface. The devices are not on a subnet of the interface, hence no arp entries for them should be created for that interface. > Again, I'm not an expert in this and there could be some nuance to the > rules that I'm missing. Me neither ... The devices are functional, though I can't tell if traffic from or to them can be misdirected because of the arp entries that shouldn't exist. The devices might still work if some of their traffic is misdirected, just not as well as they otherwise could. Since they are VOIP devices, they are required to work well --- and the VOIP quality is actually not good enough. So I'm looking for possible causes, and wrong arp entries might be one.
