Getting Your Firewall’s Configured
Intending to authenticate your users against Microsoft Active Directory? Before you go any further, you need to make sure all of the proper ports are open between your Active Directory Domain Controller and your OpenVPN server internally. You can see which ports are needed for AD traffic here: What ports on the firewall should be open between Domain Controllers and Member Servers?
First I want to point out that there are MASSIVE differences between OpenVPN Community Edition (free, open-souce) and OpenVPN Access Server (paid version) aside from just the price. If you want to make life easier and have money for your project OpenVPN Access Server is actually quite reasonably priced. This is what my company was using but we wanted to get two-factor authentication going, for which we are going to give a program called Authy a try. Authy isn’t build for the “Access Server” version of OpenVPN… hence my descent into the depths of using the “community edition”.
Anyone that has been around Linux for any length of time knows that part of the beauty and simplicity of linux is that most configuration is done in simple text files. OpenVPN Community Edition is no exception to this (Access Server is…). Getting the syntax correct in those config files is by far the biggest pain in the rear when it comes to making your server work. With that being said, I will be showing you my full config files (with some fictional stuff for my security).
Furthermore, one of the most frustrating things with setting up OpenVPN (and many other things) is that there are a lot of moving parts. You have firewalls, and authentication modules, and server config files, and key files, and usernames/passwords, and client config files, etc. etc. – I have found when working on projects like this that getting the most “bare bones” or “simplistic” configuration working is the best place to start and then gradually adding on features (i.e. complexity) and testing as you go. That way when something does break you aren’t looking at 10 different things as the culprit. With that being said, go… GO NOW… and get your port picked out and your firewall properly configured on both your client test machine, and your network and any other firewalls in-between. If a firewall is blocking UDP on your select port you are going to be beating your head against the wall very soon. DO NOT use a bloody common port (ex. 80, 443, 22, etc.). I did this initially (used port 443) and it caused much headache. Once you come back from getting your firewall straightened out, join us on the next page!
Just an FYI, one of the commands after the second to last reboot prevents any connection to the Linux server