Re: [gentoo-user] arp question
Adam Carter writes: >> Yes, I already tried that and didn't get any traffic listed. >> > > In that case it sounds like linux has bridged them across from the other > interface. Does this find anything? > tcpdump -i enp2s0 net 192.168.1.0/24 > > If it doesn't maybe generate some layer2 broadcast traffic on enp1s0 to see > if you can see that traffic in the tcpdump on enp2s0. Something like; > echo 0 > /proc/sys/net/ipv4/icmp_echo_ignore_broadcasts > ping 192.168.1.255 > > After the test is done turn it back on with; > echo 1 > /proc/sys/net/ipv4/icmp_echo_ignore_broadcasts Thanks! I tried it, and nothing shows up. > I've never bridged with linux. Bridging is usually a bad option - if you > can I suggest you move to a routed and/or NATed solution. Clean and simple > is best. Most ppl seem to recommend bridging as the clean and simple solution. How come you say that bridging is usually bad? And how do you start a container without having a bridge on the host? Not being able to do that is why I have the bridge in the first place.
Re: [gentoo-user] arp question
Rich Freeman writes: > On Sat, Dec 26, 2015 at 9:14 AM, lee wrote: >> >> They are connected to different vlans on the same switch, so they don't >> share the same broadcast domain. The switch shows the mac addresses of >> the phones only in the expected vlan. >> > > Out of curiosity, have you tried actually sending a broadcast on the > VLAN to verify that it actually is implemented correctly? If your > switch is mixing ARP across VLANs that would explain this behavior. Not yet --- and it won't exactly be an easy thing to do. It's a high-quality switch. If it couldn't keep vlans seperated, the customers it was designed for would have them pretty much all replaced under warranty. > I've never messed with VLAN on linux but I'd think that you could Me neither; so far, the switch does it. > probably implement VLAN in software and actually save yourself a > physical network interface as well (both interfaces could go out over > the same wire and be handled appropriately by the switch). Hm. That might even be possible, in a very complicated setup. Maybe some day, I can do that, after lots of learning.
Re: [gentoo-user] arp question
> Yes, I already tried that and didn't get any traffic listed. > In that case it sounds like linux has bridged them across from the other interface. Does this find anything? tcpdump -i enp2s0 net 192.168.1.0/24 If it doesn't maybe generate some layer2 broadcast traffic on enp1s0 to see if you can see that traffic in the tcpdump on enp2s0. Something like; echo 0 > /proc/sys/net/ipv4/icmp_echo_ignore_broadcasts ping 192.168.1.255 After the test is done turn it back on with; echo 1 > /proc/sys/net/ipv4/icmp_echo_ignore_broadcasts I've never bridged with linux. Bridging is usually a bad option - if you can I suggest you move to a routed and/or NATed solution. Clean and simple is best.
Re: [gentoo-user] arp question
On Sat, Dec 26, 2015 at 9:14 AM, lee wrote: > > They are connected to different vlans on the same switch, so they don't > share the same broadcast domain. The switch shows the mac addresses of > the phones only in the expected vlan. > Out of curiosity, have you tried actually sending a broadcast on the VLAN to verify that it actually is implemented correctly? If your switch is mixing ARP across VLANs that would explain this behavior. I've never messed with VLAN on linux but I'd think that you could probably implement VLAN in software and actually save yourself a physical network interface as well (both interfaces could go out over the same wire and be handled appropriately by the switch). -- Rich
Re: [gentoo-user] arp question
Adam Carter writes: >> They are wrong because there is no way for network traffic from the >> devices on the LAN to make it to the interface enp2s0. Or, if they do >> make it there, then there is something else seriously wrong. >> > > tcpdump -i enp2s0 arp > > will tell you if the arps are being generated from something on the wire > side. If there's not much traffic then clear the arp entry and ping the IP > address to generate traffic. Yes, I already tried that and didn't get any traffic listed. > | heimdali ~ # route -n >> | Kernel IP Routentabelle >> | ZielRouter Genmask Flags Metric RefUse >> Iface >> | 0.0.0.0 192.168.75.10.0.0.0 UG4005 00 >> ppp0 >> | 127.0.0.0 0.0.0.0 255.0.0.0 U 0 00 >> lo >> | 192.168.1.0 0.0.0.0 255.255.255.0 U 0 00 >> br_dmz >> | 192.168.3.0 0.0.0.0 255.255.255.0 U 0 00 >> enp1s0 >> | 192.168.3.800.0.0.0 255.255.255.255 UH0 00 >> enp1s0 >> | 192.168.3.810.0.0.0 255.255.255.255 UH0 00 >> enp1s0 >> | 192.168.75.10.0.0.0 255.255.255.255 UH0 00 >> ppp0 >> | heimdali ~ # >> ` >> >> What it the purpose of the static host routes? The connected > 192.168.3.0/24 route will take care of those hosts, so they shouldn't be > required. They shouldn't be needed. I added them manually only to see if it would make a difference. > What are enp1s0 and enp2s0 connected to? Same hub or same vlan on the > switch? If so they will both see all the layer 2 broadcast traffic from > each subnet. They are connected to different vlans on the same switch, so they don't share the same broadcast domain. The switch shows the mac addresses of the phones only in the expected vlan. Even when enp2s0 is not connected to the switch but directly to the wire the PPPoE connection comes from, the arp entries are updated. Having that said, there's one more test I can make: disconnect enp2s0 entirely and see if the arp entries still persist. As to the other reply: The firewall is IP based, and what reason and what way would any traffic have to go from a device on the LAN to an interface that is not connected to the LAN but to the internet, and on a different network than the LAN, when all IP traffic from the device to the internet is being dropped? The firewall doesn't know enp2s0 but ppp0. But still, I don't see how these arp entries could appear on enp2s0, yet they do. On a side note: I've verified that VOIP quality issues do not come from anything on the LAN (by playing music to the phones and making internal phone calls) but from the rather poor internet connection. So at least the wrong arp entries don't interfere with VOIP.
Re: [gentoo-user] arp question
> They are wrong because there is no way for network traffic from the > devices on the LAN to make it to the interface enp2s0. Or, if they do > make it there, then there is something else seriously wrong. > tcpdump -i enp2s0 arp will tell you if the arps are being generated from something on the wire side. If there's not much traffic then clear the arp entry and ping the IP address to generate traffic. | heimdali ~ # route -n > | Kernel IP Routentabelle > | ZielRouter Genmask Flags Metric RefUse > Iface > | 0.0.0.0 192.168.75.10.0.0.0 UG4005 00 > ppp0 > | 127.0.0.0 0.0.0.0 255.0.0.0 U 0 00 > lo > | 192.168.1.0 0.0.0.0 255.255.255.0 U 0 00 > br_dmz > | 192.168.3.0 0.0.0.0 255.255.255.0 U 0 00 > enp1s0 > | 192.168.3.800.0.0.0 255.255.255.255 UH0 00 > enp1s0 > | 192.168.3.810.0.0.0 255.255.255.255 UH0 00 > enp1s0 > | 192.168.75.10.0.0.0 255.255.255.255 UH0 00 > ppp0 > | heimdali ~ # > ` > > What it the purpose of the static host routes? The connected 192.168.3.0/24 route will take care of those hosts, so they shouldn't be required. What are enp1s0 and enp2s0 connected to? Same hub or same vlan on the switch? If so they will both see all the layer 2 broadcast traffic from each subnet.
Re: [gentoo-user] arp question
> Even after adding the static routes and creating firewall rules to drop > all traffic from the devices to the internet, their arp entries continue > to be renewed. How is that possible? > > Your iptables rules are IP based (layer 3), so will not match arp traffic (layer 2)
Re: [gentoo-user] arp question
Adam Carter writes: >> >> 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? They are wrong because there is no way for network traffic from the devices on the LAN to make it to the interface enp2s0. Or, if they do make it there, then there is something else seriously wrong. > Also, the output of ifconfig would be helpful. , | heimdali ~ # ifconfig -a | br_dmz: flags=4419 mtu 1500 | inet 192.168.1.1 netmask 255.255.255.0 broadcast 192.168.1.255 | inet6 fe80::5cce:2bff:fedc:dce0 prefixlen 64 scopeid 0x20 | ether fe:18:b0:e9:78:47 txqueuelen 0 (Ethernet) | RX packets 5124752 bytes 3554838408 (3.3 GiB) | RX errors 0 dropped 0 overruns 0 frame 0 | TX packets 5080086 bytes 3508269156 (3.2 GiB) | TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0 | | enp1s0: flags=4163 mtu 1500 | inet 192.168.3.20 netmask 255.255.255.0 broadcast 192.168.3.255 | inet6 fe80::7aac:c0ff:fe3c:2dc8 prefixlen 64 scopeid 0x20 | ether 78:ac:c0:3c:2d:c8 txqueuelen 1000 (Ethernet) | RX packets 998350 bytes 217325937 (207.2 MiB) | RX errors 0 dropped 7332 overruns 0 frame 0 | TX packets 965281 bytes 274572349 (261.8 MiB) | TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0 | device interrupt 17 | | enp2s0: flags=4163 mtu 1500 | inet 185.55.75.245 netmask 255.255.255.255 broadcast 185.55.75.245 | inet6 fe80::7aac:c0ff:fe3c:2dc9 prefixlen 64 scopeid 0x20 | ether 78:ac:c0:3c:2d:c9 txqueuelen 1000 (Ethernet) | RX packets 5157535 bytes 4875664995 (4.5 GiB) | RX errors 0 dropped 0 overruns 0 frame 0 | TX packets 3377329 bytes 413568759 (394.4 MiB) | TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0 | device interrupt 16 | | lo: flags=73 mtu 65536 | inet 127.0.0.1 netmask 255.0.0.0 | inet6 ::1 prefixlen 128 scopeid 0x10 | loop txqueuelen 0 (Lokale Schleife) | RX packets 276299 bytes 78159006 (74.5 MiB) | RX errors 0 dropped 0 overruns 0 frame 0 | TX packets 276299 bytes 78159006 (74.5 MiB) | TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0 | | ppp0: flags=4305 mtu 1492 | inet 185.55.75.245 netmask 255.255.255.255 destination 192.168.75.1 | ppp txqueuelen 3 (Punkt-zu-Punkt Verbindung) | RX packets 7250 bytes 3180943 (3.0 MiB) | RX errors 0 dropped 0 overruns 0 frame 0 | TX packets 6123 bytes 711342 (694.6 KiB) | TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0 | | veth5CBR3D: flags=4163 mtu 1500 | inet6 fe80::fc18:b0ff:fee9:7847 prefixlen 64 scopeid 0x20 | ether fe:18:b0:e9:78:47 txqueuelen 1000 (Ethernet) | RX packets 5077428 bytes 3616056439 (3.3 GiB) | RX errors 0 dropped 0 overruns 0 frame 0 | TX packets 5031817 bytes 3495334672 (3.2 GiB) | TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0 | | vethYXJVKH: flags=4163 mtu 1500 | inet6 fe80::fcd0:65ff:fec5:7b44 prefixlen 64 scopeid 0x20 | ether fe:d0:65:c5:7b:44 txqueuelen 1000 (Ethernet) | RX packets 47324 bytes 10528497 (10.0 MiB) | RX errors 0 dropped 0 overruns 0 frame 0 | TX packets 48502 bytes 13062823 (12.4 MiB) | TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0 | | heimdali ~ # brctl show | bridge name bridge id STP enabled interfaces | br_dmz 8000.fe18b0e97847 no veth5CBR3D | vethYXJVKH | heimdali ~ # route -n | Kernel IP Routentabelle | ZielRouter Genmask Flags Metric RefUse Iface | 0.0.0.0 192.168.75.10.0.0.0 UG4005 00 ppp0 | 127.0.0.0 0.0.0.0 255.0.0.0 U 0 00 lo | 192.168.1.0 0.0.0.0 255.255.255.0 U 0 00 br_dmz | 192.168.3.0 0.0.0.0 255.255.255.0 U 0 00 enp1s0 | 192.168.3.800.0.0.0 255.255.255.255 UH0 00 enp1s0 | 192.168.3.810.0.0.0 255.255.255.255 UH
Re: [gentoo-user] arp question
Rich Freeman writes: > On Fri, Dec 25, 2015 at 9:00 PM, Adam Carter 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.
Re: [gentoo-user] arp question
On Fri, Dec 25, 2015 at 9:00 PM, Adam Carter 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. 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. If you have some kind of routing loop it could actually make its way back to the interface on eth1. 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. Again, I'm not an expert in this and there could be some nuance to the rules that I'm missing. -- Rich
Re: [gentoo-user] arp question
> > 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.
[gentoo-user] arp question
Hi, any idea why I have entries in the arp table like this: 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?
