Re: [gentoo-user] arp question

[lee]

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

[lee]

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

[Rich Freeman]

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

[lee]

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

[Adam Carter]

> 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

[lee]

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

[lee]

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 

Re: [gentoo-user] arp question

[Adam Carter]

>
> 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.

Re: [gentoo-user] arp question

[Adam Carter]

> 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]

> 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

[Rich Freeman]

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