[Openvpn-users] Removal of the TAP Bridge, Strange ARP issue and looking for solutions for an alternative Layer2 VPN

[<fr...@ta...>]

Hello,

As it was stated by the DEVs that the bridged networking will be removed 
from OpenVPN in the future I think that will leave a lot of us who were 
using this with looking for cheap OpenSource alternatives because sooner 
or later if a software becomes out of date with security vulnerabilities 
ppl are forced to switch even if it's perfectly working like a ZX80 
calculator. Let's not go into why do DEVs think that layer2 bridges are 
bad just discuss (maybe better) currently available OpenSource 
alternatives.

One alternative is IPSEC TRANSPORT MODE but it becomes a hassle when one 
or more ends are behind NAT routers (which is the case almost always 
nowadays) and as far as I understood it does not provide superior 
security over OpenVPN.


EoIP this seems to be a Mikrotik proprietary protocol.

https://wiki.mikrotik.com/wiki/Manual:Interface/EoIP

I will skip on the *Cisco* solutions since they are all proprietary, 
commercial.




For ending I will discuss an interesting behavior with a bridging setup 
of OpenVPN 2.4.6 x86_64-pc-linux-gnu [SSL (OpenSSL)] [LZO] [LZ4] [EPOLL] 
[MH/PKTINFO] [AEAD] built on Jul  9 2018.


I twas like a 3 location VPN bridge kept up by same openvpn versions. On 
one location a network with bogous ARP traffic was plugged into the 
network causing it to send non related ARP flow of about 100-200K/s also 
generating 300MB firewall logs per day on the devices  LEN=94 TOS=0x08 
PREC=0x80 TTL=61 ID=16892 DF PROTO=UDP SPT=43849 DPT=161 LEN=74. Anyway 
the most of the traffic was not IP but just pure ARP hitting the 
Broadcast address who has address 172.30.52.31 ETC. Not even related to 
the IP ranges used on the VPN.

Now we talking about 100mbit/s WAN links so a 100-200K/s UDP flow is 
peanuts regardless this traffic caused OpenVPN (or the Linux kernel?) to 
start to go nuts.

According to this:

http://yurisk.info/2009/12/15/arp-table-overflow-in-checkpoint-nad-linux-in-general/index.html

I would get: "kernel: Neighbour table overflow." this was not the case, 
there was no overflow here however machines on the different segments 
failed to resolve hardware addresses of machines on other segments and 
even adding them manually as static ARP entries on those nodes didn't 
work. Killing and restarting OpenVPN on the nodes partially worked for a 
while.

After the bad traffic was shutdown and all the routers (or in this case 
better call them BRIDGES) running OpenVPN were rebooted everything went 
back to normal.