Stay up to date with Pomerium news and announcements.
Virtual Private Networks (VPNs) have been around for decades, providing secure connections between remote locations and enabling remote workers to access company resources. NextGen VPNs, such as StrongDM, Tailscale, and Twingate offer streamlined experiences and advanced features that organizations not only use but also adore.
However, even NextGen VPNs (or any tunneling solution, really) are not able to escape the fundamental problems plaguing VPN design: at the end of the day, they're still just TCP tunnels running on layer 4 with NAT magic.
There’s two major design flaws inherent to tunneling tools:
Tunneling tools exist to bypass network perimeters, which are no longer defendable
Even if network perimeters could be defended, see the previous point
We previously wrote in-depth about the Perimeter Problem, but here’s a quick summary in NIST’s words:
"It is no longer feasible to simply enforce access controls at the perimeter of the enterprise environment and assume that all subjects (e.g., end users, applications, and other non-human entities that request information from resources) within it can be trusted.”
Organizations relying on NextGen VPNs are exposed to the Perimeter Problem: trying to enforce access controls at the perimeter. Unfortunately, the concept of the perimeter is meaningless in the modern age of multi-cloud, hybrid on-prem network infrastructures with mergers and acquisitions. Defining a network perimeter and then enforcing access controls is not feasible without a tremendous amount of resources requiring constant maintenance and upkeep.
And then there’s tunneling. Assuming you have unlimited resources to set up a flawlessly impenetrable network perimeter, you then set up a NextGen VPN to… tunnel right through and bypass the access controls you’ve invested in. A tunnel brings the user straight into the network ecosystem giving access to everything within.
This is a self-defeating (self-exposing?) paradox. Setting up your own tunneling solutions is the fastest way to compromise your own perimeter and expose yourself to a breach. This isn’t conjecture; VPNs are a common access point and the Cybersecurity and Infrastructure Security Agency (CISA) wants to remind everyone that VPN “vulnerabilities are being found and targeted by malicious cyber actors.”
NIST proposes a solution:
“Access controls can be enforced on an individual resource basis, so an attacker who has access to one resource won’t be able to use it as a springboard for reaching other resources.”
Instead of building a perimeter and then tunneling in, enforce access controls on an individual resource-basis with a context-aware proxy. Shifting away from the concept of a perimeter improves operational agility and gives each asset itself the capability to approve or deny requests. This has the additional benefit of limiting lateral movement to a degree perimeter-based defense systems cannot.
Layer 4 vs. Layer 7 Network Differences
Layer 4 Tunneling is Agnostic to Layer 7 Data
Data Agnosticism Means An Inability to Act
The Importance of Identity, State, and Context
Next, we need to delve into the OSI model, a conceptual framework that defines how different network protocols and technologies interact. For those who don’t know, the Open Systems Interconnection (OSI) model is a conceptual framework that describes how data moves between devices on a network. It is divided into seven layers, each responsible for a specific set of functions.
NextGen VPNs and tunnel-driven solutions primarily operate at Layer 4 of the OSI model, also known as the transport layer. These solutions focus on creating secure tunnels for data transmission, ensuring confidentiality and integrity during the transfer. While they excel at securing network connections, they lack the ability to inspect or understand the application-layer (Layer 7) traffic that flows within these tunnels.
On the other hand, IAPs and CAPs operate at Layer 7, the application layer. These solutions are able to analyze and understand the content, context, and intent of the traffic passing through. This higher level of visibility empowers these proxies to enforce policies based on user identity, application, content type, and other contextual factors.
Layer 4 Traffic (NextGen VPNs)
Layer 7 Traffic (IAP, CAP)
Tunnel (TCP, RDP)
HTTP (Web, browser)
Speedy, Reliable, Efficient
Intelligent, Secure, More Control
Nonstop stream of data, hard to inspect
Can inspect and analyze individual data packets
Requires a Client
No Client required
Layer 4 tunneling tools should be used for Layer 4 traffic. We are explicitly drawing a line against using Layer 4 tunneling for Layer 7 traffic because it is agnostic to layer 7 data. Layer 4 tunneling tools should be used for Layer 4 traffic.
Data Agnosticism Means An Inability to Act
While there is nothing wrong with using Layer 4 tooling for Layer 4 traffic, this has major ramifications for observability and security at Layer 7 where most user-facing internet actually happens. While it’s possible for Layer 4 tools to understand the streams of layer 7 data with deep packet inspection, the associated costs renders it impractical:
You must be able to inspect the data in order to know if you should prevent an action.
You must stop all traffic if you want to inspect the data or accept that all actions are not “real-time.”
The end result is that Layer 4 tunneling tools simply can’t act proactively to stop malicious HTTP requests. Just like how CCTV cameras don’t prevent a break-in, tunneling tools can only log what happened.
We cannot stress how important it is to prevent privilege abuse or hacking attempts as they are happening, as the data is being transmitted. Layer 4 tools cannot prevent this without introducing costs and latency.
In contrast, Layer 7 tools such as identity- and context-aware proxies adopt a more granular approach by verifying user identity and access rights at every action or request made by the user. This constant verification ensures that access remains appropriate and up-to-date throughout the user's session, providing a higher level of security and compliance. If an incoming data request or action makes no sense, the tool is now able to recognize that in real-time, make a policy decision, and deny the request before it gets executed.
This is why inspecting that data is important — it provides observability for the core aspects of security: identity, state, and context.
The Importance of Identity, State, and Context to Policy Enforcement
Identity, State, and Context play a vital role in determining the level of security and control that can be enforced within a network environment.
Identity — Generally the User or Device identity, this is the base minimum requirement for all access control tools. In many cases, this is the verification of user credentials, but modern systems are requiring multi-factor authentication or even passwordless authentication models.
State — Going beyond Identity is the State of that entity. Is the User or Device in good standing? Is the Device compromised and dangerous to the network?
Context — After understanding Identity and State, access controls should consider the Context of the access and request. Even if the User is verified and their account is in good standing, the circumstances surrounding their access request needs to be considered before granting access. Context-awareness is critical to preventing malicious insiders and compromised credentials, the most common vector of attack.
As detailed earlier, NextGen VPNs lack the ability to act on changes in user identity, state, or contextual factors once the session is established. Consequently, they cannot dynamically adapt their policies or revoke access based on these changes.
On the other hand, Identity-Aware Proxies excel at recognizing shifts in user identity state and contextual factors. These solutions can enforce dynamic policies based on real-time changes, allowing organizations to continuously apply more precise security measures and control access based on the specific context of each user and their actions.
Client-based Access
Tunneling tools require clients and intermediary servers
This introduces expensive bottlenecks and latencies
Tunnel-based tools must install clients everywhere by design. The server needs a client. The machine needs a client. The user needs a client. Don’t be surprised if the client needs a client.
VPN clients inhibit productivity and workflow, being a necessary obstacle when using tunneling tools. Sure, super users such as network admins and technically-proficient individuals may find it acceptable to wrangle with these clients, but non-technical individuals may not. These users are frustrated whenever:
The client needs to be installed on their newest device
The client fails or needs upgrading/updating
They misplace their credentials for this client
VPN servers fail or drop the connection, disrupting workflow
And network administrators have their ticketing systems jam-packed with:
Readjusting user access permissions
Resetting user credentials
Trying to configure, set up, or debug clients for a user (even more “enjoyable” if it’s a remote user)
Web users should be served by the browser, not be forced to use tunneling clients. And then there’s latency.
It’s not just clients, but the fact that VPNs require an intermediary server to run. This increases latency as data must travel further than usual, resulting in slower connections and limited concurrent users on a finite bandwidth. Tunneling and VPN services are happy to charge you for that bandwidth despite the fact it introduces a natural bottleneck on growth and productivity.
This is another reason why companies use IAP tools that can be deployed directly where the service is; there’s no latency, no increased bandwidth costs, and no productivity loss.
Transitioning to Layer 7 Tools
Most companies understand that there is a cost of transition, and it’s not an easy task to deploy and configure an IAP solution for each service rather than set up one tunneling server. Luckily, IAP solutions and tunneling tools can work in conjunction to ease the adoption process, allowing organizations to transition away from NextGen VPNs. The result will be:
Easier because you don’t have to maintain a client or software.
Faster by deploying directly where your apps and services are. No more expensive data backhauling.
Safer because every single action is verified for trusted identity, device, and context.
