In the our last couple articles a while ago, we discussed how anyone can use SSH to safely transfer files between Linux servers or how to use SSH to create tunnels between your local PC and a remote server. They're great tools and can be extremely useful, but it does require you to configure proper tunnel first. It also has the glaring limitation of being unable to access any resource outside of your server. So, with that in mind, let's talk about VPN and what it can do for us.
Many of us are already using VPN working remotely, as many companies will have the IT staff configure it for everyone. It can be configured using either hardware, like Cisco routers, or using a software solution.
The idea is to establish a secure connection to the VPN server, which will assign you an IP address from the server. After that, you can send and receive traffic through the VPN tunnel, which will require a username and password to authenticate, and act as any other network.
Password-only authentication has gotten a bit outdated, to be honest, and key-based access- along with 2-factor authentication- is more and more common today.
Let’s assume that you have a dedicated Linux server on your office and want to have secure access to the office resources from your home. So let's just go step by step through the motions:
Install OpenVPN software on your server
[root@serversuit ~]# wget http://dl.fedoraproject.org/pub/epel/6/i386/epel-release-6-8.noarch.rpm [root@serversuit ~]# rpm -Uvh epel-release-6-8.noarch.rpm [root@serversuit ~]# yum install openvpn easy-rsa -y
Create files and folders required
[root@serversuit ~]# mkdir /etc/openvpn/easy-rsa [root@serversuit ~]# mkdir /etc/openvpn/easy-rsa/keys [root@serversuit ~]# cp /usr/share/easy-rsa/2.0/* /etc/openvpn/easy-rsa [root@serversuit ~]# ln -s /etc/openvpn/easy-rsa/keys /etc/openvpn/keys
Edit ‘/etc/openvpn/easy-rsa/vars’ file based on your local environment first. Otherwise these will be the default:
# Don't leave any of these fields blank.
export KEY_COUNTRY="US" export KEY_PROVINCE="CA" export KEY_CITY="SanFrancisco" export KEY_ORG="Fort-Funston" export KEY_EMAILfirstname.lastname@example.org export KEY_OU="MyOrganizationalUnit"
Create CA, server, and client certificates
[root@serversuit ~]# cd /etc/openvpn/easy-rsa [root@serversuit ~]# source ./vars [root@serversuit ~]# ./clean-all [root@serversuit ~]# ./build-ca [root@serversuit ~]# ./build-key-server server [root@serversuit ~]# ./build-key client [root@serversuit ~]# ./build-dh
You should be able to see your newly created keys here in the ‘/etc/openvpn/keys’ directory:
[root@serversuit ~]# ls /etc/openvpn/keys 01.pem ca.crt client.crt client.key server.crt server.key 02.pem ca.key client.csr dh2048.pem server.csr
Create OpenVPN server configuration file
Edit ‘/etc/openvpn/server.conf’ file with the following data:
server 172.16.0.0 255.255.255.0
keepalive 5 30
status openvpn-status.log 3
script-security 3 system
Allow IP forwarding and make some other configuration changes
Assuming in your office network so we have two options here.
You need to ensure that your office network devices ‘know’ where to route traffic for your VPN subnet 172.16.0.0/24. So you can either create a route to your default gateway in the office, or you can masquerade the traffic from the VPN client(s), which will be easier anyway:
[root@serversuit ~]# iptables -t nat -A POSTROUTING -s 172.16.0.0/24 -o eth0 -j MASQUERADE [root@serversuit ~]# service iptables save [root@serversuit ~]# chkconfig openvpn on [root@serversuit ~]# service openvpn start
Then edit ‘/etc/sysctl.conf’:
net.ipv4.ip_forward = 1
This will set it up so your server can act as a router, sending and receiving the traffic between your office and VPN subnets.
So right now you should have the working OpenVPN server instance ready to connect!
Now you just have to install the OpenVPN client to your home, or whatever local, computer.
Note: you may also need to configure your office router to forward UDP port 1194 to your server local IP address if it didn’t have its own public IP address!
Let me provide a ready, OpenVPN config, file for you that you can save to the ‘C:\Program Files\OpenVPN\config’ directory:
remote <your_server_public_ip_address> 1194
You’ll need to copy the following files from your server ‘/etc/openvpn/keys’ directory: ca.crt, client.crt, client.key.
Note: keep your client.key file secret!
Last thing you need is to add a route to your office network so your computer can know where to send requests. Run the following command from your Windows command prompt with the administrator privileges (substitute your real office network address and mask instead):
route add 10.1.40.0 mask 255.255.255.0 172.16.0.1 metric 1 -p
Finally, you can launch the OpenVPN GUI application and connect to your VPN server.
What happens when you try to connect to your office computer?
Your local PC will look for the route table and send traffic to remote VPN gateway
VPN server will look for source and destination IPs and will masquerade the connection. It means the server will replace your real local IP address to his own, so your office computers will see the VPN server address instead of your real one. It’s not really a security issue, but it is necessary until you have a proper route from your office gateway to your home network.
The server will send your request, receive the response and send it back to you through encrypted VPN connection.
It's all good from here!
Some things to keep in mind:
Keep your keys secret. If you compromise your keys, you need to revoke them on the server so no one could connect to it using them.
Always use VPN when you need to work remotely. We covered OpenVPN in this artcle, but there are many other VPN services, free and paid, available out there.
You may need to use your office DNS servers. If you use Active Directory, or your local DNS servers, you may need to change your DNS servers at home to use office resources first.
While using VPN to securely work from home is pretty common these days, there are many other practical application for VPN that we'll be covering in our upcoming articles, so stay tuned for more from ServerSuit!
Until next time!
This article was originally published in June 2016