Opened 4 years ago
Closed 4 years ago
#1287 closed Bug / Defect (notabug)
--connect-retry-max setting ignored
Reported by: | alclark | Owned by: | |
---|---|---|---|
Priority: | major | Milestone: | release 2.4.8 |
Component: | Generic / unclassified | Version: | |
Severity: | Not set (select this one, unless your'e a OpenVPN developer) | Keywords: | |
Cc: |
Description
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.
Change History (6)
comment:1 Changed 4 years ago by
comment:2 Changed 4 years ago by
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)
comment:3 Changed 4 years ago by
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 intended?
comment:4 Changed 4 years ago by
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)
comment:5 Changed 4 years ago by
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
comment:6 Changed 4 years ago by
Resolution: | → notabug |
---|---|
Status: | new → closed |
This works for me: