After getting the connection running I decided that I wanted to try a lower cost alternative, a software connection between an instance I’d deploy in a VPC and my existing physical network. I don’t require the extra bandwidth or higher availability that the AWS hardware VPN connection affords out of the box.
While the IPSec connection I had configured was working well in general, there was one problem I struggled to solve. I use OpenVPN to permit remote access to my network. The Untangle OpenVPN module makes using OpenVPN for the so-called “road warrior” scenario very easy.
I found that OpenVPN clients were unable to traverse the IPSec tunnel to connect with hosts on the remote end of the network. I believe that this was nothing more than a routing or firewall problem between the relevant networks, however, it was one I struggled to solve.
My limited review of IPSec vs. OpenVPN discussions left me with the sense that OpenVPN is considered more secure and, at least by some, more efficient than IPSec, whereas IPSec is more established and better supported, generally speaking.
Several people had told me that it would be challenging to implement an OpenVPN site-to-site connection between the Untangle firewall and some other OpenVPN implementation. As I thought about how easy it was to implement the OpenVPN point-to-site connections it occurred to me that a network-to-network connection shouldn’t be that tough. After all, a point-to-site connection can become a site-to-site connection with not much more than the addition of a static route on one side.
I assumed that if I could limit myself to the Untangle OpenVPN module on the physical network I’d stand a better chance at having my remote clients being able to traverse the tunnel to get to the other side of the site-to-site connection. As for the AWS side I considered extending one of the special purpose AWS Linux NAT instances by adding an OpenVPN client or by using OpenVPN already included as part of a VyOS instance. As I describe here, I recently chose to deploy a VyOS instance to provide NAT between the public and private subnets that reside in my VPC. Unfortunately, the documentation for VyOS is somewhat lacking and I struggled to find the kind of reference material that made me confident I’d configure the VyOS OpenVPN components properly without undue difficulty. For that reason, I elected to deploy an Amazon Linux NAT instance for the OpenVPN client.
I could have deployed a full OpenVPN server in the VPC but since I already had a perfectly good OpenVPN server running on the Untangle firewall I didn’t see a need to deploy yet another server. I chose the AWS NAT instance because I knew it was already slimmed down to provide nothing more than NAT, which meant that port forwarding and the few other things you’d like to see in a firewall/router were already in place. I’d only need to add the OpenVPN client. It wouldn’t have been too difficult to start from virtually any standard linux distribution.
Step 1 – Create A Remote Network Entry in the Untangle OpenVPN Module
The first task is to create a remote network client entry in the Untangle OpenVPN module. (I assume that you have a working knowledge of the Untangle firewall and that you are also familiar with the OpenVPN module and how to use it to create a connection with a remote host or mobile device. If you aren’t there are ample descriptions available.)
Go to the Untangle OpenVPN module Server tab and, if you’ve not already done so, enter a site name for your VPN.
Check the box to enable the server.
The OpenVPN server allocates addresses in its own space that’s separate from your other network spaces. Make sure that the address space indicated in the box doesn’t conflict with an address space you are using.
You will also need to decide if you want to NAT the LAN-bound OpenVPN traffic to a local address. Your implementation will be simpler if you check the box.
Here’s what that tab looks like on my system after having added the entry for the AWS-VPC.
Click the “Done” button and then the “Apply” button. Click on the “Download Client” button for the client you just created. The system will generate a few files that you can use depending on what you will be using to connect to the Untangle server. In this case, you should select the link to download the configuration zip file for other OSs.
Hang on to the zip file. You will need it to configure the OpenVPN client.
Step 2 – Export Networks
The next task is to identify the networks that your OpenVPN clients should be able to access. In my case, I’ve got the local LAN attached to the Untangle appliance, the AWS VPC LAN, and the LAN that consists of the various other remote clients that may be connected to the OpenVPN server at any given time. Set up your list of exported networks accordingly and click the Apply button.
Step 3 – Deploy the Linux Instance and Add the OpenVPN Client
Deploy a linux instance into your VPC in any way that suits you.
I chose one of the special purpose linux NAT instances supplied by Amazon. By doing so I knew that I was getting an instance with port forwarding enabled, which is important. The instructions for deploying a NAT instance are found here. Do not forget to disable source/destination checking as described in those instructions.
You will want the instance to have a public IP address so make sure to assign an Elastic IP too.
Update the instance software and install the openvpn client with the following commands:
$ sudo yum update
$ sudo yum upgrade
$ sudo yum install openvpn
Step 4 – Extract and Place the Configuration Files
Use your favorite zip file extraction tool to extract the files in that zip file you got from the Untangle OpenVPN server and copy them to the /etc/openvpn directory in the instance you created on AWS.
When you are done, the directory should look something like this (with the file names reflecting whatever you named the client).
Step 5 – Modify VPC Route Tables
Add static routes on your private AWS subnet to route traffic for the remote networks through your VPN tunnel. In my case, I added routes pertaining to the my local LAN and the OpenVPN client subnet.
Step 6 – Start OpenVPN
The standard openvpn distribution file includes scripts to start, stop and reload the openvpn service.
In the following screen capture you see that initially openvpn is not running and that accordingly there are no tunnel devices, then, we use the openvpn start command to initiate the openvpn client at which time a tunnel device (tun0) is created.
Once you get to this point you should be able to ping from hosts on the two private networks that you have now connected.
Step 7 – Start The Remote Client Automatically
Use the chkconfig command to cause the openvpn client to start whenever you boot the AWS instance.
Please let me know if you find any mistakes in this posting. If you do, drop me a line and I will update the description.
No comments:
Post a Comment