Hi, On Fri, Mar 08, 2019 at 08:40:22AM +0100, free...@tango.lu wrote: > As it was stated by the DEVs that the bridged networking will be removed > from OpenVPN in the future
Uh, what? That is news to me :-) (OpenVPN *3* is a new code base that does not have TAP support and is not likely to grow such, but OpenVPN *2* will keep its TAP support - and will not be replaced by 3.x any time soon, as the focus is different) [..] > 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. If you get "kernel: .." messages, it's the kernel, not OpenVPN :-) > 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. "overflow" = "ARP traffic that exceeds certain thresholds is dropped", so this is exactly what you see: spurious unreachability. Totally outside OpenVPN. (Now, the bridge code inside OpenVPN has a number of interesting warts wrt MAC learning on the tap interface of a p2mp server, flooding of unknown-unicast traffic, etc. - but that's all something people usually will not notice unless testing with very particular packets) 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
_______________________________________________ Openvpn-users mailing list Openvpn-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/openvpn-users