Security teams are often familiar with working with VPNs and firewalls. This article examines why VPNs and firewalls are used together, and how the role of firewalls differs when used with Twingate, given that Twingate offers a different architecture to traditional VPN solutions.

Securing access with VPNs and firewalls

Firewalls are common and are typically used to protect, control, and monitor two types of flows:

• User flows (end user to application, end user to service, etc.)
• Machine to machine flows (application to application, application to service, etc.)

User flows

In a typical VPN setup, end users are assigned local IP addresses on a company’s private network and effectively join the network. VPNs are primarily concerned with connectivity, not access control. This is because once a user has successfully signed on to the VPN, they then have access to the network behind the VPN server without any further restrictions imposed by the VPN.

This model poses a security risk. Without any additional access controls in place, once the user is connected to a network via a VPN, their device now has relatively unrestricted access on the private network since it is essentially present on the network. An attacker could now use that device (whether directly or by compromising the end user’s device) to move laterally within the network, undertaking actions such as port scanning, asset cataloguing, and so on.

Companies have historically mitigated this risk by using techniques such as network segmentation, patching policies, and firewalls. Firewalls add a layer of access controls on top of the VPN.

Common strategies used to configure firewalls for the purpose of implementing access controls include:

• blocking all inbound traffic from IP addresses assigned to user devices destined for IP adresses assigned to applications and services
• allow-listing IP addresses assigned to certain groups of users (e.g. developers) to combinations of IP addresses assigned to applications and services and ports used by services (e.g. port 22 for SSH traffic)
• monitoring outbound network traffic generated by user device IP addresses (e.g. to detect port scanning, service discovery, etc.)

Machine to machine flows

Modern applications are frequently composed of multiple moving parts, each with their own IP address. Network segmentation alone is often insufficient to ensure proper segregation of communication between applications and services. Therefore, it is common for companies to also leverage firewalls to prevent applications from communicating with each other if they do not need to do so by design. This helps to prevent a compromised application from attempting to compromise other unrelated applications if the network path is open.

To secure machine to machine flows, access control strategies are adopted that are similar to those used for end users. However, the rules associated with the former flows are typically less strict because human agents are often seen as a particularly “weak link” in the security chain.

SecOps & anomaly detection

Firewalls enforce rules but can also trigger alerts when abnormal behavior is detected (e.g. port scans). VPNs rarely have a role to play in monitoring and anomaly detection activities.

Securing access with Twingate and firewalls

Unlike a traditional VPN, Twingate does not solely focus on connectivity. Twingate is a single solution that manages both connectivity and access control.

Unlike a VPN, when an end user successfully connects to Twingate, that user is not connected to the private network. In order to access Resources on the network, the end user must first be explicitly authorized to access that specific Resource (e.g. by a combination of Security Policies and other items). In fact, the Twingate Client prevents the user from attempting to connect to applications and services on the private network by not allowing network traffic to even leave the device if the user is not authorized for the relevant application or service.

As mentioned above, firewalls are deployed in combination with VPNs to ensure that any given user will be able to:

• connect to the network (VPN)
• access only the services and applications they are authorized for (firewall)

Twingate is architected differently and is designed to cover both needs in a single solution. This is why the concept of a Resource in Twingate is key and why each Resource should ideally be tightly defined with both specific protocols and specific ports.

In one capacity, Twingate replaces the role of a firewall for user flows by not allowing traffic of any kind to arrive at Resources that a user has not been explicitly authorized to access.

What about machine to machine flows?

Machine to machine flows can also be protected by Twingate using Service Accounts. This is particularly useful whenever two systems hosted in entirely separate environments need to communicate (e.g. a CI/CD SaaS tool needing access to an on-premises server).

We still recommend the use of firewalls to impose access controls between applications and services that co-exist on the same network.

SecOps & anomaly detection

Since Twingate provides both connectivity and access control, it also makes sense for the Twingate platform to also help monitor network access activity. One way it does this is by providing real-time logs for all network connection events. Since connection attempts to Resources that a user is not authorized to access do not leave the device itself, only the traffic flowing through Connectors via authorized connections can be logged.

Twingate’s real-time connection logs provide granular information for each connection made by a device, including the:

• identity of the user and device (e.g public IP address, user’s email, device information)
• source of the connection (public IP address, Resource requested, protocol requested, port requested)
• network path (Connector information, Remote Network information)
• context (timestamp, type of event)

We recommend processing real-time connection logs via a SIEM for real time monitoring and alerting, but also for investigative work, if needed.

What about the Twingate Admin Console?

The Twingate Admin Console is a critical piece of the Twingate platform since it is where mappings between Users, Groups, Resources and Security Policies are defined. Therefore, it is important to keep the Admin Console secure. To help secure the Admin Console, Twingate provides:

• a dedicated Security Policy specific for Admin Console access (allowing more frequent re-authentication to be required, 2FA to be enforced, etc.)
• an audit trail of all administrative actions (called the Admin Actions Report) that contains a timestamped record of every action taken by any Twingate Administrator, including create, delete, edit, and connect events across all Twingate objects (Connector, Device, Group, API Keys, Remote Network, Resource, Service Account, User).