Deploying OpenVPN on ESXi
Have you ever wondered to yourself, “What is OpenVPN and what is it used for?” I know I have! I currently leverage OpenDNS’s servers in my network, and when I saw that they offer an Open-Source VPN solution, I figured I had to give it a whirl! While I have used VPN’s before for connecting to a company network from a remote location, or using a VPN service while travelling and connecting to numerous public hot-spots for the added security, I never thought to implement my own for personal use where I can connect to my home network and browse my devices or surf the net securely as if I was sitting at home in front of my computer from anywhere in the world. Well…welcome OpenVPN!
As stated on their website… “OpenVPN Access Server is a full-featured secure network tunneling VPN software solution that integrates OpenVPN server capabilities, enterprise management capabilities, simplified OpenVPN Connect UI, and OpenVPN Client software packages that accommodate Windows, MAC, Linux, Android, and iOS environments. OpenVPN Access Server supports a wide range of configurations, including secure and granular remote access to internal network and/ or private cloud network resources and applications with fine-grained access control.”
OpenVPN offers a variety of different software installation packages and virtual appliance to suit your needs. I opted for the VMware virtual appliance to deploy in my home network. In this tutorial, I will show you just how to deploy an OpenVPN Access Server on ESXi 6.5. For the purposes of this demonstration, I will be deploying said appliance on a virtual ESXi host running in my lab so without any further hesitation, let’s get started!
- Head on over to the OpenVPN website and download the virtual appliance for VMware.
- At the time of this writing, the current version is 2.1.3 released back on 9/16/2016. Installation instructions are also provided on this site. Once you have obtained the virtual appliance, connect to your ESXi host via the ESXi Host UI or the vCenter Web Client.
- As I am just working on a single host without a vCenter, I will leverage the ESXi Host UI. Follow along to deploy the appliance…
- Now that the appliance has been deployed, go ahead and power it on then open a Remote Console session to the appliance. I will be leveraging the VMware VMRC version 9.0. Once the appliance has booted, you will be presented with the following screen.
- Now, login to the appliance using the following default credentials.
- Username – root
- Password – openvpnas
- We are now entering the configuration wizard. Type “yes” to accept the license agreement and begin the wizard
- From this point, a series of questions will be presented. For the most part, we will be accepting the defaults so follow along to configure the appliance.
- Will this be the primary Access Server node?
- Explanation: If this is your initial Access Server node, press Enter to accept the default setting. Otherwise, if you are setting up your failover node, change this to say no.
- Please specify the network interface and IP address to be used by the Admin Web UI:
- Explanation: This will be the interface where OpenVPN Access Server will listen to Admin Web UI requests. Make sure you have access to the interface listed otherwise you will be unable to login to your server. If you are uncertain on what interface to use, select option 1 for all interfaces. Do note that if your network did not assign your appliance a DHCP lease or if you are planning to use a static IP for your server, you will need to specify all interfaces here and follow the instructions for assigning a Static IP in the later section of this article. This option may be changed any time after the completion of the wizard in the Web Admin UI.
- Please specify the port number for the Admin Web UI.
- Explanation: This is the port you will use to access the web-based administration area. It is usually safe to leave this at the default port unless customization is desired.
- Please specify the TCP port number for the OpenVPN Daemon
- Explanation: This is the port clients will use to connect to your VPN server. This port will have to be forwarded to the Internet if your server is behind a NAT-based router. By default, the web-based administration area also runs on this port for your convenience, although this setting can be disabled in the Admin Web UI interface.
- Should client traffic be routed by default through the VPN?
- Explanation: If you only have a small network you would like your remote users to connect over the VPN, select no. Otherwise, if you would like everything to go through the VPN while the user is connected (especially useful if you want to secure data communications over an insecure link), select yes for this option.
- Should client DNS traffic be routed by default through the VPN?
- Explanation: If you would like your VPN clients to able to resolve local domain names using an on-site DNS server, select yes for this option. Otherwise, select no. Do note that if you selected yes for the previous option, all traffic will be routed over the VPN regardless what you set for this setting here.
- Use local authentication via internal DB?
- Explanation: If you would like OpenVPN Access Server to keep an internal authentication database for authenticating your users, select yes for this option. When this option is turned on, you will be able to define and/or change username and passwords within the Admin Web UI. If you select no for this option, Linux PAM authentication will be used and you will need to add/change/delete users within the Linux operating system itself. If you would like to use LDAP or RADIUS as your authentication method, you will need to change this after you login to the Web Admin UI.
- Should private subnets be accessible to clients by default?
- Explanation: This option defines the default security setting of your OpenVPN Access Server. When Should client traffic be routed by default through the VPN? is set to no, it defines the list of subnets that your VPN clients is able to access. You are able to add more entries to this list once you log in to the Admin Web UI area. This option will have no effect if Should client traffic be routed by default through the VPN? is set to yes.
- Do you wish to login to the Admin UI as “openvpn”?
- Explanation: This defines the initial username in which you would use to login to the Access Server Admin UI area. This username will also serve as your “lock out” administrator username shall you ever lock yourself out of your own server. If you would like to specify your own username, select no. Otherwise, accept yes for the default.
- Specify the username for an existing user or for the new user account:
- Explanation: Enter the initial username you would like to use instead of the default ‘openvpn‘.
- Type the password for the ‘user’ account: > Confirm the password for the ‘user’ account:
- Explanation: Specify the password you would like to use for the account.
- Please specify your OpenVPN-AS license key (or leave blank to specify later):
- Explanation: If you have purchased a license key for your OpenVPN Access Server software, enter it here. Otherwise, leave it blank. OpenVPN Access Server includes two free licenses for testing purposes. After you complete the setup wizard, you can access the Admin Web UI area to configure other aspects of your VPN. The URL for the Admin Web UI area is displayed upon the completion of the setup wizard. As mentioned previously, you will be able to access the Admin Web UI on both the VPN port and the Admin port unless you disable this behavior in the Admin Web UI. Note: If you selected yes to the Do you wish to login to the Admin UI as “openvpn”? option in the setup wizard, you will need to define the password for this account by running: passwd openvpn and press Enter.
- Will this be the primary Access Server node?
- The only options I changed from the defaults are as follows…
- Port used by the OpenVPN Daemon
- I used “9443”
- Use local authentication via internal DB
- I said “yes”
- Do you wish to login to the Admin UI as “openvpn”?
- I said “no” and then specified a username and password.
- Port used by the OpenVPN Daemon
- There are also a few optional settings you can configure which are detailed on the instructions web page but I will not cover them here.
- If an at point you mess up during the initial configuration, first complete it and then from the command prompt type
- This will prompt you to type “DELETE” to wipe the current config so you can start over.
- Now that the appliance is deployed and configured, a port-forwarding rule is required to pass traffic to the appliance so it can be connected to from outside your network. Head over to your router and configure the TCP port you defined during the initial configuration for the OpenVPN Daemon to forward to the IP of the appliance. An additional UDP port-forward is needed for port 1194 to the appliance’s IP address.
TCP Port 9443 #this is the port that I defined in the configuration UDP Port 1194
- Once the port forwarding rules are in place, you can connect to the appliance via a web browser on your network as well as from an external network. Let’s start by testing connectivity from within our network. Open a web browser and navigate to the appliance admin login page
- If successful, you should see the login page and can log in with the credentials set during configuration. From here you can configure the appliance to your liking then download the OpenVPN Client for use on Windows, Mac, etc. I will not cover the settings in this tutorial but feel free to poke around here and configure your appliance before logging out.
- You can also connect to the appliance without the “/admin” in the URL so that you can download your client. You can use either option from the drop-down menu.
- If you choose the “Connect” option, you will see this screen which will prompt you to download the OpenVPN Client for your computer.
- If you choose “Login” option, you will see this screen which provides various download links for other devices, as well as the option to download your custom profile to be used in the client so that you connect to your personal VPN environment.
- To connect to your VPN network from an external network, you will need to obtain your external IP address by using “What’s My IP” or “IP Chicken” websites. Then enter that IP address in your web browser with the TCP port you defined in your port-forward rule.
- I tested this from my phone and was successful. Then you can download the profile and use a VPN client on your phone or computer to access your network via your OpenVPN appliance.
Well, I hope this helps shed some more light on the awesomeness of OpenVPN and that you’ve found this useful. Thanks for reading and please comment and subscribe!
Home Lab 2017 – Part 1 (Network and Lab Overhaul)
For the last 6+ months, I haven’t had much time to dedicate to my home lab and overall home network. Between holidays, transitioning to a new employer/role, and everyday life getting in the way, I found that I had to put everything on the back burner for a bit…so I inevitably shutdown by home lab. Well now I am back and am looking forward to writing up some new material that I have been meaning to do for a while. I will start this by saying this is a continuation of my Home Lab 2016 Series, now being dubbed as “Home Lab 2017“!
So first and foremost, I powered up my home lab once again and I intend to leave it up and running at 100% uptime. While doing so, my Synology NAS decided to reboot itself for an auto-update, right in the middle of a VM’s (my domain controller to be exact) boot process. This would eventually cause my VMDK file to become corrupted and I could no longer boot my DC and reconnect my home lab. I also had not yet backed anything up since the environment was still fairly new so I figured why not take this opportunity to rebuild everything and get some new components.
I decided to add a few more (3 per host to be exact), extremely quiet, Noctua NF-A4x10 FLX 40mm fans. This will help to keep my ATOM CPU cool as well as exhaust any hot air from out of each case. I had also been contemplating on doing a Network equipment overhaul. Last year I upgraded my ASUS RT-AC68U SOHO Router with a Ubiquiti ERLite-3 EdgeRouter, and turned the ASUS into a wireless AP only. I do not have a single complaint in the performance and overall stability of that setup. But I recently began looking at the Ubiquiti UniFi gear, and noticed that it the Unified Security Gateway basically runs the same EdgeOS found in the ERLite-3, just with a different web-interface. Realizing that we are in this new wave of cloud-managed networking, and seeing that the USG-3P was basically on-par with the ERLite-3, I bit the bullet and ordered my new Ubiquiti UniFi gear to replace my current setup. The featureset in the EdgeRouter series of routers still has the edge over the UniFi’s features but it’s only a matter of time before they are equal, or UniFi surpasses the EdgeRouters.
I decided on the following products:
- UniFi Controller Cloud Key (UC-CK)
- UniFi Security Gateway (USG-3P)
- UniFi Switch 8-60W (US-8-60W)
- UniFi AP-AC-Pro (UAP-AC-Pro)
After getting everything connected, I will say that I was extremely impressed with the ease of setup, current feature set, and the presentation of the Web UI. I am not going to go into the specifics of how to set it all up, etc. as this is not a UniFi tutorial, but I will say that the little quick start guides tell you everything you need to know. One can also consult “Mr. Google” for more information.
My only gripe with the current feature set of the USG-3P is that there is no support for Jumbo Frames…yet!…but hopefully that will come in a future firmware release. The US-8-60W does indeed support Jumbo Frames so I enabled in on there at least for now. Additionally, the VOIP LAN port on the USG-3P is there for a future release to add support for it. I have also read some threads were feature requests have been submitted to allow said port to be used as a secondary LAN/WAN port instead of just for VOIP. This is currently in beta, but once these settings are added, I feel it would bring the device closer to the capabilities of the ERLite-3 in terms of features. Only time will tell…
Now that I had my basic home network configured, LAN & WiFi-LAN, I powered on my Cisco lab switches and began migrating all of my VLANs over to the new USG-3P, thus removing the need for any static routing which I relied on with my previous setup. Next, I powered on all of my hosts, and began upgrading them to ESXi 6.5. Finally, I was finally on my way to getting up to the latest release of vSphere! Once all of my hosts were upgraded, with the exception of my dev-host as the CPU is not supported in ESXi 6.5, I began spinning up a few new VMs. I took this time to install Windows Server 2016 for my Domain Controllers, and decided to ditch the Windows-based vCenter server in favor of the vCenter Server Appliance (vCSA) since it now has vSphere Update Manager (vUM) integration and the appliance runs on VMware’s Photon OS.
Once my vSphere environment was minimally setup, I started to deploy some more VM’s with the vSphere Web Client, and I must say the speed and performance of the Web Client in 6.5 is “night-and-day” as compared to the Web Client in 6.0! Nore more need for the Client Integration Plugin as the newer version for 6.5 runs as a service. This is the way the web client should have been designed from the very beginning instead of making us all suffer because of how slow the Flash-based version previously was. Although I always preferred to use the Web Client because of the features within it, I can see why so many users still used the C# “fat-client” instead. Who wants to wait forever and a year just for the Hosts and Clusters view, or VM’s and Templates view to load?!?!? I know that I dreaded the loading times. Currently, my vSphere lab consists of the following machines…for now.
- 2 – Domain Controllers (I’ve learned my lesson and the consequences of only having one DC…)
- 1 – vCenter Server Appliance
- 1 – vSphere Data Protection Appliance
- 1 – Windows 10 Management Jumpbox
- 1 – IP Address Management Server (phpIPAM)
- 1 – Mail Server (hMailServer)
- 1 – WSUS Server
- 1 – SCCM Server ( I am currently teaching this to myself and may eventually leverage SUP, thus replacing/repurposing my current WSUS server)
- 1 – vRealize Configuration Manager (vCM) Server ( I am also teaching this to myself as to become more familiar with the product and its capabilities)
- 1 – OpenVPN Appliance
So now that my Home Lab has been upgraded and completely rebuilt, I look forward to spending more time tinkering with it and putting it to good use for exam studies and personal knowledge. I am dedicating my Sundays as “Home Lab Fun-days”! Thanks for stopping by and I hope you enjoyed the read! Please comment below and subscribe!
Create a macOS/OS X VM on VMware ESXi 6.5 & VMware Workstation 12.x
Create a macOS/OS X VM on VMware ESXi 6.5 & VMware Workstation 12.5.2 Pro
**NOTE: This is completely for experimental purposes and is unsupported by both Apple and VMware**
Running a MacOS/ OS X virtual machine is not anything new and has been supported for quite some time, as long as you are running said VM on a supported hypervisor with Apple Hardware. But many of the “Non-Apple” users in the world would not be able to take advantage of this without owning some type of Apple Computer. Luckily, there is an alternative method for running a Mac-based VM on non-apple hardware-based VMware ESXi and/or VMware Workstation for Windows! In this tutorial, I am going to show you just how to do so. Please keep in mind that the methods described in this article are not supported nor endorsed by Apple or VMware in any way, so please use at your own risk.
Before we can begin, there are a few tools required to ensure this works flawlessly.
- macOS Sierra installation media in .iso format (You can use an older OS as well but for this demo, I will be installing macOS Sierra 10.12.3)
- This media will have to be created as the OS comes as a .app by default.
- This link has a good tutorial for creating said media.
- Unlocker Utility
- Type 1 Hypervisor (ESXi) or a Type 2 Hypervisor (VMware Workstation)
Ready? Here we go! I’ll start by showing you how to create a macOS Sierra VM on VMware Workstation 12.5.2 Pro…
VMware Workstation 12.5.2 Pro
- Make sure that VMware Workstation is installed but not running.
- Extract the contents on the Unlockler 2.0.9RC.
- Open a command prompt and navigate to the extracted folder
- Run win-install.cmd. This will patch your VMware Workstation to unlock the capabilities to run a Mac OS. It will also download the latest VMware Tools (darwin.iso) for macOS into the extracted directory.
- Launch VMware Workstation and create the shell VM
- When choosing the hardware compatibility, you can optionally change this to version 10 so that you do not need to manually edit the .vmx file after the shell has been created.
- I am going to leave it at version 12 and manually edit the .vmx file afterwards. Continue creating your shell by following along…
- Now that we have the shell created, we still need to attach the ISO to the VM. Click on the CD/DVD (SATA) option on the left side in the Devices pane. Once in the settings, select the ISO image.
- Next, navigate to the directory that houses the virtual machine’s files. Edit the .vmx file with your preferred text editor. I personally love using NotePad++. Scroll to the bottom of the text and add the following line. This will enable the VM to boot up.
- If you opted to change the hardware version to version 10 in the earlier steps, disregard this and move on to the next step.
smc.version = "0"
- At this point, the VM is ready to be powered on to install macOS Sierra. I will cover the installation steps further down in this tutorial, but first, let me cover the procedures for enabling this on ESXi. I will be showing how to do so on ESXi 6.5a (Build 48872370)
VMware ESXi 6.5a (Build 48872370)
- For ESXi we first need to copy the unlocker utility to a local or shared datastore. You can accomplish this by using vCenter, ESXi Host UI, or WinSCP. For simplicity, I opted to use WinSCP and copied the folder into a newly created “Tools” folder on a local datastore. You can also take this time to upload the .ISO to the local datastore for use later in this tutorial.
- Now that the files have been copied, open an SSH connection to your ESXi host, and navigate to the unlocker directory.
- We can then type “ls” to view the contents of the directory.
- Next, we must make the installation script executable. I also like to make the uninstallation script executable as well. Do so by running the following commands.
chmod +x esxi-install.sh chmod +x esxi-uninstall.sh
- Typing “ls” again will now display the (2) scripts in green text, indicating that they are now executable.
- Run the installer script by running the following command
- The script will only take a brief moment to run, afterward, a reboot is required. Once it has finished type
- After the ESXi host has restarted, connect to the ESXi Host UI and begin building the shell VM by following along.
- Now that the shell VM is created, we need to go back into the VM’s settings and attach the .ISO that you uploaded to the datastore in a previous step.
- At this point, the VM is ready to be powered on to install macOS Sierra! Unlike with the VMware Workstation instructions, there is no need to change the hardware version to version 10 or manually modify the .vmx file.
- In the next section, I will cover the installation steps for MacOS Sierra.
Installing macOS Sierra
**The following instructions apply to both an ESXi and Workstation built macOS VM**
- Start by powering on the virtual machine and opening the Remote Console view
- Once the VM has booted the .ISO, you will be presented with this screen. Click next and then go to the taskbar and open Disk Utility. We need to create a partition to install macOS onto.
- After the partition has been created, we can actually start the macOS installation.
- After the VM has rebooted, we can continue the installation/configuration of macOS.
- Finally, the macOS VM is ready to use! For the finishing touches, it is recommended to install VMware Tools on this VM. When we ran the installation script at the start of this procedure, it downloaded a “tools” folder inside of the unlocker tool folder and inside it contains the darwin.iso which is used to install VMware tools. This should be the latest release of VMware Tools 10.1.0. Optionally, you can always download the tools from VMware’s website.
- In order to install the VMware Tools, we first need to eject the mounted install media. Afterwards, connect the CD/DVD drive to the darwin.iso file.
- Once the VMware Tools (darwin.iso) is mounted, double-click the “Install VMware Tools” package to begin the installation. After it completes, reboot the VM for the changes to take effect.
Adjusting Screen Resolution
- By default, the macOS VM will only support (1) resolution natively, 1024 x 768.
- If you’d like to change this to support a higher resolution for say…a larger monitor, please download the following file on the macOS VM. Once the file has been downloaded to the “Downloads” folder in the VM. Open the “Terminal” application and navigate to the folder. We need to make the script executable, just as we did earlier with the unlocker scripts.
cd Downloads/VMware-Fix-resolution/ chmod +x vmware-resolutionSet
- Now we can run the script and specify the desired resolution. In this example, I am going to choose a 1440 x 900 resolution. Do so by running the following
./vmware-resolutionSet 1440 900
- On the ESXi-based VM, I did notice that it does not set a resolution higher than 1176 x 885 while in the Remote Console. But, the VMware Workstation-based VM does indeed set the desired resolution.
Disable Beam Synchronization to Improve VM Performance
- Download the following application and place it in the “Applications” folder. Double-click it to launch the application. Afterwards, add it to the user’s “Logon Option” so it runs every time at login.
I hope that you’ve found this information useful. Please do leave comments below and subscribe to my blog! Thanks for stopping by!
Achievement Unlocked! vExpert 2017!
Earlier today, I got the notification and I am honored that I’ve been awarded the VMware vExpert 2017 title! The current vExpert count is 1,472 people and this marks my 2nd consecutive year (2016-2017) that I’ve been awarded with the title. I could not be more grateful and humbled! It takes effort, passion, and dedication to elevate your personal skillset and knowledge base and I am thankful that I have had a great experience in working with VMware’s product line. I look forward to keeping this going for years to come! Congratulations to all my fellow vExperts!!
And special thanks go to VMware, Corey Romero, and the entire VMTN Community for all their efforts into making the vExpert program such a success!