Can connect-retry prevent misbehaved client from using up all seats?

hx5s6

I have a misbehaved client which successfully connected to the server but failed a following certificate check. This resulted in an incomplete connection and thus the user was recorded by OpenVPN as a UNDEF user. In this case this client kept trying to re-connect to the server but kept failed due to the same reason, and eventually used up all the client seats, which further affected other legitimate clients (they got disconnected).

My questions are - Is there a way to avoid the above issue via a configuration option? I checked the reference manual and found two options, "connect-retry n" and "connect-timeout", but not sure if these options are the appropriate choices to prevent such a misbehaved client from using up all client seats. If I put these options into the configuration file, are there any side effects on legitimate clients? Are these options for TCP-connection only? Thanks in advance.

TinCanTech

Openvpn does not have a limited number of "seats" ..

https://forums.openvpn.net/viewtopic.php?f=30&t=22603

hx5s6

Thanks for the reply. I should have mentioned that I used the Openvpn parameter “max-clients” to limit the maximum number of simultaneously connected clients. When saying “seats”, I mean the value of this parameter.

TinCanTech

hx5s6 wrote I have a misbehaved client which successfully connected to the server but failed a following certificate check. This resulted in an incomplete connection and thus the user was recorded by OpenVPN as a UNDEF user. In this case this client kept trying to re-connect to the server but kept failed due to the same reason, and eventually used up all the client seats, which further affected other legitimate clients (they got disconnected).

This sounds like it could be a bug but it's probably user error.

TinCanTech wrote https://forums.openvpn.net/viewtopic.php?f=30&t=22603

Without the information requested here we will never know ..

hx5s6

Hi TinCanTech, my concern is not about why that certain client misbehaved that way (failed on certificate check), which I've known the cause. My main concern is about why such a misbehaved client's repeated incomplete connections reached the "max-clients", namely used up all the client "seats" in my words. It's very likely the re-connections from that client were too frequent and thus the OpenVPN garbage collection couldn't reclaim those "seats" occupied by the UNDEF user from the misbehaved client in time. So I was thinking there might be a way to slow down the repeated re-connection to prevent the "max-clients" from reaching?

TinCanTech

Maybe your server violated 3rd party TCP connection limits ?

TinCanTech

:mrgreen: @Pippin @Titex @300000

chime in :roll:

hx5s6

I don’t think my server violated 3rd party TCP connection limits. I set the “max-clients” value to be a certain number to limit the max number of simultaneously connected clients. Before that misbehaved client started to connect, there were some clients (far from the “max-clients” limit) connecting to the server and running very well already. But after the misbehaved client started to connect to the server, as I described earlier, it connected successfully but failed a following license check immediately, on the server side an UNDEF user was notified by the OpenVPN, that misbehaved client immediately retried to connect to the server and repeated the process, till the number of UNDEF users reached the “max-clients” and also led other legitimate clients disconnected. If removing that misbehaved client, then everything came back to normal.

So I’m not worry about how to fix the exact misbehavior of that client. I more wonder if there’s any solution from OpenVPN that can respond such a misbehavior and protect other legitimate clients.

Pippin

TinCanTech wrote ...
https://forums.openvpn.net/viewtopic.php?f=30&t=22603

There is a good reason to read the above and post the necessary information.

TinCanTech

hx5s6 wrote it connected successfully but failed a following license check immediately

Openvpn does not have licenses either ..