Hello Gert,
I was thinking on the same.
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.
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
On Client1 where tap1 traffic comes in I have tried:
ebtables -A OUTPUT -o tap0+ --pkttype-type multicast -j DROP
ebtables -A FORWARD -o tap0+ --pkttype-type multicast -j DROP
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.
Besides this I think that the layer2 bridge mode is one of the best
features of OpenVPN and would be a shame to remove it. It's a pain in
the ass to do these setups with old Strongswan/OpenSWAN IPSEC. I still
use IPX/SPX and novell but that is not the main reason why I like layer2
setups, it is because if it's needed you can easily point any machine on
the network, regardless which segment are you on to use a gateway on the
other as a default route.
If you would have a normal routing setup for example 10.3.0.5 --
10.3.0.x -- 10.3.0.1 GW 1 --VPN-- 10.4.0.1 GW2
How would you define GW2 as default gateway just for 1 machine
(10.3.0.5) on network 1, without installing any vpn client and
establishing a connection between .5 and gw2 directly?! It is
impossible. The only workaround maybe some iproute 2 rules on GW1 to
divert the traffic what it gets from that machine and send it through
GW2.
On 2018-06-27 20:01, Gert Doering wrote:
Hi,
On Wed, Jun 27, 2018 at 09:30:51AM +0200, free...@tango.lu wrote:
There is this issue bugging me since a long time and try to put a stop
to it:
[22444423.820856] br0: received packet on tap0 with own address as
source address
I assume these are multicast packets, and I have the nagging suspicion
that the combination
<--openvpn/tap--> client <-bridge-> LAN
will reflect multicast packets coming in from the "server->client" back
to the server. This is hard to say for sure since tcpdump on the tap0
interface on the client does not always seem to be telling the full
truth
for multicast things...
(We have a trac ticket open on a similar case which leads to the
openvpn *server* starting to misbehave - if my theory is true, but
still waiting for logs to say for sure)
It should be noted that br0 is not complaing about "source *IP*
address"
but about "source *MAC* address". So whatever you change in the IP
config
won't be interesting to br0.
I guess if you do a tcpdump on the server's tap0 (that's logging the
error) for "tcpdump -n -s0 -e -i tap0 'ether src x:x:x:x:x:x and
multicast'",
replacing the "x:x:x:x:x:x" with the ethernet address being shown in
"ifconfig br0", it might lead to interesting discoveries.
(And @dazo: there's a reason why we have tap mode *and* why linux
briding
exists - sometimes there is no other way to do things. There is at
least one known bug in our server-side mac-learning code, though, but
this one is different)
gert
------------------------------------------------------------------------------
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
