VPN Technologies: Remote Access Security

This article is educational content about VPN technologies and remote access security. It is not professional guidance for VPN deployment, security architecture, or a substitute for consulting a qualified security engineer.

VPNs come up in almost every conversation about remote access security. Your employees ask about them, your MSP recommends them, your security team debates whether they're still necessary. Yet many organizations struggle with the basics: what problem a VPN actually solves, what you should expect it to do, and whether it's the right approach for your situation. A VPN creates an encrypted tunnel from your computer to your organization's network, making it safe to work from anywhere. But "safe enough" is the real question, and the answer depends on what you're doing with that access and what threats you're actually protecting against.

Connecting Offices: Site-to-Site VPN

Site-to-site VPN creates a permanent encrypted tunnel between two networks, typically between your main office and branch offices. Instead of paying for expensive dedicated links between locations, you can use the regular internet with a VPN tunnel protecting the traffic. The VPN gateway at the main office connects to a gateway at the branch office, and all traffic between the sites is encrypted and protected.

Site-to-site VPNs are rock-solid for branch connectivity because they're always-on, automated, and require minimal user intervention. The traffic moving between sites doesn't involve user decisions about security. Once you set up the tunnel, it just works. The downside is that site-to-site VPNs move significant amounts of traffic continuously, and they require decent connectivity on both ends. If your branch internet connection is poor or unstable, the tunnel performance suffers. But site-to-site VPNs have matured into commodity technology. They work reliably, are relatively inexpensive, and are usually the right choice when you have multiple office locations that need to share network resources.

Remote Access from Anywhere

Remote access VPN is different. It lets individual users connect from anywhere—home, coffee shop, airport—and get access to your network as if they were in the office. This requires the user to run VPN client software on their device, initiate the connection, and authenticate. Once connected, their device is treated as if it's on your office network.

This was the standard approach for remote work for decades, and it still works. Remote access VPNs have an advantage: they're simple conceptually. You connect to the VPN, you're on the network, you can access what you need. But they create friction. Users have to remember to connect, have to manage client software, have to troubleshoot connectivity issues. More importantly, remote access VPNs have a critical security weakness: the device doing the connecting is only as secure as the user's home network and their device's own security. If the user's home Wi-Fi is compromised or their laptop is infected with malware, that malware gets VPN access to your network. This is why modern security thinking has shifted toward zero trust approaches that don't trust the device but instead verify every access request separately.

How VPNs Encrypt: Protocols and Standards

A VPN uses encryption protocols to protect traffic. Common protocols include IPSec (used in site-to-site VPNs), SSL/TLS (used in remote access VPNs), and newer protocols like WireGuard. Each makes different trade-offs between security, performance, and ease of use. IPSec is mature and widely deployed but more complex to configure. SSL/TLS is simpler and more flexible but typically slower. WireGuard is newer, simpler, and faster but less battle-tested in enterprise deployments.

What matters for your organization: your VPN should use modern encryption standards. AES-256 for symmetric encryption and TLS 1.2 or 1.3 for key exchange are the baseline. You should not be using old protocols like PPTP or early versions of SSL/TLS that have known weaknesses. If you're running an old VPN deployment, that's often a good reason to upgrade, not just for performance but for security. Auditing your VPN configuration means checking that the protocol and encryption standards are current.

The VPN Concentrator and Scaling Issues

A VPN concentrator is the hardware or software that terminates VPN connections from remote users. It handles authentication, encrypts and decrypts traffic, and enforces policies for what connected users can access. A typical concentrator might handle 100 to 1,000 concurrent connections, and performance degrades as load increases.

This became a real problem when organizations suddenly needed to support thousands of home workers. Many organizations discovered during the pandemic that their VPN concentrators couldn't scale to the demand. This is why many moved away from traditional VPNs during the shift to remote work—concentrators became bottlenecks. Modern alternatives like zero trust gateways can scale more easily through cloud infrastructure.

If you're evaluating VPN capacity, understand your peak concurrent users. How many people are actually connecting at the same time, not how many people work remotely. These are different numbers. You might have 500 remote employees but only 200 of them connecting simultaneously.

Kill Switches and Connection Loss

A kill switch is a feature that blocks all internet traffic if the VPN connection drops. Without a kill switch, if your VPN connection fails, your user's traffic routes directly to the internet outside the VPN, potentially exposing sensitive data. The user might not even realize they're no longer protected. With a kill switch, if the VPN fails, the user gets no internet access until they reconnect. This forces them to deal with the problem rather than unknowingly working outside your security perimeter.

A kill switch is not optional for remote access VPN—it's a requirement. If you don't have it, users can get direct internet access without your knowledge, completely bypassing your security controls. Most modern VPN clients include kill switch capability, but you should verify it's enabled and actually test that it works. A kill switch that doesn't work is no protection at all.

Split Tunneling: The Security Trade-Off

Split tunneling means the user's traffic splits: some traffic goes through the VPN to your network, other traffic goes directly to the internet. A remote user might send work email through the VPN but send personal traffic like streaming video directly to the internet. This improves performance by not routing everything through your VPN infrastructure, which saves bandwidth and reduces latency for non-work traffic.

But split tunneling creates security problems. Any traffic not going through the VPN bypasses your security monitoring and is exposed. If the user is on an infected home network or public Wi-Fi, non-VPN traffic can be intercepted. For security, you generally want to prevent split tunneling. All traffic should go through the VPN when the user is working. You can make exceptions for specific high-traffic scenarios—video conferencing might reasonably bypass the VPN if it's causing performance issues—but most traffic should be tunneled.

Enforcing no split tunneling requires client-side policy enforcement or network-level detection that your VPN software is actually encrypting all traffic. This adds complexity but protects the organization.

Authentication and Multi-Factor Authentication

VPN authentication verifies that the person trying to connect is actually an authorized user. Username and password is the traditional approach, but password alone is weak. If an attacker has stolen a user's password, they can connect to your VPN even though the user isn't at their computer.

Multi-factor authentication for VPN access requires something in addition to a password. This might be a code from an authenticator app, a push notification to a phone, or a hardware token. VPN MFA is increasingly required by compliance frameworks and is a best practice regardless of compliance. If your VPN doesn't support MFA, that's a strong reason to upgrade.

VPN authentication should also validate the device trying to connect. Not just the user but the specific device. Is it a managed corporate device? Does it have encryption enabled? Has it been patched recently? This is part of zero trust approaches: verify the user, verify the device, verify it's compliant with security policies before granting access.

The Evolution: From VPN to Zero Trust

Zero Trust is a security model that fundamentally doesn't trust the network. Instead of saying "if you're on the VPN you're trusted," zero trust says "we verify every access request, every user, every device, every time, regardless of where you're connecting from."

Zero trust gateways replace VPN by authenticating each application access individually rather than granting blanket network access. Instead of connecting to a VPN and then accessing everything you have permission to access, you authenticate and connect only to the specific application you need. This is more secure because an attacker who compromises one application can't automatically pivot to others.

Zero trust is more complex to implement than VPN and requires application awareness, but many organizations are moving in this direction because it's more secure than VPN alone. If you're deploying remote access, understand whether you want traditional VPN (simple but less secure) or zero trust architecture (more complex but more secure). Many organizations will do both—VPN for broad network access and zero trust for sensitive applications.

Making the VPN Decision

VPNs are a foundational remote access technology that have been reliable for decades. Site-to-site VPNs remain the standard for branch connectivity. Remote access VPNs work for smaller organizations and specific use cases. But VPNs are not the final answer to remote access security. They're one tool, and modern security thinking pushes toward zero trust approaches that verify each access rather than trusting everyone on the VPN.

If you're managing a VPN deployment, ensure it uses modern encryption protocols, enforce MFA on all connections, and implement kill switch. If you're designing new remote access, consider whether zero trust alternatives better match your security requirements. The key is understanding what each approach protects against and what threats it doesn't address. A VPN protects traffic in transit but doesn't protect the device itself. A compromised device on a VPN is still compromised. Understanding those limitations helps you build a more comprehensive remote access strategy.

Fully Compliance provides educational content about IT infrastructure and cybersecurity. This article reflects general information about VPN technologies and remote access security as of its publication date. For security architecture decisions specific to your organization, consult a qualified security engineer.