Limit connection resets on SIGUSR1[soft,no-push-reply]

[alclark]

We are running OpenVPN with MFA enabled via Okta and have had a few cases of users getting locked out of Okta due to the push notifications retrying indefinitely until locking their account. Given Okta hardcodes the max retry to 5 and starting the client service doesn't actively prompt you to accept a push notification, it's quite easy to forget they're enabled, miss that the VPN hasn't connected and get locked out after 5 minutes of retries. We're looking for a way to limit the retries after a SIGUSR1[soft,no-push-reply].

The --connect-retry-max seemed promising as the --connect-retry setting was used for the restart pause after the no-push-reply but it turns out the connection is established prior to the PUSH_REQUEST so this isn't seen as a connection-retry against that limit (https://community.openvpn.net/openvpn/ticket/1287).

Does anyone know of any other settings that might be able to limit the retries after this missing push notification? We've done our best to reduce the cases where users might not realise they have a push notification to accept but there's still cases of it.

[TinCanTech]

Given Okta hardcodes the max retry to 5

Given what I know about Okta, I believe your issue lies with them.

OpenVPN provides a VPN not a do anything for free solution..

To be honest I cannot understand what this has to do with openvpn at all.

[alclark]

This issue we have is that our Identity provider (Okta) has a hard retry limit for push notifications and the OpenVPN client will retry those push notifications indefinitely with no way that I can find to disable or limit the retry. As discussed in the support ticket, the --connect-retry-max behaviour is exactly what is wanted (to say if the user hasn't acknowledged after x attempts then stop) but doesn't apply to this case as the connection has already been established.

So where we currently get the following, where if no push reply is found, the client process restarts and tries again:

Code: Select all

Jun 08 16:59:12 openvpn[29543]: [{vpn-host}] Peer Connection Initiated with [AF_INET]{vpn-ip}:1194
Jun 08 16:59:13 openvpn[29543]: SENT CONTROL [{vpn-host}]: 'PUSH_REQUEST' (status=1)
Jun 08 16:59:18 openvpn[29543]: SENT CONTROL [{vpn-host}]: 'PUSH_REQUEST' (status=1)
Jun 08 16:59:24 openvpn[29543]: SENT CONTROL [{vpn-host}]: 'PUSH_REQUEST' (status=1)
Jun 08 16:59:29 openvpn[29543]: SENT CONTROL [{vpn-host}]: 'PUSH_REQUEST' (status=1)
Jun 08 16:59:34 openvpn[29543]: SENT CONTROL [{vpn-host}]: 'PUSH_REQUEST' (status=1)
Jun 08 16:59:39 openvpn[29543]: SENT CONTROL [{vpn-host}]: 'PUSH_REQUEST' (status=1)
Jun 08 16:59:44 openvpn[29543]: SENT CONTROL [{vpn-host}]: 'PUSH_REQUEST' (status=1)
Jun 08 16:59:50 openvpn[29543]: SENT CONTROL [{vpn-host}]: 'PUSH_REQUEST' (status=1)
Jun 08 16:59:55 openvpn[29543]: SENT CONTROL [{vpn-host}]: 'PUSH_REQUEST' (status=1)
Jun 08 17:00:00 openvpn[29543]: SENT CONTROL [{vpn-host}]: 'PUSH_REQUEST' (status=1)
Jun 08 17:00:05 openvpn[29543]: SENT CONTROL [{vpn-host}]: 'PUSH_REQUEST' (status=1)
Jun 08 17:00:10 openvpn[29543]: SENT CONTROL [{vpn-host}]: 'PUSH_REQUEST' (status=1)
Jun 08 17:00:16 openvpn[29543]: No reply from server after sending 12 push requests
Jun 08 17:00:16 openvpn[29543]: SIGUSR1[soft,no-push-reply] received, process restarting
Jun 08 17:00:16 openvpn[29543]: Restart pause, 5 second(s)
Jun 08 17:00:21 openvpn[29543]: NOTE: the current --script-security setting may allow this configuration to call user-defined scripts
Jun 08 17:00:21 openvpn[29543]: TCP/UDP: Preserving recently used remote address: [AF_INET]{vpn-ip}:1194
Jun 08 17:00:21 openvpn[29543]: Socket Buffers: R=[212992->212992] S=[212992->212992]
Jun 08 17:00:21 openvpn[29543]: UDP link local: (not bound)
Jun 08 17:00:21 openvpn[29543]: UDP link remote: [AF_INET]{vpn-ip}:1194
Jun 08 17:00:21 openvpn[29543]: TLS: Initial packet from [AF_INET]{vpn-ip}:1194, sid=1b24aaa3 232fcdc3
Jun 08 17:00:21 openvpn[29543]: VERIFY OK: depth=2, {cert-info}
Jun 08 17:00:21 openvpn[29543]: VERIFY OK: depth=1, {cert-info}
Jun 08 17:00:21 openvpn[29543]: VERIFY KU OK
Jun 08 17:00:21 openvpn[29543]: Validating certificate extended key usage
Jun 08 17:00:21 openvpn[29543]: ++ Certificate has EKU (str) TLS Web Server Authentication, expects TLS Web Server Authentication
Jun 08 17:00:21 openvpn[29543]: VERIFY EKU OK
Jun 08 17:00:21 openvpn[29543]: VERIFY X509NAME OK: {cert-info}
Jun 08 17:00:21 openvpn[29543]: VERIFY OK: depth=0, {cert-info}
Jun 08 17:00:21 openvpn[29543]: Control Channel: TLSv1.2, cipher TLSv1.2 ECDHE-ECDSA-AES256-GCM-SHA384, 384 bit EC, curve: secp384r1
Jun 08 17:00:21 openvpn[29543]: [{vpn-host}] Peer Connection Initiated with [AF_INET]{vpn-ip}:1194
Jun 08 17:00:22 openvpn[29543]: SENT CONTROL [{vpn-host}]: 'PUSH_REQUEST' (status=1)

I would ideally like to be able limit the OpenVPN client process restarting after receiving SIGUSR1[soft,no-push-reply]. To clarify we are not getting 12 push notifications sent as implied:

Code: Select all

No reply from server after sending 12 push requests

The user is sent 1 and the client seems to poll to see if that notification has been accepted and gives up after 12. Then the process restarts, user gets another push notification, etc, and those restarts continue indefinitely.

I thought the OpenVPN community support forum might have some suggestions if there's any way to configure the OpenVPN client in such a way. Maybe someone else had had a similar issue with push notifications.

[TinCanTech]

This issue we have is that our Identity provider (Okta) has a hard retry limit for push notifications and the OpenVPN client will retry those push notifications indefinitely

I believe you are confusing what Okta refer to as "push notifications" and what openvpn refers to as PUSH_REQUEST.

[alclark]

The terminology may wrong as you say but I believe the issue I'm trying to solve is the same.

After 12 PUSH_REQUESTs with no response, the client receives a SIGUSR1[soft,no-push-reply] and restarts the process. There is a similar configuration for failed connections and the --connect-retry config setting even works exactly the same for this particular restart pause.

This lead me to believe someone with more OpenVPN experience may know of a similar setting that may fit the problem as I couldn't find one but it's feeling like not.

[TinCanTech]

terminology may wrong as you say but I believe the issue I'm trying to solve is the same

I believe you are wrong about that also ..

After 12 PUSH_REQUESTs with no response

Do you know why this happens ?

[alclark]

As far as I know, after the connection is established the OpenVPN Server is waiting for the user to accept a push notification (Okta push notification), triggered via a plugin. And that wait times out after a minute, which coincides with the PUSH_REQUESTS backing off and the client receiving a SIGUSR1[soft,no-push-reply]. It seemed like all of that tied up to be related to the same "push" but if these PUSH_REQUESTs in the client are unrelated then any information on that would be appreciated.

But the behaviour I see on my end is:
1. Start the client - openvpn --config /path/to/config.conf
2. Give username and password
3. Client logs show through to connection established and PUSH_REQUESTS start
4. Receive a push notification to my phone (ignore to simulate user not noticing)
5. After 1 minute the client gets the SIGUSR1[soft,no-push-reply] (when I would expect the server to time out waiting for the notification)
6. The client process restarts and steps 3-5 repeat.

All I'm looking for is whether there's a way to configure the client to upon receiving that SIGUSR1[soft,no-push-reply] to just fail, like the connect-retry-max seems to for the SIGUSR1[soft,connection-reset].

[TinCanTech]

All I'm looking for is whether there's a way to configure the client to upon receiving that SIGUSR1[soft,no-push-reply] to just fail

Classic case of the XY problem..

after the connection is established the OpenVPN Server is waiting for the user to accept a push notification (Okta push notification), triggered via a plugin

That plugin is probably the root cause of your issue. As I said before, I believe this is Okta's issue.

If you want more help here then we need this:
viewtopic.php?f=30&t=22603#p68963