OpenVPN users only allowed if in admins group?

dszp

OK I've searched the forums extensively and looked in the wiki, but help me out…is it possible to assign OpenVPN users (SSL+User auth) that are allowed to login to OpenVPN only but NOT to the web interface, or anywhere important? It seems like I have to add users to the "admins" group to allow OpenVPN login from what I can tell by experimenting. Even if I grant every privilege to an "openvpn" user group I created, the user still can't login unless I add them as a member of the admin group. I see http://redmine.pfsense.org/issues/736 but I'm OK with users getting access to 'all services' (IPsec, OpenVPN, captive portal) but not with them being able to login to pfSense and administer the entire system. Do I have to remove user-auth to accomplish this for now?

eri--

Can you give evidence in form of logs and openvpn configs to be able to reproduce this?

dszp

I don't have logs, yet anyway. Going to be crazy busy tomorrow with other stuff. But I created a group, added new user just to that group, initially added no permissions, and then used Client Export to download an OpenVPN connectoid for a tunnel that uses both Certs and user authentication. Using that username and password it would never connect, but when using a username that was a member of the admins group, it would always connect fine. I edited the group, adding permission areas each time (first just User permissions and eventually doing a Select All and saving), and even with all permissions assigned to that group, the user would still get an AUTH_ERROR message in the OpenVPN GUI client and be asked to retry user/pass (three times before giving up). Added that user to the admins group and it connected the very next try. Snapshot from Sun Feb 6 15:16:13 EST 2011 i386. Internal CA and certificates generated for users in user manager.

When I changed the tunnel settings to require SSL only (cert but no user auth), and re-downloaded the config file export to update the settings, it also connects just fine with the user that wasn't working before, only it never prompts for a username/password (which is correct when not doing user-auth, obviously).

I may be able to test/gather logs sometime this weekend but likely not before then.

Nachtfalke

Hi,

I didn't have such problems. I am testing it at the moment and it works with 2.0-BETA5 (i386) built on Tue Feb 8 05:33:31 EST 2011:

Fri Feb 11 08:36:33 2011 OpenVPN 2.1.3 i686-pc-mingw32 [SSL] [LZO2] [PKCS11] built on Aug 20 2010
Fri Feb 11 08:36:39 2011 IMPORTANT: OpenVPN's default port number is now 1194, based on an official port number assignment by IANA.  OpenVPN 2.0-beta16 and earlier used 5000 as the default port.
Fri Feb 11 08:36:39 2011 WARNING: No server certificate verification method has been enabled.  See http://openvpn.net/howto.html#mitm for more info.
Fri Feb 11 08:36:39 2011 NOTE: OpenVPN 2.1 requires '--script-security 2' or higher to call user-defined scripts or executables
Fri Feb 11 08:36:39 2011 Control Channel Authentication: using 'pfsense1-udp-1194-tls.key' as a OpenVPN static key file
Fri Feb 11 08:36:39 2011 LZO compression initialized
Fri Feb 11 08:36:39 2011 UDPv4 link local (bound): [undef]:1194
Fri Feb 11 08:36:39 2011 UDPv4 link remote: XX.YYY.ZZ.25:1194
Fri Feb 11 08:36:39 2011 WARNING: this configuration may cache passwords in memory -- use the auth-nocache option to prevent this
Fri Feb 11 08:37:02 2011 [OpenVPN-Server1] Peer Connection Initiated with XX.YYY.ZZ.25:1194
Fri Feb 11 08:37:09 2011 TAP-WIN32 device [LAN-Verbindung 2] opened: \\.\Global\{51D939D1-7722-4A3A-A17E-1C51D70D7677}.tap
Fri Feb 11 08:37:09 2011 Notified TAP-Win32 driver to set a DHCP IP/netmask of 10.0.0.6/255.255.255.252 on interface {51D939D1-7722-4A3A-A17E-1C51D70D7677} [DHCP-serv: 10.0.0.5, lease-time: 31536000]
Fri Feb 11 08:37:09 2011 Successful ARP Flush on interface [65542] {51D939D1-7722-4A3A-A17E-1C51D70D7677}
Fri Feb 11 08:37:15 2011 WARNING: potential route subnet conflict between local LAN [172.17.0.0/255.255.0.0] and remote VPN [172.17.0.0/255.255.0.0]
Fri Feb 11 08:37:15 2011 Initialization Sequence Completed

I have created a Group GUESTS and within a USER VPN1 with which I connect with SSL/TSL and User_AUTH.
Had no problems to connect and like you could see, connection is working fine.

Fri Feb 11 08:37:15 2011 WARNING: potential route subnet conflict between local LAN [172.17.0.0/255.255.0.0] and remote VPN [172.17.0.0/255.255.0.0]

This is because I am starting the VPN connection frome the same subnet as OpenVPN connects me to.

–-edit----
Works with 2.0-BETA5 (i386) built on Thu Feb 10 02:42:11 EST 2011

user.JPG_thumb

dszp

Odd, initially I was getting denied a connection because traffic for OpenVPN (on the default port) was Denied by Default Rule, so I deleted it and recreated the rule and now it works (was using UDP and everything right, but log showed the connection being denied based on default deny rule).

Anyway, once I got the connection working, I tried to connect with a user from the "openvpn" group I created. I got an authentication error again, so renamed the group to "usersopenvpn" and saved it (it has no permissions assigned) and now the user can login to OpenVPN. So something was "stuck" both in the firewall rules and the group (I reset states before trying any of this), but now it's working. Can't explain it, if I see it again I'll report more details. This is all on a second firewall from the one I originally submitted about, that was having the same problem. I'll check the original one soon and see if I can get repeat results with SSL/user auth.