Adam Carter <adamcart...@gmail.com> 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
>> | Ziel            Router          Genmask         Flags Metric Ref    Use
>> Iface
>> | 0.0.0.0         192.168.75.1    0.0.0.0         UG    4005   0        0
>> ppp0
>> | 127.0.0.0       0.0.0.0         255.0.0.0       U     0      0        0
>> lo
>> | 192.168.1.0     0.0.0.0         255.255.255.0   U     0      0        0
>> br_dmz
>> | 192.168.3.0     0.0.0.0         255.255.255.0   U     0      0        0
>> enp1s0
>> | 192.168.3.80    0.0.0.0         255.255.255.255 UH    0      0        0
>> enp1s0
>> | 192.168.3.81    0.0.0.0         255.255.255.255 UH    0      0        0
>> enp1s0
>> | 192.168.75.1    0.0.0.0         255.255.255.255 UH    0      0        0
>> 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.

Reply via email to