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

Attachment: signature.asc
Description: PGP signature

_______________________________________________
Openvpn-users mailing list
Openvpn-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openvpn-users

Reply via email to