--connect-retry-max setting ignored

[alclark]

It looks like any setting for --connect-retry-max either via the CLI or .conf file is being ignored for our VPN Client. We MFA set up via Okta with push notifications and currently the VPN client will retry indefinitely if nothing is found for the push notification. So for example, when a user starts the client service via Systemd it prompts for a username/password and then returns and in the background sends a push notification. If the user forgets about this or doesn't notice the notifications, they are locked out after 5 retries.

We wanted to use --connect-retry-max to limit these retries but no matter what it's set to via CLI argument or client.conf file the client still retries indefinitely. Is there a catch to this setting or a reason why the SIGUSR1 returned when the user doesn't acknowledge the push notification wouldn't be counted against these retries?

Let me know if there's any other information of use.

[tct]

This works for me:

Mon Jun  8 15:12:09 2020 us=385991 Attempting to establish TCP connection with [AF_INET]{server-ip}:1194 [nonblock]
Mon Jun  8 15:12:09 2020 us=386121 TCP connection established with [AF_INET]{server-ip}:1194
Mon Jun  8 15:12:09 2020 us=386146 TCP_CLIENT link local: (not bound)
Mon Jun  8 15:12:09 2020 us=386160 TCP_CLIENT link remote: [AF_INET]{server-ip}:1194
Mon Jun  8 15:12:09 2020 us=403065 Connection reset, restarting [0]
Mon Jun  8 15:12:09 2020 us=403188 TCP/UDP: Closing socket
Mon Jun  8 15:12:09 2020 us=403277 SIGUSR1[soft,connection-reset] received, process restarting
Mon Jun  8 15:12:09 2020 us=403319 Restart pause, 5 second(s)
Mon Jun  8 15:12:14 2020 us=408796 All connections have been connect-retry-max (1) times unsuccessful, exiting
Mon Jun  8 15:12:14 2020 us=408920 Exiting due to fatal error

[alclark]

Ah yeah, this was why I wondered about the different signal for the missing push reply. This is what I get with --connect-retry-max 0, may be more of an issue that the missing push reply isn't seen as a connection reset.

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)

[tct]

Server initiates connection prior to PUSH_REQUEST

Mon Jun  8 20:54:26 2020 us=436841 127.0.0.1:46381 [c05] Peer Connection Initiated with [AF_INET]127.0.0.1:46381
Mon Jun  8 20:54:26 2020 us=436879 c05/127.0.0.1:46381 MULTI_sva: pool returned IPv4=10.127.121.2, IPv6=(Not enabled)
Mon Jun  8 20:54:27 2020 us=652322 c05/127.0.0.1:46381 PUSH: Received control message: 'PUSH_REQUEST'

Client initiates connection prior to PUSH_REQUEST:

Mon Jun  8 20:54:26 2020 us=436841 [s01] Peer Connection Initiated with [AF_INET]127.0.0.1:1194
Mon Jun  8 20:54:27 2020 us=652161 SENT CONTROL [s01]: 'PUSH_REQUEST' (status=1)

IE. The connection is established.

From man 8 openvpn:

--connect-retry-max n
              n specifies the number of times each --remote or 
<connection> entry is tried. Specifying n as one would try each 
entry exactly once.
              A successful connection resets the counter. 
(default=unlimited).

Would you agree that --connect-retry-max is working as expected?

[alclark]

Ah, OK yes, sorry, thanks for pointing that out! Yes --connect-retry-max does seem to be working then. I was also a bit confused by the fact that the --connect-retry setting still applies to the retry after the missing push reply.

Out of interest do you know of any similar setting that would apply in this situation to stop the infinite retry on push notifications? (I understand if this is not the correct place and can take it to the forums)

[tct]

do you know of any similar setting that would apply in this situation to stop the infinite retry on push notifications?

Presuming you mean OpenVPN PUSH_REQUEST, from your own log you can see that the client restarts after 12 unanswered PUSH_REQUESTs.

Moved to: ​https://forums.openvpn.net/viewtopic.php?f=22&t=30437