Azure Multi-Factor Authentication Server with OpenVPN brief How-To
-
@apuch I actually recently came across the same issue myself and am searching for a solution too. If you watch the logs you'll see the TLS cert expiring - when this happens it'll send the MFA prompt a few times, and if it is not accepted within a certain time period, the VPN will stop passing traffic (although appearing to stay connected, at least in the Windows OpenVPN connect client). I've had to advise my users to keep their phone in front of them while working so they can see the prompt pop up and just accept it to avoid interrupting connectivity.
I had a brief look but could not see any related settings in pfsense, and also didn't find anything from a quick google. If you find the solution to increase the cert timeout, I'd greatly appreciate a heads up.
-
@jamantus same here.
IP/user removed but this is the log prior to getting the authenticator alert after being on for approx an hour.
Oct 14 11:43:49 openvpn 51963 user/ip TLS Error: local/remote TLS keys are out of sync: [AF_INET]ip [1]
Oct 14 11:43:52 openvpn 51963 user/ip TLS Error: local/remote TLS keys are out of sync: [AF_INET]ip [1]
Oct 14 11:43:56 openvpn 51963 user/ip TLS Error: local/remote TLS keys are out of sync: [AF_INET]ip [1]
Oct 14 11:43:56 openvpn 51963 user/ip TLS Error: local/remote TLS keys are out of sync: [AF_INET]ip [1]
Oct 14 11:43:56 openvpn 51963 user/ip TLS Error: local/remote TLS keys are out of sync: [AF_INET]ip [1]
Oct 14 11:43:57 openvpn 51963 user/ip TLS Error: local/remote TLS keys are out of sync: [AF_INET]ip [1]
Oct 14 11:43:57 openvpn 51963 user/ip TLS Error: local/remote TLS keys are out of sync: [AF_INET]ip [1]
Oct 14 11:43:59 openvpn 51963 user/ip TLS Error: local/remote TLS keys are out of sync: [AF_INET]ip [1]
Oct 14 11:43:59 openvpn 51963 user/ip [user] Inactivity timeout (--ping-restart), restarting
Oct 14 11:44:05 openvpn 51963 TCP connection established with [AF_INET]ip
Oct 14 11:44:05 openvpn 51963 ip peer info: IV_VER=3.git::3e56f9a6
<connection works from here> -
@apuch This could have something to do with it, https://community.openvpn.net/openvpn/wiki/Openvpn23ManPage (search for
--reneg-sec
)--reneg-sec n Renegotiate data channel key after n seconds (default=3600). When using dual-factor authentication, note that this default value may cause the end user to be challenged to reauthorize once per hour."
but I wonder where to configure that on the pfsense side since we do it via the GUI.
Update (it won't let me post a new reply so soon so I'm editing the post)
oh of course, it's in the custom options box (link)
-
@jamantus Is this server side only or you need to download ovpn and repush out to all clients?
Found this also on another blog:
I’m asked to reauthenticate after some time.
You probably forgot to set the reneg-sec n option in Step 13 of Configuration (or the value you set does not fit your needs). The reneg-sec n option allows you to change the time (in seconds) after which a data channel key renegotiation happens. Set to reneg-sec 0 to never have to authenticate again as long as you don’t disconnect. Setting the option to 0 should fix the issue. If you do not want to generate and export a new OpenVPN configuration file again, you can edit your OpenVPN configuration file manually:- Go to your OpenVPN configuration file directory (C:\Program Files\OpenVPN\config by default) and open your configuration file (*.ovpn). Note that you are going to need administrator privileges to change the file, so run the file as administrator.
- Add the following line to the end of the file: reneg-sec 0. If your file already contains a reneg-sec n option, change its value to 0.
- Save the file.
Cheers!
-
@apuch Seems like it's needed on both ends - if there are different values on each end, it will use the lowest value. So I've decided to set it to 14400 (4 hours) on the server side, and disable on the client side.
The openvpn-client-export package has the same custom options box, so I'm going to putreneg-sec 0
and control the setting via the server side to avoid having to push out new config files any time I need to adjust the value.
Server
ClientExport
-
@jamantus Thanks agree - I have added on server and client side, and re-exported.
Can confirm config ovpn now shows "reneg-sec 0"
See how it goes now! Cheers mate. -
-
THX, still working ;)
-
Am I missing something here? I have NPS setup and working, but when I add the Azure AD MFA Extension, I keep getting "wrong credentials" on the VPN Client, I never get an MFA notification.
Is there something else required when authenticating with OpenVPN? I have read people posting "add the TOTP code to the end of your password" and all sorts of other things, such as adding the reg key on the NPS server to fall back to the Prompt method (if number matching is enforced)...
I see in the NPS logs upon connecting "Enter Your Microsoft verification code" and I do see an entry in Azure AD when I try...just nothing on the MFA app when I try and connect.
-
I have exactly the same problem and see exactly the same message in the NPS log file. I can connect fine without Microsoft Azure MFA (now called some new brand name like Entra or Identity) and proper NPS RADIUS calls to Active Directory, but I can't add Azure MFA to the VPN setup.
Note that I know for sure that the current setup works with our existing, old Cisco AnyConnect VPN (using the exact same NPS RADIUS server with the exact same Azure MFA and NPS Extension for Azure MFA. So I have hard proof that the Cisco ASA can do it, but as soon as I attempt to swap out the Cisco ASA with the Netgate 4100, it fails unless I remove the MFA requirement.
<Reply-Message data_type="1">Enter Your Microsoft verification code</Reply-Message>
In the same log event line, there are these tags:
<Packet-Type data_type="0">11</Packet-Type><Reason-Code data_type="0">0</Reason-Code>
The failure is almost instant (it's almost certainly not hitting our 60 second timeout).
Anybody have any ideas on what might have changed in the last few years?
-
It is probably related to the NPS Extension for Azure MFA version, of which we have the latest 1.2.2216.1. My guess is that the prior successful posts were all written when using earlier versions of NPS Extension for Azure MFA.