General: Should I use VPN to secure my connection?

Out of the box, your Opengear secures connections to its Web UI using HTTPS and its CLI using SSH.  For most applications, this level of security is sufficient.  In more demanding environments, your Opengear also embeds full OpenVPN and IPsec VPN client/server stacks and also a PPTP VPN server. 

The article contains some best practices and recommendations as to when and how VPN can be beneficial.  These are general recommendations and should be considered in conjunction with corporate security policy, security team advice and the individual characteristics of your network and use patterns.

Pros and cons of VPN

Some benefits of using Opengear’s built-in VPN support are:

VPN secures the entire network channel, giving you a single secure point of entry 

• Adds an additional layer of authentication and encryption
• Allows you to restrict inbound Service Access policies to VPN only – fewer listening services means fewer attack vectors
• Allow you to completely disable inbound access, with the Opengear establishing the outbound VPN – no listening public services

VPN is authenticated by strong pre-shared secrets, certificates or keypairs rather than username/passwords 

• Username/password access means one stolen or weak password can result in compromise 

VPN gives you secure routed access between networks not just remote access to Opengear services

• Allows you to use Opengear as a VPN router to connect multiple LANs, or a single client to the Opengear’s LAN subnet
• Opengear can maintain access to remote AAA server on your central private network during failover onto public network
• Allows you to access network devices on the Opengear’s LAN subnet using local client software, without having to set up with SSH port forwards (i.e. obviates the need for SDT Connector)

IPsec and OpenVPN perform better than SSH tunnels for access to network services behind the Opengear

• Of potential benefit in the scenarios in the previous point
• Of marginal benefit for straightforward out-of-band console management 

The downsides of VPN are that it is more complex to setup than SSH/HTTPS, and will have some data overheads which you will want to measure and account for e.g. on a cellular connection that’s billed per KB or MB.

When to use VPN

From a security perspective, whether or not to use VPN starts by assessing the risk of your connection being compromised and the consequences of a compromise.  The former is largely determined by two factors:

1. Is the Opengear directly accessible from the public WAN? (extent of exposure)
2. Is the Opengear permanently accessible from the public WAN, or during failover scenarios only? (duration of exposure)

Depending on your answers to these questions, we can make the following recommendations:

1. Yes, 2. Yes – Always-on public IP  

• Favour VPN – inbound is good, outbound is better
• Disable direct SSH and HTTPS from the public WAN interface(s) under Service Access to mandate remote access over VPN
• Use Firewall Rules to lock down remote access to trusted source networks
• If VPN is not an option, SSH with key-based auth (avoid passwords) is an acceptable compromise
• If key-based auth is not an option, see the note on username/password access under “Implementation notes”

1. Yes, 2. No – Failover to a public IP

• Favour VPN or SSH (prefer key-based auth, avoid passwords)
• Consider Firewall Rules to lock down remote access to trusted source networks
• Direct SSH/HTTPS is typically acceptable, see the note on username/password access under “Implementation notes”
• Use outbound VPN where you need to maintain routed access to your private central network during failover (VPN can be started and stopped by Auto-Response at failover/fail forward)

1. No, 2. Yes or No – Always-on or failover private (carrier NAT) IP

• Direct SSH/HTTPS is typically acceptable
• Use outbound VPN/SSH Call Home for convenience where you need to “break out” of a NATed network 

Implementation notes 

For “road warrior” connections, prefer OpenVPN

• A road warrior is single client PC connection that may have a dynamic IP (e.g. operator laptop connected via airport Wi-Fi)
• OpenVPN is typically the best option as client support is very good (e.g. OpenVPN for Windows, Tunnelblick for OS X) and OpenVPN offers strong security
• PPTP may be an acceptable compromise as client support is built into major operating systems including OS X and Windows, however PPTP has known security limitations including a relatively weak username/password authentication mechanism

For network-to-network tunnels, prefer IPsec

• IPsec offers strong security but can be complex to setup
• IPsec is highly interoperable with many other vendor’s equipment including Cisco and Checkpoint – where possible test tunnel stability over a few days as conflicting rekeying timeouts can cause issues

For direct SSH over a public network, prefer key-based authentication

• SSH key-based authentication uses asymmetrical public/private keypairs rather than passwords
• SSH keys are much longer and more complex that passwords and computationally unfeasible to guess
• The private part of the keypair is never sent over the network so even if the SSH server is compromised the key is still secure and cannot be used to compromise other systems – however the private key must be kept secure of the client system, e.g. by the use of a password to decrypt it
• For each user, upload their public key under Users & Groups -> Edit -> SSH Authorized Keys, check Disable Password Authentication and Apply
• Direct HTTPS access is always authenticated using passwords, disable HTTPS on the public WAN interface(s) under Service Access to mandate access via SSH port redirection

When using SSH with interactive password authentication over a public network 

• Use remote AAA where possible for central accounting and password management
• Avoid the use of shared “break glass” passwords, e.g. root credentials
• Set strong passwords
• Enable Brute Force Protection

When using HTTPS with interactive password authentication over a public network

• HTTPS is always authenticated by username/password (and optionally RSA SecurID via RADIUS AAA)
• Consider Auto-Response WebUI Authentication Event alerts