OpenVPN Access Server

[rsenio]

I've been setting up and testing the hyper-v version of openvpn as. Couple of things I'm not sure about. Setting the hostname from the shell works until a reboot happens. It then defaults to localhost.localdom. Weird?

Also, is there a way to set the IP of the as0t1 or as0t0 interfaces? It seems to have arbitrarily assigned an address based on my vpn subnet that I setup in the web interface.

One more thing, the default user...openvpn...can log into the VPN no matter what authentication method is chosen. Radius, LDAP etc. Since the only accounts I want connecting to the VPN are my AD users, I dont want the openvpn account to be able to connect to the VPN as a security liability. I realize I can create another account, but I dont want any of the localDB users to have access to connect to the VPN. Only reason for the local user is to administer the OpenVPN server.

[rsenio]

ha, one more. Running the latest version of OpenVPN and client 1.8.3. Loging in I get "Allow VPN connection to blah.blah.com using UNVERIFIED profile?"

If I say no, the client shows blah.blah.com disconnected, profile is not approved.

Umm....what? Is it because I'm using the default certs still?

[udi]

Hi,
My questions are nearly the same as yours Any ideas?
Thanks a lot

[rsenio]

Only thing I've found out so far is that you can create another user, change back to local auth and log in as that user. Set the default OpenVPN account to Deny Access (deny's access to vpn login, not admin login). Log back in as openvpn and delete the other user you just created. Then switch back to whatever auth method you were using before.

I'd love to know what the deal is with the strange message when connecting though.

[udi]

hi,

have you made any progress in this issue? if yes, please let me know!

[rsenio]

Nope, I havent.

[rsenio]

So....no one has seen the message/error "Allow VPN connection to blah.blah.com using UNVERIFIED profile?" while using the latest client???????

[novaflash]

Hello and sorry for the late reply. I don't frequent this forum very much - we usually handle questions through the live chat support system or the support ticket system at http://support.openvpn.net/.

In any case, let's see what I can answer.

So....no one has seen the message/error "Allow VPN connection to blah.blah.com using UNVERIFIED profile?" while using the latest client???????

If I say no, the client shows blah.blah.com disconnected, profile is not approved.

Well, everybody should see that message at least once on a client. There will always be a one-time question asking you if you wish to allow a connection to a VPN server it has not connected to ever before. That it is unverified is because by default the Access Server comes with a self-signed SSL certificate with a nonsense name. If you want to set it up correctly then you can purchase an SSL certificate matching the host name (FQDN) that you are using. For example, vpnserver1.mymegasupercompany.com or whatever you are using. Once that is installed in the Access Server then the client should be able to verify that the profile is trusted. But even then, the message will merely be of a different format, like "Do you wish to allow a connection to vpnserver1.mymegasupercompany.com?". This is a courtesy message informing the user that a VPN configuration profile is now being installed for that server, and if you want to allow this or not. And if you answer no, then you see "profile is not approved" - not approved by you, that means to say.

Only thing I've found out so far is that you can create another user, change back to local auth and log in as that user. Set the default OpenVPN account to Deny Access (deny's access to vpn login, not admin login). Log back in as openvpn and delete the other user you just created. Then switch back to whatever auth method you were using before.

What an interesting and convoluted message of adding a user! Congratulations on finding this unique and interesting method. But really now, the important thing to remember is that Access Server is capable of authenticating against 4 different sources. Namely, a local SQLite database that can be managed fully from the inbuilt web based admin UI, a PAM service, an LDAP server or a RADIUS server.

Local management can be done completely from the browser. You can go to user permissions in the admin UI and add/remove users and set passwords for these users and be done with it. For small implementations with a limit of up to about 50 to a 100 users max this is the easiest option.

A PAM service is usually already present in a Linux operating system and this works with the local users. If you just do "adduser bla" and then assign bla a password "passwd bla" then Access Server will automatically pick up on it. It might not show in the user permissions screen, but when you try to log in as that user with that password, it ought to function.

Same goes for LDAP and RADIUS, really. You can add users in those systems and if you've provided the correct methods of connecting to one of these systems, it will allow users to log in at the Access Server with usernames and passwords that are stored in the LDAP/RADIUS servers. This is useful for connecting the Access Server to a Windows server with Active Directory.

For PAM, LDAP and RADIUS you may still need to use the admin UI to specify specific properties for certain users. If for example you want to give the PAM user "bla" the autologin right, then go to user permissions, add a user with the exact name "bla", so that it matches with what PAM knows, and give it autologin rights there. When the user "bla" logs in, authentication is done against the PAM service and the properties defined under user permissions on the user with the name "bla" will apply then.

Setting the hostname from the shell works until a reboot happens. It then defaults to localhost.localdom. Weird?

No, not really. The hostname is stored in a small text file, usually /etc/hostname. Change the contents of that file to make the hostname change permanent.

Also, is there a way to set the IP of the as0t1 or as0t0 interfaces? It seems to have arbitrarily assigned an address based on my vpn subnet that I setup in the web interface.

No, and you shouldn't try. The Access Server employs multiple OpenVPN daemons to cover the use of both TCP and UDP protocols and to make full use of all the CPU cores. The subnet you have defined in the web interface is being split equally over these daemons. Access Server allows these separate daemons to communicate with each other as if it were one OpenVPN daemon, and applies access rules where necessary to direct traffic. Changing the addresses on these interfaces is not the correct method of working with Access Server and for most purposes you should leave these interfaces alone. I don't really know why you would want to change these because this is all pretty much handled automatically on both the server and the client side.

One more thing, the default user...openvpn...can log into the VPN no matter what authentication method is chosen. Radius, LDAP etc. Since the only accounts I want connecting to the VPN are my AD users, I dont want the openvpn account to be able to connect to the VPN as a security liability. I realize I can create another account, but I dont want any of the localDB users to have access to connect to the VPN. Only reason for the local user is to administer the OpenVPN server.

Yes, this is done on purpose. It is called the bootstrap user. It has access always. The reason for this is because if you use LDAP or RADIUS, and the connection to the LDAP/RADIUS server is interrupted for whatever reason, you have no way of logging in. Therefore, the openvpn user remains the exception in that you can always log in under this account. This is not that much of a security leak because first of all, during the installation you had the option of changing this username to anything you like. After installation you still can but it's slightly more involved. And second, the Access Server's web services are protected against brute-forcing by temporarily locking out continuous bad password login attempts. And besides, you can fix this situation by doing the following:

Open the console of the Access Server or log into it using SSH.
Assuming you have root, or assuming you use sudo before your commands:
nano /usr/local/openvpn_as/etc/as.conf
Then find the line that says:
boot_pam_users.0=openvpn
Then simply comment out that line like so:
# boot_pam_users.0=openvpn

I think you can tell from this that it is easily possible to alter the username of the bootstrap user here, but please note that you must make sure that user does exist on the local system. So "adduser supermegaadminuserthing" and then altering the line to read "boot_pam_users.0=supermegaadminuserthing" would pretty much be the thing to do then.

[rsenio]

What an interesting and convoluted message of adding a user! Congratulations on finding this unique and interesting method. But really now, the important thing to remember is that Access Server is capable of authenticating against 4 different sources. Namely, a local SQLite database that can be managed fully from the inbuilt web based admin UI, a PAM service, an LDAP server or a RADIUS server.

Oh yes, I totally understand that already. However, I was only trying to find a way to prevent the openvpn user from having VPN log in access. You cannot alter the openvpn user while logged in as that user. My current auth method is Radius, but creating another "admin" account wont let you log in unless you switch back to local auth (PAM), at which point you can alter the openvpn user.

not really. The hostname is stored in a small text file, usually /etc/hostname. Change the contents of that file to make the hostname change permanent.

Again, the change does not stay after a reboot. Although I'm not sure if there's any negative impact with not having this set.

during the installation you had the option of changing this username to anything you like

During the install of hyper-v version of OpenVPN-AS I had no option of setting a username

[novaflash]

Oh yes, I totally understand that already. However, I was only trying to find a way to prevent the openvpn user from having VPN log in access. You cannot alter the openvpn user while logged in as that user. My current auth method is Radius, but creating another "admin" account wont let you log in unless you switch back to local auth (PAM), at which point you can alter the openvpn user.

Right. With the information I've given you, you could just add a PAM user and stick it in as.conf under the bootstrap key I mentioned.

Again, the change does not stay after a reboot. Although I'm not sure if there's any negative impact with not having this set.

It's possible you also need to edit the /etc/hosts file to reflect the changes.

During the install of hyper-v version of OpenVPN-AS I had no option of setting a username

ovpn-init must have already been run on that once then. To see what I mean you'll have to wipe your setup and run ovpn-init --force to get that question. No matter, you can just change it to another PAM user.

[rsenio]

It's possible you also need to edit the /etc/hosts file to reflect the changes.

Doesn't help as well. After a restart the files are reverted back to the defaults.

[novaflash]

This is not really an issue with Access Server and doesn't really matter. I suggest you Google search for the instructions on how to permanently change the hostname on your operating system. I believe it is either Debian or Ubuntu that you are using. You can usually find out by doing this:
uname -a
lsb_release -a

That should get you some information to determine what OS you're using.

Good luck.

[rsenio]

Applied the fix from here, just added an entry into my Active Directory DNS server for the vpn appliance
http://communities.vmware.com/thread/213902

[udi]

@novaflash
thanks a lot for your detailed answers
merry christmas

[begaagi]

Hello and sorry for the late reply. I don't frequent this forum very much - we usually handle questions through the live chat support system or the support ticket system at http://support.openvpn.net/fun wifi name.

In any case, let's see what I can answer.

So....no one has seen the message/error "Allow VPN connection to blah.blah.com using UNVERIFIED profile?" while using the latest client???????

If I say no, the client shows blah.blah.com disconnected, profile is not approved.

Well, everybody should see that message at least once on a client. There will always be a one-time question asking you if you wish to allow a connection to a VPN server it has not connected to ever before. That it is unverified is because by default the Access Server comes with a self-signed SSL certificate with a nonsense name. If you want to set it up correctly then you can purchase an SSL certificate matching the host name (FQDN) that you are using. For example, vpnserver1.mymegasupercompany.com or whatever you are using. Once that is installed in the Access Server then the client should be able to verify that the profile is trusted. But even then, the message will merely be of a different format, like "Do you wish to allow a connection to vpnserver1.mymegasupercompany.com?". This is a courtesy message informing the user that a VPN configuration profile is now being installed for that server, and if you want to allow this or not. And if you answer no, then you see "profile is not approved" - not approved by you, that means to say.

Only thing I've found out so far is that you can create another user, change back to local auth and log in as that user. Set the default OpenVPN account to Deny Access (deny's access to vpn login, not admin login). Log back in as openvpn and delete the other user you just created. Then switch back to whatever auth method you were using before.

What an interesting and convoluted message of adding a user! Congratulations on finding this unique and interesting method. But really now, the important thing to remember is that Access Server is capable of authenticating against 4 different sources. Namely, a local SQLite database that can be managed fully from the inbuilt web based admin UI, a PAM service, an LDAP server or a RADIUS server.

Local management can be done completely from the browser. You can go to user permissions in the admin UI and add/remove users and set passwords for these users and be done with it. For small implementations with a limit of up to about 50 to a 100 users max this is the easiest option.

A PAM service is usually already present in a Linux operating system and this works with the local users. If you just do "adduser bla" and then assign bla a password "passwd bla" then Access Server will automatically pick up on it. It might not show in the user permissions screen, but when you try to log in as that user with that password, it ought to function.

Same goes for LDAP and RADIUS, really. You can add users in those systems and if you've provided the correct methods of connecting to one of these systems, it will allow users to log in at the Access Server with usernames and passwords that are stored in the LDAP/RADIUS servers. This is useful for connecting the Access Server to a Windows server with Active Directory.

For PAM, LDAP and RADIUS you may still need to use the admin UI to specify specific properties for certain users. If for example you want to give the PAM user "bla" the autologin right, then go to user permissions, add a user with the exact name "bla", so that it matches with what PAM knows, and give it autologin rights there. When the user "bla" logs in, authentication is done against the PAM service and the properties defined under user permissions on the user with the name "bla" will apply then.

Setting the hostname from the shell works until a reboot happens. It then defaults to localhost.localdom. Weird?

No, not really. The hostname is stored in a small text file, usually /etc/hostname. Change the contents of that file to make the hostname change permanent.

Also, is there a way to set the IP of the as0t1 or as0t0 interfaces? It seems to have arbitrarily assigned an address based on my vpn subnet that I setup in the web interface.

No, and you shouldn't try. The Access Server employs multiple OpenVPN daemons to cover the use of both TCP and UDP protocols and to make full use of all the CPU cores. The subnet you have defined in the web interface is being split equally over these daemons. Access Server allows these separate daemons to communicate with each other as if it were one OpenVPN daemon, and applies access rules where necessary to direct traffic. Changing the addresses on these interfaces is not the correct method of working with Access Server and for most purposes you should leave these interfaces alone. I don't really know why you would want to change these because this is all pretty much handled automatically on both the server and the client side.

One more thing, the default user...openvpn...can log into the VPN no matter what authentication method is chosen. Radius, LDAP etc. Since the only accounts I want connecting to the VPN are my AD users, I dont want the openvpn account to be able to connect to the VPN as a security liability. I realize I can create another account, but I dont want any of the localDB users to have access to connect to the VPN. Only reason for the local user is to administer the OpenVPN server.

Yes, this is done on purpose. It is called the bootstrap user. It has access always. The reason for this is because if you use LDAP or RADIUS, and the connection to the LDAP/RADIUS server is interrupted for whatever reason, you have no way of logging in. Therefore, the openvpn user remains the exception in that you can always log in under this account. This is not that much of a security leak because first of all, during the installation you had the option of changing this username to anything you like. After installation you still can but it's slightly more involved. And second, the Access Server's web services are protected against brute-forcing by temporarily locking out continuous bad password login attempts. And besides, you can fix this situation by doing the following:

Open the console of the Access Server or log into it using SSH.
Assuming you have root, or assuming you use sudo before your commands:
nano /usr/local/openvpn_as/etc/as.conf
Then find the line that says:
boot_pam_users.0=openvpn
Then simply comment out that line like so:
# boot_pam_users.0=openvpn

I think you can tell from this that it is easily possible to alter the username of the bootstrap user here, but please note that you must make sure that user does exist on the local system. So "adduser supermegaadminuserthing" and then altering the line to read "boot_pam_users.0=supermegaadminuserthing" would pretty much be the thing to do then.

This is not really an issue with Access Server and doesn't really matter. I suggest you Google search for the instructions on how to permanently change the hostname on your operating system. I believe it is either Debian or Ubuntu that you are using. You can usually find out by doing this:
uname -a
lsb_release -a