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

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:

Support: Needs full tunnel access (all traffic goes through the VPN).
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.

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.

Connect to the console and get root privileges.

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

Refresh the Access Server configuration to apply the changes:
```
sacli start
```

Connect to the console and get root privileges.

List the developers group:

sacli --pfilt developers UserPropGet

Example output:

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

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

Connect to the VPN as a user in each group.
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.
(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.

Using Admin Web UI⁠

Sign in to the Admin Web UI.
Click Access Controls.
- The Group and User Access Rules tab displays.
Click New Access Rule.
Add the rule:
- Target: Group
- Group name: Support
- IP address: 0.0.0.0/1
- Reachable via: NAT
Click Save rule.
Add a second rule:
- Target: Group
- Group name: Support
- IP address: 128.0.0.0/1
- Reachable via: NAT
Save and restart the server.

Using CLI⁠

Connect to the console and get root privileges.

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

Refresh the Access Server configuration to apply the changes:
```
sacli start
```

Using Admin Web UI⁠

Click Access Controls.
- The Group and User Access Rules tab displays.
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⁠

Connect to your console and get root privileges.

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"
  }
}

Confirm the output includes:

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

Connect to the VPN as a user in each group.
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.
(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)

Can't find what you're looking for?

Our support team will be happy to assist you.

Contact Support Schedule a Demo

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

Overview⁠

Prerequisites⁠

Scenario 1: Full tunnel is enabled globally⁠

Scenario 2: Split tunnel is enabled globally⁠

Was this information helpful?