lwiscovitch We're just about done switching our existing OpenVPN deployment from TAP to TUN, been a "fun" migration but I think we're finally good to go. When discussing this with the sysadmin he asked me to test out a situation he had run into before: * Establish a VPN session and perform an endless ping against a server over the VPN * Edit our client-connect script and add in a "sleep 60" entry * Establish a second VPN session His expectation was that while the second VPN session is being established (Adding the "sleep 60" makes it take at least 60 seconds) that the first VPN session's ping would stop...I thought that was ludicrous and fully expected to prove him wrong. But he was right...As soon as the second VPN session was established and the client-connect script hit the "sleep 60" the ping stopped on the first one...And then as soon as it was finished it resumed pinging. We also use a auth script and I did the same test and saw the same results. Is this by design? Any way to disable/address this? The reason the sysadmin knew about it was that previously we had an issue where our FreeIPA servers were fubar and the authentication process (Using PAM at the time) was never finishing or erroring out. So when a client tried to connect it would just wait...and wait...and wait. However all existing connections then went silent because of this. Would like to avoid this if possible.
lwiscovitch I guess it could be exploited like that...Again, in our case we saw this in production when our FreeIPA servers were fubar...So wasn't intentional/deliberate, but did happen.
Traffic Traffic wroteSounds like a deliberate DOS style attacklwiscovitch wroteEdit our client-connect script and add in a "sleep 60" entrylwiscovitch wroteSo wasn't intentional/deliberateSure looks deliberate to me .. :geek:
lwiscovitch Oh you mean that...Yeah, it was a deliberate way to test/confirm the situation. I don't see why that is an issue in this case...The fact that I put a sleep in there to see if the existing connections stall while a new connection is being setup is not the issue...The issue is that when a new connection is being setup existing connections stall. Or am I not explaining that correctly? Again, we ran into this previously through no fault of our own...I'm just trying to show what we're seeing and provide a logical way to duplicate it.
Traffic I believe this is in part due to openvpn being single thread process. If you stall the connection process then you stall the server. What you are seeing is known about and it is not considered to be a bug .. it is a limitation of openvpn. You could ask the devs on their mailing list, if you prefer.
Pippin Traffic wroteI believe I believe too because i remember i read it somewhere, probably mailing list.
