Twingate

Twingate vs. VPNs

What is the difference between Twingate and corporate VPNs?

This article explains the differences between using Twingate versus using VPNs to secure access to your private applications and IT resources. Twingate offers organizations the easiest path to adopting and maintaining a zero trust networking model. If you’re unfamiliar with zero trust networking, we explain what it is below.

Why are VPNs used and what is Zero Trust Networking (ZTN)?

How the Corporate VPN Model Works: Castles, Moats & Drawbridges

Traditionally, companies housed all their information technology resources “on-premises,” in locations controlled and managed by them. This included servers loaded with applications that were placed in a data center or an office server room, and desktop computers used by employees, all of which were all wired up to a company-controlled local or wide area network over which they communicated.

Because everything and everyone tended to be located on the same corporate network, securing the perimeter of this network against outside attackers was the standard approach. In other words, building a moat around the corporate castle.

On the occasion someone working remotely and outside the corporate network (maybe a traveling salesperson) needs to access an IT resource, they have to be given a way to cross the moat: a drawbridge. That drawbridge typically takes the form of a virtual private network (VPN) server.

VPNs facilitate the creation of a secure connection to a network over the internet, which is considered an unsecure network. So to access the corporate network, a remote user must establish a connection to a VPN server and, once they prove they are an authorized user, they are granted access to the network behind the server, as if they were sitting at a computer in the office and on the network.

To segregate resources, larger companies may also have multiple “castles” (networks) which need to communicate with each other. This requires building a complicated network of VPN connections between them and letting users connect to multiple VPN servers.

Times have Changed: From Castles to Cities

In the physical world, walled castles have been replaced by borderless cities, as people and the activities they engaged in spilled out beyond the castle walls. A similar thing has occurred with how companies house their resources and locate their workforce.

The growth of cloud-based SaaS products and IaaS providers like AWS, Microsoft Azure and Google Cloud Platform has seen companies increasingly use IT resources that are no longer located within the corporate network. Near-universal wireless internet connectivity and the omnipresence of mobile devices has allowed many workers to work from outside the office and while traveling. The COVID-19 pandemic accelerated this trend as workforces transitioned en masse to working remotely for a prolonged period.

Given that people and IT resources are now increasingly situated outside of the castle walls, a perimeter-based defense combined with a VPN are quickly becoming obsolete given that they no longer protect all the things that need protection. For example, there is no reason an employee on a mobile device accessing a cloud-based email account needs to access the corporate network.

How Zero Trust Networking Works

ZTN is a network access model that is based on the core principle that the network and the users that want to connect to corporate resources on it are assumed to be untrusted (hence “zero trust”). This being the case, to ensure security this dictates that every attempt to access a private resource must be checked and verified to ensure that the user is who they claim to be (authentication), and is authorized to access what they are trying to access (authorization).

This security model aligns much more with how organizations work today. Many users and IT resources are outside the corporate network and connect to each other over the internet. And, as a public network mostly controlled by third parties, the internet is inherently untrustworthy from a security perspective. The internet is essentially part of the corporate network, and there is no static perimeter that reliably defines what’s inside and trusted, and outside and untrusted.

The ZTN model also unlocks a whole host of other security benefits over VPNs as the next section describes.

Benefits of Twingate vs. VPNs

Twingate allows organizations to adopt a ZTN model. However, ZTN can be implemented in a myriad of ways. Twingate provides a thoughtful implementation that focuses not just on security, but also on usability. Thus, in addition to ZTN being more suited for the modern workforce, Twingate offers numerous additional benefits over VPNs across many dimensions.

Security

Control access granularly at the application level, not the network level. With VPNs, user access is granted to the entire network that the VPN secures. However, Twingate allows access to be granted on a per application basis. This has two significant benefits:

  • “Least privileged” access can be implemented. This is a key security concept where you grant users access to what they need, and nothing else. VPNs only provide coarse access control at the network level.

  • Limit the scope of data breaches. With VPNs, users have access to all the resources on a network, whether they are relevant to the user or not. Therefore the whole network is exposed when an attacker breaches a VPN. Twingate greatly limits the blast radius of a breach because an attacker’s access is limited to specific apps, and they cannot move laterally to other resources on the network. In fact, the network isn’t even visible to an attacker.

Keep private resources hidden. With VPNs, VPN gateways need to be deployed and they are public and visible on the internet. As a result, gateways are constantly probed by attackers searching for weaknesses, requiring organizations to pay close attention to securing them. However, vulnerabilities in VPN gateways manufactured by all major vendors are regularly discovered, and zero day exploits or unpatched vulnerabilities render organizations highly exposed to breaches. For example, a VPN vulnerability was the cause of a successful ransomware campaign on Travelex that they estimated cost them $30m. To use our earlier analogy, with VPNs, everyone knows where your drawbridge is.

With Twingate, you don’t need to install a public gateway, so no network resources are publicly exposed on the internet and your network stays hidden. Malicious actors can’t attack what they can’t see. Instead, Twingate connectors are installed inside your hidden network, and these facilitate outbound connections to authorized users.

Authorize access based on rich contextual data. With VPNs, determining whether a user is authorized to access a network is based on a narrow set of attributes, such as a username, password and user IP address.

With Twingate, determining whether a user is authorized to access a specific resource can be based on a wide variety of factors, including an identity authenticated by a third party SSO or identity provider using MFA, the user’s physical location, time of day, device posture, and other contextual data such as a risk score. This provides a more flexible, adaptive and controlled approach to security allows you to balance risk and user friction.

Centralized visibility over all network security activity. Logging is key to monitoring what is happening with IT resources and enabling quick responses to issues that arise. With VPNs, managing multiple networks means logging practices may be fragmented and inconsistent.

Twingate connects with and logs security events across all networks. It provides a single centralized, consistent view over everything, making monitoring easier. Twingate can also integrate with SIEM (security information and event management) systems.

Performance

Twingate is architected in a way that:

  • Improves internet connectivity for users by reducing latency and making accessing private and public resources more responsive
  • Reduces corporate network congestion and bandwidth usage
  • Provides the reliability expected of an important system

No backhauling. With a VPN enabled, all traffic from a user device is routed to a VPN server, which may be physically distant. In turn, the resource the user wants to access may also be physically distant from the VPN server. For example, a U.S.-based user traveling in Tokyo may be trying to access a website located in Singapore. In order to do that, they need to connect to a VPN server located in New York. Instead of traffic being able to flow directly from Tokyo to Singapore, it first has to be routed half a world away through New York! The added latency results in a frustratingly slow connection for users. This situation is referred to as backhauling.

With Twingate, backhauling is eliminated, since traffic does not need to be routed through a chokepoint in the form of a company VPN server. Twingate has a global network that is able to relay data to destinations more directly, resulting in smoother and clearer video calls, more responsive web browsing, and better transmission speeds.

Split tunneling. Communications using a VPN are “full tunnel,” which means all traffic is indiscriminately passed through a VPN server and into a corporate network - whether it makes sense to do so or not. Twingate is “split tunnel” by default, meaning only traffic that needs to go through your internal network (such as access to internal apps) gets sent there. Other traffic doesn’t need to take that detour, which results in lower latency connections, and less bandwidth use and congestion on the corporate network. This is particularly important for applications that provide real-time media streaming or voice and video calls.

Decentralization of decision making at the edge. The functionality of VPN clients is relatively limited. They relay authorization information to a VPN server, and it is the job of that server and other network infrastructure to process authorization requests and manage traffic routing. This is known as “tromboning,” which causes increased latency.

Twingate pushes these processing activities to the network edge by making its clients intelligent. This further streamlines the user experience by reducing bottlenecking. For example, Twingate clients can handle initial processing of authorization requests without having to go out to the cloud. MFA checks are performed before a connection is initiated to the destination resource.

The Twingate client app is also lightweight and not resource intensive, having being built on technology that has powered desktop and mobile apps with millions of active users.

Reliability comes standard. Twingate takes over handling the hard work of ensuring service availability, managing load balancing, redundancy, maintenance and scalability. Offering Twingate is our core business, so we focus a lot of attention on ensuring it works the way customers expect. When implementing a VPN, this work falls more squarely on the shoulders of the organization, which often does not specialize in operating VPNs.

Deployment & Maintainability

Deploying and maintaining VPN infrastructure is resource intensive, requiring a lot of hands-on management by a company. Complexity mushrooms as companies grow. In contrast, Twingate handles a lot of these activities so that when it comes to access control, IT teams can focus on simply determining who should have access to what.

Easy Setup, Rapid Deployment. VPNs are not trivial to set up. Appliances first need to be procured. Implementing VPNs not only requires these appliances to be configured, but also often requires surrounding network infrastructure to be reconfigured as well (e.g. network segmentation planning). Segmenting access by application is much more intuitive, and doesn’t require the planning demanded by segmenting by networks.

On the other hand:

  • Because Twingate is a service with software components and no appliances or hardware, it can be procured, configured, and tested in minutes.
  • No infrastructure changes are required, apart from installing a lightweight connector component (delivered in the form of a container) on a single device within a network.
  • Network names and IP addresses don’t need changing, and users can continue to access resources using the same names as before.
  • Twingate is protocol agnostic and supports all private applications, so no additional configuration is required by users or admins.

Scalability. A lot of work is required to scale VPN infrastructure (e.g. procuring new appliances, setting them up, reconfiguring networks, updating clients, load balancing, building redundancy). Change management can be a nightmare. Because Twingate is delivered as a service, all of this work is handled by Twingate, unburdening IT teams from having to do it themselves. As business needs grow (or pull back), scaling Twingate up or down is possible with literally a few mouse clicks. Twingate provides a more agile approach to security that can keep up with fast-moving businesses.

Centralized organization-wide management. Unlike VPNs, Twingate includes a centralized admin console which controls access to private resources throughout the organization, regardless of whether they are inside or outside the traditional network. This single view promotes consistency and leads to fewer errors in managing access controls.

Reduces complexity of the security stack. VPNs are a legacy technology that are complicated and costly to maintain. Expensive security experts need to be staffed to maintain VPN infrastructure: troubleshooting errors, monitoring for vulnerabilities, applying patches and installing upgrades. This also introduces key person risk, since this technical knowledge may be limited to a handful of people within the company. Twingate simplifies an organization’s security stack by managing that complexity for businesses and freeing up IT teams to work on other projects.

User Experience

Effortless user experience. VPN clients require users to regularly interact with them. They must be periodically toggled on or off, and sometimes users must select which VPN server to connect to, imposing on them the challenge of remembering which server is associated with the resource they want to access. The Twingate client is always on in the background, and stays out of the way, requiring no user interaction. By intelligently and automatically routing traffic from the user’s device, it gets out of the user’s way and just works.

Better online user experience. When a VPN is on, it degrades users’ online experience, increasing latency and causing connectivity issues with certain activities. Another side effect of VPN usage is that users often encounter incorrectly localized content when accessing websites. This is because a user’s traffic appears to originate from where the VPN server is located, which may be different to the region the user actually is in. This can be frustrating to users when, for example, they see pages in other languages or search engine results they do not expect.

Twingate’s ViPR technology, built into each of its clients, supports split tunneling, handles authorization processing, and eliminates backhauling - all of which mean a better user experience online overall - not just when accessing the company’s private resources. Smoother video calls, more responsive web browsing, and fewer connection problems means happier users who spend less time with tech support.

Easy enough to self-serve. Users can download Twingate clients and self-enroll with a few clicks. Users turn on the app with a single click, and can then forget about it. Setting up a VPN client is a more involved, multi-step process that is more error prone.

Cost

No upfront capex. VPNs require an upfront capital investment to implement. Scaling VPN infrastructure up or down is also a slow process due to the deployment times required. This means that organizations either over-purchase capacity to plan for future growth (which may not always occur), or under-purchase capacity (which leads to delays and productivity losses as IT teams scramble to build more capacity). Twingate, as a software-only cloud-based service, converts capex into opex, allowing organizations to buy only as much capacity as they need in the short term. Twingate is also more cost-effective overall, with transparent, easy to understand pricing.

Lower personnel costs. As mentioned above, Twingate results in less time spent supporting users, and less time spent by IT administrators maintaining and configuring systems. This results in a more efficient use of personnel and a better return on investment.

Why doesn’t everyone use ZTN?

ZTN solutions are a better solution than traditional VPNs. The main reasons organizations don’t clamor to make the change comes down to a few perceived issues: (1) ZTN is complicated to set up, (2) migrating from VPNs to ZTNs is a major, time consuming project, and (3) so many resources have been invested in VPN infrastructure that it would be costly to replace it and retrain everyone.

With Twingate, none of those things are true! Twingate makes implementing and migrating to ZTN relatively quick, simple and low risk.

One key thing is that Twingate can work alongside existing VPNs without requiring changes to infrastructure. That means it can be tested without risk to the organization - there is no need to “rip and replace” existing systems, change infrastructure, or rename network resources. Rollout can be phrased in gradually. For example, pilot testing can be performed with a single team with respect to a subset of private resources they need to access.

Moreover, as mentioned above, Twingate is a more cost-effective solution that can reduce overall IT spend - not just in the form of capital expenditure on equipment, but also in the form of lowering the administrative burden on IT teams and making users more productive. Twingate’s user-centric approach means minimal training and simplifying remote access for users.

Twingate is so easy, you can sign up for a free trial today and immediately try it out.

Updated 3 months ago


Twingate vs. VPNs


Suggested Edits are limited on API Reference Pages

You can only suggest edits to Markdown body content, but not to the API spec.