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.
