Two factor authentication for openVPN in pfsense
-
-
pfSense asks the proxy if username/password is correct
-
The proxy asks the RADIUS server if the username and password are correct
-
If no, the proxy sends an Access-Reject back to pfSense
-
If yes, the proxy starts a duo authentication with the API server
-
If it fails, the proxy sends an Access-Reject to pfSense (this is why you need a longer timeout in the pfSense config - time for all this to happen. I use 60s)
-
If successful, the proxy sends Access-Accept to pfSense
Note that you are free to have a RADIUS server configured in System > User Manager, Servers that points to the RADIUS server and one that points at the Duo proxy. Then you can pick and choose which services must two-factor and which don't by selecting the appropriate authentication server in that service. You can test them in Diagnostics > Authentication.
-
-
So what your after is multifactor, not just 2 factor because by definition if your auth requires something you have and something you know you have your 2 factors.
The cert you have to have on your machine, and the password to said cert and or login would mean your already doing 3 factor. Something you have and 2 things you know. The cert is the thing you have, the password to said cert would be the 1 thing you know, and the username and password to auth to openvpn is the 2nd thing you know.
How is ssl/tls+user auth not meet 2 factor??
-
picky picky but correct. This would be two things he has (the private key and the duo phone) and one thing he knows (the username/password). And in my case the Duo app requires me to enter the phone passcode or TouchID in most cases, so there is another known factor or an are factor.
-
yeah you can go to many many factors.. Duplication of things is not always considered another factor
Normally you can go to 3 factor
something you have
something you know
something you are.My point is he already has 2 factors with the cert and the password.. Adding another just makes it harder to log in, for what possible reason? Is this a gov facility? There is being secure and taking steps to be secure and then there is just overhead and complication for no extra security.
To me the OTP thing, or use of some token that changes code ever so many seconds, etc. is just plain PITA.. And unless your line of work justifies the extra effort its just making it harder to get anything done.
Just my 2 cents on the whole matter… While I think such methods of auth are pretty cool, and fun to setup - actual use of them are PITA..
-
Thanks, this is working now as when I login to OpenVPN it pushes the DUO notification to click to accept, which is good enough for my uses, rather than enter a code which is annoying.
One thing I don't understand is, in the duo config on my duo proxy, both sections I had to put my pfSense ip address as the radius. Does that make sense? It works though…
-
pfSense asks the proxy if username/password is correct
-
The proxy asks the RADIUS server if the username and password are correct
-
If no, the proxy sends an Access-Reject back to pfSense
-
If yes, the proxy starts a duo authentication with the API server
-
If it fails, the proxy sends an Access-Reject to pfSense (this is why you need a longer timeout in the pfSense config - time for all this to happen. I use 60s)
-
If successful, the proxy sends Access-Accept to pfSense
Note that you are free to have a RADIUS server configured in System > User Manager, Servers that points to the RADIUS server and one that points at the Duo proxy. Then you can pick and choose which services must two-factor and which don't by selecting the appropriate authentication server in that service. You can test them in Diagnostics > Authentication.
-
-
The comments in the config file I posted are self-explanatory. Post yours so I can see what you're talking about.
The one in radius_client should be the actual RADIUS server that holds the usernames and passwords.
The one in radius_ip_1 is pfSense which is really a RADIUS client to the proxy (something that asks the proxy to do an authentication).
-
The comments in the config file I posted are self-explanatory. Post yours so I can see what you're talking about.
The one in radius_client should be the actual RADIUS server that holds the usernames and passwords.
The one in radius_ip_1 is pfSense which is really a RADIUS client to the proxy (something that asks the proxy to do an authentication).
Here is my config:
[radius_client]
host=10.10.10.1
secret=[radius_server_auto]
ikey=
skey=
api_host=
radius_ip_1=10.10.10.1
radius_secret_1=
failmode=safe
client=radius_client
port=1812Both IP are pointing to pfsense box's FreeRadius server.
Well since I'm hosting radius with pfsense, which has same IP, I guess they are both the same?
-
yeah you can go to many many factors.. Duplication of things is not always considered another factor
Normally you can go to 3 factor
something you have
something you know
something you are.My point is he already has 2 factors with the cert and the password.. Adding another just makes it harder to log in, for what possible reason? Is this a gov facility? There is being secure and taking steps to be secure and then there is just overhead and complication for no extra security.
To me the OTP thing, or use of some token that changes code ever so many seconds, etc. is just plain PITA.. And unless your line of work justifies the extra effort its just making it harder to get anything done.
Just my 2 cents on the whole matter… While I think such methods of auth are pretty cool, and fun to setup - actual use of them are PITA..
If it's possible and easily done, why not? I'm really the only one that's logging into my network and I rather have another level of authentication. Plus the DUO is a good compromise, all you do is click vs the token codes like google authentication which you have to enter a code. I don't see how that would hinder any real production environment as my company I work for actually uses DUO to authenticate when connecting to VPN from remote.
-
They're not. One is allowing pfSense to send requests to the proxy and the other is asking pfSense's RADIUS server to authenticate.
Mine are different because my RADIUS server isn't pfSense. It's Mac OS X Server.
-
They're not. One is allowing pfSense to send requests to the proxy and the other is asking pfSense's RADIUS server to authenticate.
Mine are different because my RADIUS server isn't pfSense. It's Mac OS X Server.
I think I understand… I guess I could set a different IP address for the RADIUS on pfSense so it's more obvious. Since right now the radius server interface is same IP as pfSense.
-
If both RADIUS client and server on the same node don't over-think it. If you make pfSense do everything, then everything is going to have the same IP address.
I do it this way so everyone's login information is the same. Change their Mac login password, and their VPN (and mail, calendar, etc) password changes. People could enable AD RADIUS and do the same thing. Or use the LDAP Proxy. (I prefer RADIUS because it's not MS-centric).
-
i was wondering if there some kind of token software for the android of iOS to allow 3 steps auth.
already using cert + username + password auth. -
Yeah. Duo as has been discussed works on android. One ought to be able to roll a RADIUS proxy for google authenticator, etc. Not sure about it being running on pfSense. That would be a question for the FreeRADIUS package maintainers.
-
-
pfSense asks the proxy if username/password is correct
-
The proxy asks the RADIUS server if the username and password are correct
-
If no, the proxy sends an Access-Reject back to pfSense
-
If yes, the proxy starts a duo authentication with the API server
-
If it fails, the proxy sends an Access-Reject to pfSense (this is why you need a longer timeout in the pfSense config - time for all this to happen. I use 60s)
-
If successful, the proxy sends Access-Accept to pfSense
Note that you are free to have a RADIUS server configured in System > User Manager, Servers that points to the RADIUS server and one that points at the Duo proxy. Then you can pick and choose which services must two-factor and which don't by selecting the appropriate authentication server in that service. You can test them in Diagnostics > Authentication.
A sample configuration based on the above clear explanation for anyone who wants it
[radius_client] #Step 2: Contact the below IP (Primary authentication server) using the below secret to validate user name and password provided host=10.xx.xx.1 secret=secretonpfsense [radius_server_auto] #Step 4: Contact Duo API (Second factor authentication server) using the below details to approve/reject access request ikey=DIXXXXXXXXXXXXXXXX skey=xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx api_host=api-xxxxxxxxx.duosecurity.com #Step 1: Expect a request from the below IP (pfsense box in this instance) providing the below secret seeking authentication radius_ip_1=10.xx.xx.1 radius_secret_1=secretonproxy failmode=safe client=radius_client port=1812 -
-
Maybe its just me but so are you vpn into a dod facility here? How is a cert, and user name and password not enough? Is your goal to discourage use of the vpn? Then sure add as many hoops you want to actually get in and do some work..
So for someone to get into your vpn with a typical 2 factor setup they need the cert (so device cert installed on) and the username and password. Now you want to also have 3 method… That do be honest just another link in the chain that can fail..
There is security, and then there is just making something so difficult to use that users don't use it or they find ways to bypass it... Which defeats the purpose of the security in the first place. Screw vpn into work on my files, I will just take them with me so I don't have to jump through the ring of fire to get to my stuff..
