Change Language
wds-media
  • Home
  • VPN
Zero Trust With OpenVPN Protocol for Network Access = Our ZTNA-Capable Solutions

Zero Trust With OpenVPN Protocol for Network Access = Our ZTNA-Capable Solutions

  • By Admin

OpenVPN Cloud is now CloudConnexa® — learn more here.

What is Zero Trust Network Access (ZTNA)?

According to Gartner, “Zero trust network access (ZTNA) is a product or service that creates an identity- and context-based, logical access boundary around an application or set of applications. The applications are hidden from discovery, and access is restricted via a trust broker to a set of named entities. The broker verifies the identity, context and policy adherence of the specified participants before allowing access and prohibits lateral movement elsewhere in the network. This removes application assets from public visibility and significantly reduces the surface area for attack.”

If we deconstruct the main functionality of Zero Trust Network Access (ZTNA) solutions into two main components, they would be: 1) applying the zero-trust security principles to ensure that there is no lateral movement and that permissions to applications are based on identity and context and 2) providing a means to get network access to those applications.

The ZTNA solutions in the market differ based on the technologies they use to accomplish the zero trust and network access functionality. The choice of technologies can give some products an edge over others or suit a particular market need better.

Are OpenVPN products ZTNA-capable?

Our products provide the essential set of ZTNA capabilities. The products have separated policy enforcement functions from network access. With our products, getting access to the network does not mean that one can access all the applications on the network or even discover which applications are present on the network.

With our products, getting access to the network does not mean that one can access all the applications on the network or even discover which applications are present on the network.

Our products use the OpenVPN tunneling protocol to provide access to the network, which is the network access component of ZTNA. Then, the zero-trust component comes into play – and access is granted to only those applications that are authorized based on authenticated identity and context.

The first policy control point is at the network access connection. Prior to granting network connection via the OpenVPN tunnel, a set of checks are carried out to verify:

  • The presence of an HMAC signature in all SSL/TLS handshake packets for integrity verification.
  • The use of a valid client digital certificate.
  • The proper device context.
  • The authenticated user identity.

Devices that do not possess the assigned digital certificate or use the proper HMAC signature cannot even proceed to user authentication. This keeps the applications hidden from discovery and vastly minimizes the attack surface.

Once the network connection is granted, an identity- and context-based, logical access boundary around an application or set of applications is created based on enforcing configured access policies. These access policies operate at the network layer and effectively create network segmentation that prevents lateral movement. The access policies can be considered to be similar to network firewall rules, but unlike static firewall rules, these rules are created and enforced based on user identity. To summarize, after successful network access, our products enforce network firewall rules that are granular to the application protocol and port level to segment the network and provide access to only authorized applications based on the user’s identity.

Why do we use the OpenVPN protocol for network access?

Using the OpenVPN protocol for network access makes for a very robust and flexible ZTNA solution because it provides connectivity at the IP layer and therefore supports all internet application protocols. Using an approach other than IP layer connectivity implies that it will support only a limited set of applications, most likely web-based, and will try to convert other popular application protocols like RDP and SSH into HTTPS with limitations. OpenVPN tunnels that provide IP-layer access ensure that all current and future IP-based applications are natively supported.

Using the OpenVPN protocol for network access makes for a very robust and flexible ZTNA solution because it provides connectivity at the IP layer and therefore supports all internet application protocols.

Some other reasons our products use the OpenVPN protocol are:

We know it best: Being the creators of the OpenVPN protocol, we are experts in it. We continually strive to improve it. Case in point: our improvements to the protocol to provide data throughput close to line-rate speeds by offloading all data channel processing to the kernel — a scheme we call Data Channel Offload (DCO).

Firewall-friendly and DoS attack-proof: Based on SSL/TLS, the OpenVPN protocol is firewall-friendly, which is an important consideration when users are accessing applications from a variety of different Wi-Fi and other access networks. The OpenVPN protocol has built-in mechanisms to prevent denial of service attacks which ensure that application access is always available.

OpenVPN tunnels allow Application servers to contact devices: With network-level access, Application servers can send unsolicited traffic to devices. For example, it could be a request from a device management application server to a target device for applying a software patch, erasing data, etc. Most ZTNA solutions that do not use network tunneling protocols are built on the premise that the device or application client will always initiate traffic to the application server and do not account for any cases in which the application server needs to be the one to initiate traffic.

The OpenVPN protocol is proven and secure: Unlike proprietary ZTNA solutions and network tunneling protocols, the OpenVPN protocol, being open-source, is fully transparent and has been audited as safe.

IoT communications: The use of OpenVPN tunnels and mutual authentication based on digital certificates provide a digital certificate-based identity to IoT devices allowing for least privilege access even for connected IoT devices. Many ZTNA solutions not based on network tunneling protocols do not account for unattended always-on connections from IoT devices.

Our ZTNA-capable products

We have two products that have ZTNA capabilities. Access Server is our on-prem solution for customers who prefer to own and manage their own ZTNA solution and keep their data communications completely within their trust domain. Cloud Connexa is our service offering for customers who don’t want to deploy, manage, and scale an on-prem solution and want to use a service instead.

Access Server

Our self-hosted on-prem network access software solution supports Zero Trust capabilities and implements OpenVPN tunneling protocol as Network Access. Access Server simplifies the rapid deployment of a secure remote access and site-to-site solution within a ZTNA framework with features like clustering, authentication, and access control.

CloudConnexa®

Cloud-delivered network access service that supports Zero Trust capabilities and implements OpenVPN tunneling protocol as Network Access. With Cloud Connexa your business gets a cloud-delivered service that integrates virtual networking and critical security functions in a secure overlay network that’s easy to deploy and manage within a ZTNA framework.

Why is a client-based approach the best approach?

Our solutions only accept network access requests from OpenVPN client software applications. Our client application is available for all operating systems, both mobile and desktop. While some ZTNA solutions allow for access to applications using a web browser, we strongly believe that client-based access is the only approach to use, and here are the reasons why:

Strong security: Security is foremost among our considerations. In order to allow client-less access, a web server that proxies access to the applications needs to be made public. We believe that making anything accessible to the internet, other than hardened servers to accept incoming OpenVPN tunnel connections, opens up an unneeded attack vector. Secondly, web browser access does not use digital certificates for mutual authentication, meaning that the user/browser does not need to possess a digital certificate in order to access the web server – which would increase the attack surface even more. With the use of a client app, a digital certificate is needed and used for mutual authentication to increase security and allow only legitimate users.

Not all apps use browsers: Applications that need client software to work cannot be accessed via a web browser. For example, Remote Desktop Protocol (RDP).

Mobile apps are on the rise: More businesses are creating private mobile applications that have been specifically developed for internal use within a company, and the use of web browsers on mobile devices for application access is diminishing. Using our client-based solution, these mobile apps can have secure access, which is impossible with a browser.

A client can check device posture attributes: Our client applications can be a source of device information. They can provide device identity and posture information which can be considered while authorizing the connection.

Key technical differentiators for our cloud-delivered service, CloudConnexa

Cloud Connexa creates a private overlay network that connects all your applications, networks, users, and devices. The service can be accessed from 30+ points of presence worldwide. Some of the technical differentiators that set Cloud Connexa apart from the competition are as follows:

Full-mesh connectivity: All Cloud Connexa points of presence are connected together in a full-mesh topology providing a direct route for low latency and alternate routes for redundancy.

Sole Application Access: Instead of connecting a network to Cloud Connexa, only the application servers can be connected. This provides users access to a specific service and nothing else.

Private IP address Cloaking: Even after getting network access, there are no routes to the connected private networks sent to the client. Even the private IP addresses of the application servers are not disclosed.

Application-based Domain Routing: Instead of providing IP address subnets as routes to your private networks, Application Domain-based Routing lets you easily route traffic to applications distributed among your various connected private networks using the application’s domain name as a route to the network where that application resides. This means you can connect private networks to Cloud Connexa that are using the same overlapping IP address subnets without affecting application access.

Traffic Segregation: Traffic to private applications, internet destinations, and SaaS applications that you trust and want to access via Cloud Connexa can be segregated from general internet traffic. The general internet traffic can then be protected with a third-party internet security service.

Restricted Internet: Internet access can be completely blocked for specialized single-purpose devices except for trusted Internet destinations and private applications. This is useful to lock down connected devices such as kiosks, point-of-sale systems, etc.

Private Application Discovery and Visibility: Cloud Connexa provides traffic flow visibility and shows you who is accessing what. This also means that you can discover traffic flows to private applications that you did not know existed and apply access policies for them.

SSE Lite capabilities: Cloud Connexa can be used as a lightweight SSE solution because, in addition to providing ZTNA, it can protect internet access using Content Filtering & IDS/IPS. It can also offer SaaS protection by securely tunneling SaaS traffic to Cloud Connexa and enabling using SaaS trusted source IP address login restrictions.

Device Identity Verification and Enforcement (DIVE): Cloud Connexa has capabilities to prevent the use of the digital certificate assigned to a specific authorized device from being used with a different unauthorized device and providing network access to authorized devices only.

Trusted Extranets: Cloud Connexa customers can securely share their private applications with each other forming an extranet between trusted parties. For example, a Cloud Connexa customer can share access to their private financial application with another Cloud Connexa customer who is a financial auditing company.

Get Started Today

OpenVPN® is the market-proven leader in secure virtualized networking. Our cloud-based platform enables organizations to maintain secure communication between their distributed workforce, IoT/IIoT devices, and the online services they rely on daily. Built on the market-proven OpenVPN protocol, the solution combines advanced network security, encrypted remote access, and content filtering into a virtualized secure network that provides the best of VPN and ZTNA security.

With over 60 million downloads of our core open-source software and over 20,000 commercial customers, OpenVPN is recognized as a global leader in secure networking.

Ready to take your business to the next level with Cloud Connexa? Work from anywhere and from any device with confidence. Create an account today for three free connections and the secure network connectivity your business needs.

Soft2Bet Launches Christmas-Themed MEGA Engine to Boost Engagement

Soft2Bet Launches Christmas-Themed MEGA Engine to Boost Engagement

Read More