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.
_______________________________________________
Openvpn-users mailing list
Openvpn-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openvpn-users
