How Does Twingate Split Tunneling Work Using Default-Deny Resources?

Overview

Unlike traditional VPNs where you configure "Split Tunneling" to exclude traffic, Twingate uses a "Default Deny" model. By default, nothing goes through the tunnel. Traffic only goes through Twingate if you explicitly define it as a Resource.

This guide explains how to configure Resources to access private servers (AWS/On-Prem) while keeping Zoom/YouTube traffic direct to the internet.

The Golden Rule: Define What You Need, Nothing Else

Do not add 0.0.0.0/0 (Full Tunnel) unless absolutely necessary. It hurts performance and increases bandwidth costs.

Step 1: Defining Resources (IP vs. FQDN)

Always prefer FQDN (Domain Names) over IP addresses.

1. Log in to the Twingate Admin Console.

2. Navigate to Network > Remote Networks > Select your Network (e.g., "AWS-Mumbai").

3. Click Add Resource.

Scenario A: A Specific Internal Server

• Resource Address: internal-db.netnxt.local

• Why: Twingate handles DNS resolution. The user's laptop doesn't need to know where this DNS record lives; the Connector inside your AWS VPC resolves it.

Scenario B: A Subnet (CIDR)

• Resource Address: 10.0.1.0/24

• Why: Grants access to all servers in that specific VPC subnet.

Step 2: Access Policies (Who gets in?)

Once a Resource is created, no one can access it until you create a Policy.

1. Go to Policies > Resource Policies.

2. Create a Policy: Engineering - High Security.

   • Requirements: "Trusted Device" (Must be JumpCloud Managed) + "MFA Every Day".

3. Assign this policy to your sensitive resources (e.g., Production DB).

Step 3: Verification (Split Tunnel Check)

To prove that Twingate is not slowing down Zoom:

1. Connect the Twingate Client.

2. Go to whatismyip.com.

   • Result: You should see your ISP's IP Address (e.g., Airtel/Jio), not the AWS Connector IP.

3. Ping your internal resource (ping internal-db.netnxt.local).

   • Result: It should resolve to a private IP (e.g., 100.x.x.x CGNAT range) mapped by Twingate.

FAQ

1) How does split tunneling work in Twingate?

Twingate uses a default-deny approach where no traffic enters the tunnel unless explicitly defined as a Resource, allowing all other traffic to go directly to the internet.

2) Why should FQDNs be preferred over IP addresses in Twingate resources?

FQDNs allow Twingate connectors to handle DNS resolution internally, reducing endpoint complexity and ensuring stable access even if backend IP addresses change.

3) How do access policies control who can reach Twingate resources?

Access policies define user and device requirements, such as trusted devices and MFA, and must be explicitly attached to resources before any access is granted.

4) How can administrators verify non-work traffic is bypassing Twingate?

By checking public IP addresses while connected and confirming internet traffic shows the ISP IP, while internal resource access resolves through Twingate-mapped private addresses.