A More Flexible Zero Trust Networking Architecture

New zero trust networking option applies modern security to legacy infrastructure

Zero Trust networking solutions have been getting a lot of attention lately, bolstered by the potential of ransomware and cyber attacks being used as a proxy for war.  Trustgrid has seen a corresponding rise of interest in zero trust network access, or ZTNA, from both existing and new customers. Specifically, our customers want to understand how ZTNA can be used to solve or upgrade their current connectivity challenges as securely as possible.  

However, as we begin to peel back their connectivity requirements, it becomes clear for most that current ZTNA solutions alone cannot solve all scenarios and leaves gaps that must be solved with additional connectivity solutions or technology.  These gaps could include the use of legacy protocols or the ability to use a preferred set of application clients or tools that are not supported by existing ZTNA products.  

To address these gaps, Trustgrid has bolstered our current ZTNA solution with a new ZTNA Layer 3 bridge option. This new feature can be used to provide zero trust security in situations where current ZTNA solutions cannot adequately solve a specific connectivity requirement.

ZTNA Today

To provide some background, ZTNA products today can be broadly categorized into 2 categories – proxy-based and SDP-based.

Proxy-based (Beyond Corp)

In proxy-based ZTNA solutions application traffic is terminated and proxied by an application gateway. This gateway is responsible for verifying the user is authorized to make the request, as well as potentially injecting secondary application-specific credentials into the request.  Many of these types of offerings provide browser-based application interfaces (eg – in browser RDP or SSH), or do other networking tricks like layer 4 forwarding on the local loopback interface.  Drawbacks to this approach can include a lack of legacy or non-standard application support, as well as usability limitations with browser-based application user interfaces.


The Software-Defined Perimeter (SDP) ZTNA approach was first defined by the Cloud Security Alliance.  This approach implements a network security architecture that uses new components including SDP controllers and SDP client software, as well as new security techniques such as single packet authentication (SPA).  This ZTNA approach involves planning for and implementing an entirely new network security architecture, which obviously takes a large commitment of time and resources for an organization to fully implement.

Trustgrid ZTNA Layer 3 Bridge

While the previously discussed ZTNA approaches work well in many enterprise IT scenarios, it may not work so well in others.  For this reason, in addition to a full proxy-based ZTNA solution, Trustgrid provides what we call a ZTNA Layer 3 bridge.

A ZTNA L3 Bridge is a technology that blends ZTNA principles along with Layer 3 network tunneling for use in situations where it is necessary or desirable to do so.

Examples of such situations may include:

  1. DevOps users that have a strong preference for specific clients/tools
  2. Providing support access to legacy or proprietary systems
  3. One or more applications break when terminated/proxied (eg – app using mTLS)

At some level, it may seem counterintuitive to label an L3 tunneling solution as a ZTNA component. But we at Trustgrid feel it is a necessary component for a ZTNA architecture that can be used to address the gaps that a “pure” ZTNA solution may present.  

Since L3 access can introduce some of the very security risks that ZTNA is meant to address, we brought several zero trust principles into the configuration and access mechanism of the Layer 3 bridge. Our L3 access is accomplished securely by using the same strong authorization framework and observability features that the rest of the Trustgrid ZTNA solution uses.


After configuring a ZTNA L3 bridge in the administrative portal, authorized users can then access the bridge via the Trustgrid zero trust networking portal.  After configuring the L3 bridge with the user’s public key, the user can then select the desired bridge in the ZTNA portal.  

Upon successful login and access policy evaluation, the Trustgrid cloud relays this user’s public key and location info to the relevant Trustgrid gateway where the user can then create a VPN connection and access the specifically allowed resources for the amount of time specified in the bridge configuration.  After the session expires, the user must reauthenticate to reestablish the session.

Trustgrid ZTNA Architecture

Identity-based Access Policy

Each L3 bridge contains an access policy that defines which users and locations can access a particular bridge. When configuring an L3 bridge access policy, the user specifies which Identify Provider (IdP) bridge users should be authenticated against, as well as user and or group-based rules defining who should have access to the bridge.  

Other user context information such as IP addresses or geographical (eg – country) may be used in policy rules as required or exception-based criteria.  An implicit ‘deny’ is applied to all users and traffic not matching the bridge access policy.

Trustgrid Zero Trust Networking Access Policies

Micro Segmented Resource Access

Trustgrid ZTNA L3 bridges are intent-focused in that each one is defined with a specific set of activities in mind.  For instance, a bridge may be configured to allow HTTP access to a set of applications servers for most users, whereas another may provide ICMP and SSH to those very same servers for DevOps activities.

Trustgrid ZTNA Security Policies

To accomplish this in a simple and zero trust fashion, each L3 bridge is configured with a set of allowed destinations that users of the bridge may access.  Doing this allows each bridge to easily be defined with the minimum set of protocols, IPS, and ports needed to support the intent of the L3 bridge in question.

Open Source Client Support 

Access to the Trustgrid L3 bridge is supported on open-source VPN clients.  Currently, any standard WireGuard client is supported, with OpenVPN support coming soon.  By supporting open source clients the customer is provided additional security through the visibility the open-source community provides, rather than developing yet another software client and relying on security through obscurity as many do.

Extensive Observability

The L3 bridge provides the same deep observability as the rest of the Trustgrid ZTNA solution.  Current and historical visibility is provided into the who/what/where of each user accessing an L3 bridge, as well as failed login attempts. When deeper insight is required into an active or past connection, all traffic flow logs are visible within the administrative portal, along with an option to immediately terminate and block an active session.

Trustgrid Zero Trust Networking Session Monitoring


Trustgrid zero trust networking is specifically designed to aid DevOps and support teams managing applications across cloud and edge environments. The platform allows to apply the principles of zero trust security to their remote access support stack.

In addition to highly-available connectivity, the solution provides advanced security, logging, and observability features to organizations supporting applications or components in their customer environments.  While the majority of remote access scenarios can be supported by Trustgrid’s proxy-based ZTNA approach, there will likely be scenarios where layer 3 access will be required by the technology used or desired by teams supporting it.

The ZTNA Layer 3 Bridge is a powerful tool that can fill some of the gaps presented by more traditional ZTNA products. Instead of requiring that users immediately ditch legacy infrastructure or operate additional connectivity products, Trustgrid’s ZTNA L3 Bridge gives the user the ability to immediately secure their infrastructure with a ZTNA architecture, while giving the option to continue to use the systems and tools they prefer when needed.

Learn more about Trustgrid Remote Access

* WireGuard is a registered trademark of Jason Donenfeld