There are several encrypted ways to access a network remotely, as well as several ways to manage the network itself.

Encrypted Access

We use two primary ways to get a device onto a remote network in a way that seems, to the device, that it’s locally available.

The first of these is through a client-side VPN (Virtual Private Network) application. In our setup, this application features a login username and password and optionally a two-factor authentication method. This account is setup on the remote location’s firewall (either through local accounts setup on the firewall, OR via an LDAP connection to a domain controller handling accounts). After authentication, the client PC is assigned an IP from a dedicated range set aside for SSL-VPN connections. Traffic from that IP block to the rest of the network is controlled via firewall policies. This allows the client machine working remotely to interact with the local network seamlessly (from the client perspective) while the firewall handles the actual routing.

There are two ways to handle the traffic over the client-side VPN – split or full tunneling. In split tunneling, ONLY the traffic that must be routed to the network – file shares, authentication, and so on – actually travels over the tunnel. In full tunnels, ALL traffic flows over the tunnel. While this does increase network traffic over the tunnel itself (which can reduce network throughput), for security reasons it can be advantageous to have all network traffic flowing through a secure tunnel to a remote location which reduces tracking and monitoring on the client side.

The second method to connect networks is via site-to-site VPN. In this setup, instead of individual devices connecting to the remote location via a device-side application, the two firewalls themselves are connected using native features (in our case, encrypted IPSec tunnels). The firewalls on each end handle the routing of traffic via subnets, and again the devices don’t see it as separate networks. In this setup, ONLY the traffic that must flow to the other network does so, the rest is handled by routes on the local network. The advantage with this setup is that individual devices don’t require any extra applications or work for the users. The downside is that, without deliberate security applied, any device on the network can reach the remote network as well if it attempts to do so.

Network management connections

We use three methods to manage our networks, although two function in practice very similarly.

The first is the GUI – the Graphical User Interface. The GUI is a manufacturer-provided visual system for making changes as needed. It’s a webpage hosted on the device itself that allows most network changes to be made, and while easiest for beginners since the information is laid out fairly intuitively, exposing ALL features would make it overwhelming, so more advanced features aren’t, by default, visible on the GUI.

The second method is via the Console – this is a text-based management method using a manufacturer-provided domain language to code the devices themselves. While it exposes all features, it does require learning the command line code to take full advantage of it. The console is only available when logged into the device itself.

The third method we use is SSH – this is also a text-based connection method, detailed in an earlier post. Once connected, the Console (method 2 above) is exposed to a remote connection and can be programmed as normal.

I’ve come to prefer the console, as it allows a lot more automation than the GUI. Since all GUI methods involve mouse moves and clicking, it’s harder to automate. With the console/SSH connection, programming and reconfiguring can be done via copy/pasting of commands which has allowed me to drastically speed up network device configuration (from hours to minutes).