A VPN may not be the perfect solution for an organisation's security problems, but it can certainly be a good start. However, a poorly managed VPN can also be a flawed open window that cuts through even the most well-constructed security architecture.

VPNs are a legitimate network security control which can be used to enforce network segregation, traffic encryption, and QoS while abstracting network complexity away from users. Problematically they can also be used for degrading an otherwise punchy security stack, hiding traffic from inspection and monitoring, and reduce defence-in-depth to a single layer. Network issues become more difficult to diagnose and they can negate any kind of authentication process that is in place to restrict access to an organisation's IT infrastructure.

ARCHITECTURAL VARIANCE
VPNs are available in a few basic architectures, each solving a different problem. Personal VPNs are typically the kind that you purchase online and install via an app onto your phone, computer or home router. They secure access from your device to the provider's infrastructure, applying protection when passing local wireless networks, your ISP and, potentially, monitoring applied at nation state borders.

You place your trust in the ability and ethics of the provider, who deliver minimal corporate protection. Others, like Client-to-site VPNs, typically route client traffic to a VPN concentrator, firewall or remote access server inside a corporate network. They provide all the benefits of a Personal VPN, whilst forcing some or all traffic through network defences defined by the organisation before reaching either the internet or internal systems. They can be a particularly useful way to apply network protection and constraints for remote workers. Lastly, site-to-site VPNs create a persistent connection between two points on a network, often between two networks managed by different organisations. In this way, Organisation X can trust that the traffic originating from Organisation Y's static IP really came from there and hasn't been interfered with or observed. Often, that's all they can trust.

A SURFEIT OF PROTOCOL
The history of VPNs is littered with protocols that make for great study during cybersecurity courses. Particularly PPTP and L2TP without the IPSEC encryption are examples of how legacy protocol or implementation decisions can hurt security in the modern world. IPSEC/IKEv2, OpenVPN and Strongswan are good modern suites with rafts of guidance on how to configure them for maximum security in detail. Be aware that some literature online is aimed at consumers and isn't designed to provide guidance or protection against concerted and capable attackers.

For maximum security in any IPSEC-based VPN, avoid aggressive mode, ensure both AH and ESP are enabled and consider disabling ISAKAMP and IKEv1 for security associations. (IKEv2 is currently fine.) Be aware of the crypto - AES-GCM, ChaCha20/Poly1305 and SHA2 based hashing that are all encouraging things to see. For OpenVPN and other TLS-based options, understand the potentially game-ending weaknesses that can exist within the underlying TLS/SSL ciphers and act accordingly. For maximum security (but potentially tricky interoperability) go for something like TLS-ECDHE-ECDSA-WITH-AES-256-GCM-SHA384. AES-256-GCM as the cipher is solid and consider Curve25519 for DH exchange instead of the more NIST-y alternatives.

STATE AND QUALITY
A further consideration is that, just as with TLS connections, a poorly managed set of expiring VPN credentials or secrets can create silent or hard-to-diagnose service outages. Proper monitoring of both the state and quality of the tunnel, as well as the health and lifespan of the keys either side is vital - or else things can go wrong without a clear cause, diagnostic route, or a path to recovery.

VPNs can be great security tools, but they should be used with great care and integrated as part of the whole security architecture of an organisation. NC