Skip to main content

Tutorial: Step-by-Step Examples for Configuring Full and Split Tunneling in Access Server

Abstract

Configure full and split tunneling in OpenVPN Access Server using real-world scenarios. Learn how to apply and verify routing rules for users and groups with the Admin Web UI and CLI.

Overview

This tutorial shows how to configure full and split tunneling in Access Server using practical, real-world scenarios.

In this example, Brandon manages IT and networking for a company that uses Access Server to secure employee traffic.

There are two groups:

  1. Support: Needs full tunnel access (all traffic goes through the VPN).

  2. Developers: Need split tunnel access (only traffic to internal resources goes through the VPN).

The goal is to apply the correct tunneling behavior for each group.

There are two common scenarios:

  • Scenario 1: Full tunnel is configured globally.

  • Scenario 2: Split tunnel is configured globally.

Prerequisites

  • Access Server installed and running.

  • Admin Web UI access.

  • Root access to the Access Server console (for CLI steps).

  • One or more users or groups configured.

Note

In our documentation, we use example IPv4 addresses and subnets reserved for documentation, such as 192.0.2.0/24, 198.51.100.0/24, and 203.0.113.0/24.

Ensure you replace them with valid IPv4 addresses and subnets for your network(s).

Scenario 1: Full tunnel is enabled globally

If full tunnel is enabled globally, the Support group already has the correct access. You only need to configure split tunneling for the Developers group.

Step 1: Configure split tunneling for the Developers group

Important

This override can only be configured using the CLI.

  1. Connect to the console and get root privileges.

  2. Select one of the following:

    • Split tunnel without pushing DNS:

      sacli --user "developers" --key "prop_reroute_gw_override" --value "disable" UserPropPut

    • Split tunnel while still pushing DNS:

      sacli --user "developers" --key "prop_reroute_gw_override" --value "dns_only" UserPropPut

  3. Refresh the Access Server configuration to apply the changes:

    sacli start

Step 2: Verify the Developers group configuration

Important

You need to use the CLI to verify this setting.

  1. Connect to the console and get root privileges.

  2. List the developers group:

    sacli --pfilt developers UserPropGet

    • Example output:

      {
  "developers": {
    "group_declare": "true",
    "prop_reroute_gw_override": "dns_only",
    "type": "group"
  }
}

  3. Confirm the output includes "prop_reroute_gw_override" with the correct setting.

Step 3: Verify tunneling behavior from the client

  1. Connect to the VPN as a user in each group.

  2. Check the VPN client logs:

    • Support group (full tunnel):

      9 [redirect-gateway] [def1]
10 [redirect-gateway] [bypass-dhcp]
11 [redirect-gateway] [autolocal]

      redirect-gateway means all traffic goes through the VPN.

    • Developers group (split tunnel):

      9 [redirect-private] [def1]
10 [redirect-private] [bypass-dhcp]
11 [redirect-private] [autolocal]

      redirect-private means only specific traffic goes through the VPN.

  3. (Optional) Check the client routing table of the VPN client device.

    • Full tunnel includes two large routes:

      • 0.0.0.0/1 (or 0.0.0.0 128.0.0.0)

      • 128.0.0.0/1 (or 128.0.0.0 128.0.0.0)

Scenario 2: Split tunnel is enabled globally

If split tunneling is enabled globally, the Developers group already has the correct access. You need to configure full tunnel behavior for the Support group.

Step 1: Configure full tunneling for the Support group

Important

This method simulates full tunneling by routing all traffic using two large subnets:

  • 0.0.0.0/1

  • 128.0.0.0/1

Using Admin Web UI

  1. Sign in to the Admin Web UI.

  2. Click Access Controls.

    • The Group and User Access Rules tab displays.

  3. Click New Access Rule.

  4. Add the rule:

    • Target: Group

    • Group name: Support

    • IP address: 0.0.0.0/1

    • Reachable via: NAT

  5. Click Save rule.

  6. Add a second rule:

    • Target: Group

    • Group name: Support

    • IP address: 128.0.0.0/1

    • Reachable via: NAT

  7. Save and restart the server.

Using CLI

  1. Connect to the console and get root privileges.

  2. Use these commands to enable full tunnel for the Support group, without changing DNS settings:

    sacli --user "support" --key "access_to.0" --value "+SUBNET:0.0.0.0/1" UserPropPut
sacli --user "support" --key "access_to.1" --value "+SUBNET:128.0.0.0/1" UserPropPut

  3. Refresh the Access Server configuration to apply the changes:

    sacli start

Step 2: Verify the Support group configuration

Using Admin Web UI

  1. Click Access Controls.

    • The Group and User Access Rules tab displays.

  2. Confirm that both routes appear correctly in the Destination column for the corresponding group:

    • 0.0.0.0/1

    • 128.0.0.0/1

Using CLI

  1. Connect to your console and get root privileges.

  2. List the support group:

    sacli --pfilt support UserPropGet

    • Example output:

      {
  "support": {
    "access_to.0": "+NAT:0.0.0.0/1",
    "access_to.1": "+NAT:128.0.0.0/1",
    "group_declare": "true",
    "type": "group"
  }
}

  3. Confirm the output includes:

    "access_to.0": "+NAT:0.0.0.0/1"
"access_to.1": "+NAT:128.0.0.0/1"

Step 3: Verify tunneling behavior from the client

  1. Connect to the VPN as a user in each group.

  2. Check the VPN client logs:

    • Support group (simulated full tunnel):

      9 [redirect-private] [def1]
10 [redirect-private] [bypass-dhcp]
11 [redirect-private] [autolocal]
14 [route] [0.0.0.0] [128.0.0.0]
15 [route] [128.0.0.0] [128.0.0.0]

      redirect-private means specific traffic goes through the VPN while other traffic uses the client's local internet connection (split tunnel).

      [route] [0.0.0.0] [128.0.0.0] and [route] [128.0.0.0] [128.0.0.0] means that we're simulating full tunneling by routing all traffic using two large subnets, regardless of the redirect-private.

    • Developers group (split tunnel):

       9 [redirect-private] [def1]
10 [redirect-private] [bypass-dhcp]
11 [redirect-private] [autolocal]

      redirect-private means only specific traffic goes through the VPN, while other traffic uses the client's local internet connection (split tunnel). The two large subnets shouldn't appear for the Developers group.

  3. (Optional) Check the client routing table of the VPN client device.

    • Simulated full tunnel includes two large routes:

      • 0.0.0.0/1 (or 0.0.0.0 128.0.0.0)

      • 128.0.0.0/1 (or 128.0.0.0 128.0.0.0)

In this section: