Hi, On Thu, Jun 28, 2018 at 04:43:13PM +0200, free...@tango.lu wrote: > Here is some traffic dump (on tap0) run on the Server where 192.168.5.4 > is the address of the Server on br0: > > 10:14:43.593256 1e:6f:f0:1a:74:2f > 01:00:5e:00:00:01, ethertype IPv4 > (0x0800), length 46: 0.0.0.0 > 224.0.0.1: igmp query v2 > 10:15:01.674472 1e:6f:f0:1a:74:2f > ff:ff:ff:ff:ff:ff, ethertype ARP > (0x0806), length 42: Request who-has 192.168.5.23 tell 192.168.5.4, > length 28 > 10:15:16.282724 1e:6f:f0:1a:74:2f > ff:ff:ff:ff:ff:ff, ethertype ARP > (0x0806), length 42: Request who-has 192.168.5.56 tell 192.168.5.4, > length 28 > 10:16:49.033270 1e:6f:f0:1a:74:2f > 01:00:5e:00:00:01, ethertype IPv4 > (0x0800), length 46: 0.0.0.0 > 224.0.0.1: igmp query v2 > 10:17:53.572669 1e:6f:f0:1a:74:2f > ff:ff:ff:ff:ff:ff, ethertype ARP > (0x0806), length 42: Request who-has 192.168.5.77 tell 192.168.5.4, > length 28 > > Well this seems normal to me, when the server want to know some IPs it > broadcasts to ff:ff:ff:ff:ff:ff and this gets forwarded to all 3 > networks but you suggest that I should never see this traffic coming in > on TAP0 but only on BR0.
Indeed. It should be "sent out" on br0, and then be bridged *out* tap0
and tap1, but never come *in* on tap0/tap1.
The problem with generic tcpdump is that you can't see if it went
br0->tap0 or tap0->br0 when sniffing "on tap0". So my advice was not
overly useful... (except to confirm "there is multicast activity").
Do the timestamps of the 224.0.0.1 packets correlate to your log
entries about the machine's own (MAC) address coming in on br0?
> About the multicast I can block it but will not solve the issue, I have
> tried on the Server:
>
> iptables -I OUTPUT -o tap0+ -m pkttype --pkt-type multicast -j DROP
>
> ebtables -A OUTPUT -o tap0+ --pkttype-type multicast -j DROP
>
> ebtables -A FORWARD -o tap0+ --pkttype-type multicast -j DROP
> ebtables -A FORWARD -i tap0+ --pkttype-type multicast -j DROP
That does the "+" signify at "tap0+"? I've only ever used exact
interface names in filtering.
Can iptables/ebtables filter on bridge member interfaces? (Aka: if you
set up the filter on the server side, will it stop the 224.0.0.1 traffic
from reaching the clients?)
[..]
> No effects. Of course I cannot block the broadcast otherwise on the
> subnets the machines then won't be able to resolve the hwaddresses of
> the other segments.
Of course. I do not think the broadcast packets are to blame here
(because everyone handles these quite reasonably) but multicast.
No IPv6 multicast on your network?
gert
--
"If was one thing all people took for granted, was conviction that if you
feed honest figures into a computer, honest figures come out. Never doubted
it myself till I met a computer with a sense of humor."
Robert A. Heinlein, The Moon is a Harsh Mistress
Gert Doering - Munich, Germany g...@greenie.muc.de
signature.asc
Description: PGP signature
------------------------------------------------------------------------------ Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________ Openvpn-users mailing list Openvpn-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/openvpn-users
