Having access to your devices over the Internet is a requirement for any admin deploying a project. Instead of running to a remote site to administer devices (making changes, applying updates and patches), it’s easier to connect remotely and make changes. Remote access poses many issues and concerns.

Security

First and foremost is security. You always, always, ALWAYS want devices connected to the Internet behind a router with a built-in firewall (NAT router). A firewall filters traffic between two networks (your ISP and home for example) and will block attempts to connect to your internal (private) network.

Device manufacturers take security for granted. Little testing and auditing takes place because the analysis is expensive for throw-away devices. This is noted in many stories including Bug Exposes IP Cameras, Baby Monitors where simply clicking “OK” on the login dialog allowed access to the Internet connected video camera. It is trivial to find these devices on the Internet because of Shodan. Shodan is dubbed the “Internet of Things Search Engine.” If you’re not familiar, think of it as the Google for devices connected directly to the internet. These could be: web servers, printers, cameras, industrial machines, bitcoin mining… Putting devices behind a firewall minimizes the risk because anything trying to peer into the network would be blocked by the firewall.

This holds true for networks you don’t control (granted access on someone else’s network). Put your stuff behind a router/firewall so they can’t see your devices and you can’t be exploited by devices on the other network.

Port Forwarding is a popular technique to only allow traffic on a specific port to a device you specify in your firewall (router). This provides little security as it still allows a potentially vulnerable service to accept incoming connections from the Internet.

Choose a good router

Couple of tips for a good router:

• You get what you pay for. Don’t opt for cheap.
• Opt for ones that support third-party firmware like DD-WRT and Tomato or setup a dedicated computer running pfsense or Untangle. These have proven to be more secure than stock firmware in addition to offering a more complete feature set.
• Stick with popular models as found on Amazon, Newegg, or other tech store. They’re more likely to be reliable, well updated models.
• Look for ones that accept USB cellular modem dongles for installations that have no accessible network connection like a remote site.

Virtual Private Network

The preferred way to connect to a remote network is to use a VPN. A VPN connects to a private network securely over the Internet. It allows the user to exchange data, use services, and connect to devices as if they were directly connected to that network. An open-source project that implements VPN technologies security is OpenVPN. OpenVPN is an application that allows for secure point-to-point communication. There are many implementations of OpenVPN including using it in many third-party router firmware (mentioned above). OpenVPN Access Server is one of the many implementations and the one used for this project.

This project was inspired by Hak5 1921 – Access Internal Networks with Reverse VPN Connections. As an Amateur Radio operator into the newer computer and digital technologies, more devices are located at remote sites.

This setup consists of:

1. A remote network behind a firewall where devices exist you want to access. This will be a Linux server on the remote network that will act as the gateway and persistently connected to the bridge. This could be a full desktop computer purposed for something else or Raspberry Pi. Also on the same network will be a Windows machine.
2. An unsecure/unknown network, AKA the Internet.
3. A private server that will act as the bridge between the remote network and a device you choose.
4. A device in a separate location that will connect to the cloud server and will be able to access the remote network. I will use a Windows machine to act as a ‘home’ computer.

This setup works in nearly all cases because the only device receiving incoming connections is the bridge server in the cloud. Firewalls block incoming connections by default. Very few block connections originating inside the network out to the Internet (egress). If a device along the way filters by content, connection attempts will be blocked. Many corporate networks are doing this kind of filtering. Otherwise the traffic looks the same as secure web traffic on port 443. No port forwarding is used.

Hosting

I recommend using an infrastructure hosting provider for the bridge server. This can cost anywhere from $5-$15 per month. The device can be anywhere on the public Internet. It must accept multiple connections on different ports but only by a couple users at a time are needed. Minimal configuration is more than sufficient. Bandwidth, latency, and up-time of all points in this setup effect reliability. My personal recommendations for infrastructure hosting providers are: Rackspace and DigitalOcean.

IP addressing

All remote networks and the home user networks cannot overlap in address space. That is they need to be differently numbered. For example, typically home networks have addressing as 192.168.1.x. The remote site(s) can’t have the same numbering (192.168.1.x). It must be different. I suggest making the remote site different enough to not cause conflict with any home users’ networks. Remote sites as 192.168.25.x, 192.168.26.x, and 192.168.27.x would work fine when the home users’ networks is addressed 192.168.0.x, 192.168.1.x, 192.168.2.x, and so on (except 25-27). Similarly addressed networks create routing conflicts and the packets will not reach the correct network.

Downsides

Cost.

In addition to hosting, a downside to using OpenVPN Access Server is licensing. While OpenVPN is Open-Source Software and OpenVPN Access Server is free, the license allows for only two concurrent tunnel connections at any one time. This means the remote site counts as one connection and the home device the second. If a second person (third device) needed access to the remote network, they would get a message saying ‘Access Server has reached its concurrent connections limit.’ The first person would need to disconnect first before the second could connect otherwise current connections will begin to be booted. Additionally, connecting two or more remote sites and a home user is not possible without purchasing licenses or running an additional bridge server. Additional licenses can be purchased for “$9.60 License Fee Per Client Connection Per Year. Support & Updates included. 10 Client minimum purchase.” $96 per year.

An alternative to OpenVPN Access Server is to setup your own (roll your own) OpenVPN server which is free. I hope to do an OVPN server setup at some point in the future.

Assumptions

This guide is step-by-step in nature, meant for beginners, with brief explanations of the steps. It will help to have an understanding of Linux commands and scripting. Capitalization is important in Linux! Understanding of basic networking concepts including determining network prefixes and CIDR notation is also required.

Program versions

I used a Windows 7 64 bit PC for configuration (and Home PC). Applications and versions used in this writeup:

• OpenVPN Access Server 2.0.24
• Putty 0.67
• Ubuntu 14.04 x64 (bridge and remote servers)
• Filezilla 3.16.0