---
title: 'Tutorial: Step-by-Step Examples for Configuring Full and Split Tunneling in Access Server'
canonical: https://openvpn.net/as-docs/v3/tutorials/tutorial--extended-full-and-split-tunnel-configurations/
product: Access Server Docs
description: 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.
---

# 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:

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](https://en.wikipedia.org/wiki/Reserved_IP_addresses#IPv4), 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`)

---

Prev: [Tutorial: Configure Full and Split Tunneling in Access Server](https://openvpn.net/as-docs/v3/tutorials/tutorial--full-and-split-tunnel-vpn.md)
Next: [Tutorial: Configure DNS Settings in Access Server](https://openvpn.net/as-docs/v3/tutorials/tutorial--configure-dns-settings.md)
Index: https://openvpn.net/as-docs/llms.txt
