As organizations increasingly seek to support and secure more remote network connections, many are rethinking the traditional VPN. Many VPN alternatives exist to help secure remote access — mesh VPNs chief among them.
Mesh virtual private networks (VPNs) use a peer-to-peer architecture that can theoretically be less expensive than traditional VPN approaches. VPNs, which are estimated to be used by 1.6 billion people, don’t carry the same weight they used to in the security stack, given massive security holes, port shadow weaknesses, and broad consensus on their susceptibility to cyberattacks.
Still, the global VPN market is robust — and expected to almost triple by 2030 to $137 billion.
In legacy network stacks a VPN was used to access network-based resources such as on-prem line of business apps and file shares as if you were on the corporate network. In traditional enterprise networks if you were within the network perimeter you had inherent network-level access to most everything on the network. Hybrid networks and a push toward zero-trust concepts have the industry moving away from this way of thinking, making the concept of a network perimeter less of a focal point when it comes to securing enterprises. If you’re running a traditional hub-and-spoke VPN architecture, making the switch to mesh VPN might be worth considering.
Why mesh VPN
Mesh VPN is a relatively new concept that is quickly gaining momentum as more vendors bring their services to market. At its core, mesh VPN solves a few weaknesses in the traditional VPN approach and fundamentally integrates tightly with current security stacks.
Reduced attack surface
Unlike a client-server VPN with a hub-and-spoke model, there is no VPN server on the perimeter as a potential attack surface. Traditional VPN servers are frequently easy to identify as there are a finite number of VPN standards or even proprietary protocols. This makes discovery a cinch and attack a natural progression for bad actors. Conversely, members of a mesh VPN can reside behind a corporate firewall, on a home network, or on a cellular connection, behind NAT and other technical components that frequently cause difficulty with VPNs. The ability for nodes to connect to each other comes from a control plane that is typically managed and maintained by the VPN vendor.
Better support for Edge devices
Traditional VPNs primarily come in two flavors: site-to-site and remote access. With current networks extending to edge devices tasked with enabling business operations many edge deployments require either a software VPN client or a network appliance configured with a site-to-site VPN connection. Mesh VPNs can certainly leverage a software VPN client on all of the popular operating systems but can also be implemented directly into containerized applications and other cutting-edge deployments that may not be a great fit for traditional VPNs.
Focused access to networked services
Mesh VPNs by default only provide access to other members of the mesh VPN, not to the entire network. This could include servers, workstations, storage devices, cloud-based resources, or even application containers. This capability can often be further refined to provide access only to the devices and services appropriate for a particular user: meaning while a variety of systems and services are accessible on the mesh VPN, individual users only have access to the services to which they have a business need for access. The net result of these capabilities is essentially dynamic firewall rules between nodes based on the user’s roles and business requirements. From a management perspective, nodes and services can be grouped and restricted using concepts that are familiar to cloud administrators such as resource tagging and access control lists.
Automated management
Most mesh VPN solutions further enhance these concepts by offering API-based management, meaning the process of assigning roles and access can be integrated with other management and orchestration tools already being leveraged within the organization. This could be in the form of an extended detection and response (XDR) solution, or simply script-based automation that interacts with business systems.
Integration with existing security tools
Mesh VPN solutions are built from the ground up for hybrid work. As such, security staples like identity management (IDM) and mobile device management (MDM) help form a cohesive foundation for the hybrid workforce. Integration with IDM helps streamline onboarding (and perhaps more importantly offboarding), as well as dynamic changes to system access based on changes to user identities. Mesh VPN solutions make sense in security devices alongside MDM as customer laptops, tablets, and even mobile phones can potentially be added as VPN nodes.
Before you jump
For a mesh VPN service to be successful in the enterprise there are some non-negotiables. Integration with current authentication services is an absolute must, and this extends to authenticating devices and ensuring they meet device management policies. Additionally, integration with existing tools in the security stack such as event monitoring and EDR (endpoint detection and response) is going to be a hard requirement for devices accessing protected services.
Why not mesh VPN
Mesh VPN solutions check a lot of boxes, but as always there is a flip side of the coin. Businesses still operating in more of an old-school, on-prem architecture will likely have better options for a couple of reasons.
Architecture
Businesses still functioning with the concept of a hard network perimeter and little to no cloud presence may not garner much value from the hybrid identity and zero-trust capabilities which mesh VPN can help introduce. Likewise, if business resources (such as file servers or line of business apps) are primarily contained within the network perimeter a centralized VPN server may be the better investment.
Cost
Speaking of investments, one potentially major downside to mesh VPN solutions comes down to subscription costs. Most mesh VPN offerings have a monthly subscription cost per user, which can add up quickly, particularly for some of the more premium capabilities. As more and more legacy VPN solutions pivot to subscription-based licensing this concern must be weighed carefully.
How to: Support connectivity to centralized corporate resources
VPNs have been used as a way to allow remote users to access resources within the perimeter of the corporate network. Mesh VPNs are designed as a peer-to-peer network, meaning the scope of the network extends by default only to those devices with the VPN client installed. This becomes a bit of an issue when trying to provide access to applications or services in a centralized location. Do you install the VPN client on each server? How do you support workloads that are clustered across multiple servers, or run in a stack like containerized apps? What about devices that simply don’t support software installation, such as industrial hardware or even printers?
Tailscale offers the concept of subnet routers to function as a gateway to one or more devices on a network segment. This feature allows users to install the Tailscale client on a single computer within a network, and configure it to provide connectivity to other devices on that network. The process to enable a subnet router in Tailscale requires two steps for security purposes. First, you must configure the Tailscale node as a subnet router, which on Windows involves starting Tailscale from the command line using the --advertise-routes parameter followed by IPv4 subnets defined in CIDR notation. For example, the following command serves the entire 192.168.1.x Class C subnet to the Tailscale network (the tailnet).
tailscale up --advertise-routes=192.168.1.0/24
Individual endpoints can be shared by specifying the full IP address followed by the /32 CIDR subnet mask. Multiple subnets (or endpoints) can be defined by separating them with a comma.
The second step to enable a subnet router involves using the Tailscale admin console to enable individual routes.
Tim Ferrill
Tim Ferrill
Once the route is approved in the admin console, tailnet members will be able to access the applications and services on the target subnet.
How to: Restrict access to resources and services to authorized users
In a zero-trust world access to corporate resources should be limited to the minimal number of users required. Being able to access the corporate network through a VPN should not automatically grant access to web servers or file shares, even at the network level. Tailscale offers tools to limit what devices and users can reach network resources using access control lists (ACLs).
ACLs in Tailscale boil down to a source and a destination. Unlike traditional firewall rules, Tailscale ACLs always result in an ‘allow’ action; connectivity is only allowed if you explicitly define a rule. Within the Tailscale ACL policy editor, you can leverage users or devices in bulk using groups or tags respectively, or individually using host or usernames. Access to devices or subnets made accessible to the Tailnet using subnet routing can also be allowed by referencing the subnet in the destination portion of the rule:
{
"action": "accept",
"src": ["tag:mobile"],
"dst": ["192.168.1.0/24:80,139,443,445"],
},
This rule states that devices with the mobile tag are allowed to connect to devices on the 192.168.1.0/24 subnet, but only on ports 80, 139, 443, and 445. Asterisks can be used as wildcards for both source and destination, either for the host or the allowed ports.
How to: Route internet traffic from remote clients through a central network
One common VPN use case is to protect sensitive internet traffic while devices are connected to public networks. Some industries require internet traffic to be monitored and/or filtered. There are several ways to achieve these requirements, but having all traffic routed through a central network has the potential to streamline the process. Tailscale’s exit node feature facilitates meeting these needs.
Exit nodes are configured similarly to subnet routing. The option is enabled in the Tailscale client on the device designated as the exit node, and then the configuration is approved by an admin in the admin console. Exit nodes can be configured as recommended (also known as suggested) or mandatory, which allows Tailscale to either select an exit node based on latency or performance or to force mobile users to send all traffic through a single exit node. Mandatory exit nodes require Tailscale’s premium or enterprise plan, as well as an MDM solution.
How to: Leverage corporate DNS servers for Tailscale clients
By default, Tailscale uses a feature termed ‘Magic DNS’ to provide name resolution to tailnet members. This name resolution does not extend to devices served on subnets and can prove problematic when attempting to access services predicated on DNS such as Active Directory.
Tailscale offers, however, the ability to define one or more internal DNS servers to use for name resolution. These DNS server entries can be configured for split DNS, providing the ability to only forward requests for a specific domain to the internal DNS server. Combining split DNS with subnet routing and ACLs presents a compelling blend of functionality.
How to: Achieve separation of duties within Tailscale
Creating a full-featured VPN solution is great and all, but it’s not the end of the story in modern IT security and compliance requirements. Separation of duties is a key best practice and a frequent component of compliance checklists. Tailscale offers several built-in roles you can quickly use to meet these business needs:
- Network admins are the administrators for the Tailscale account and have permissions to manage all aspects of the network configuration. User and device settings are can be viewed by network admins, but they are unable to make changes even to their own devices
- IT admins are less focused on the networking aspects of the Tailscale account and more on users and devices. IT admins can view network details, including ACLs contained in the tailnet policy file, but cannot make any changes.
- Billing admins can manage pricing plans and billing information. They do have view access to all aspects of the admin console, but cannot make changes to networks, devices, or users.
- Auditors have read access to all aspects of the admin console, but no ability to make changes. This role is particularly useful for compliance or audit reasons, or even quality assurance.
- Members have user-level access to tailnet. They have no access to the admin console but can connect to your tailnet and devices as allowed by ACLs.
Two additional roles, owner and admins, have full access to all aspects of the admin console. There can only be one owner, and in order to delete that account the owner role must first be transferred.
