Skip to main content

Tutorial: Create a Site-to-Site Network with Access Server

Abstract

Create a site-to-site VPN to connect your business networks using Access Server — secure access through an encrypted OpenVPN tunnel.

Overview

A site-to-site VPN connects two or more private networks over a secure, encrypted tunnel. This allows devices on separate networks—such as a headquarters (HQ) network and a branch office—to communicate as if they were on the same local network.

In this tutorial, you'll configure a site-to-site (or site-to-branch) VPN using:

  • Access Server hosted on the headquarters network.

  • An OpenVPN client acting as a site-to-site connector on the branch network.

Traffic between the two networks is encrypted and routed through the VPN tunnel.

Prerequisites

  • Access Server installed on a Linux system in the HQ network

  • Internet access and a private IP address for Access Server

  • Port forwarding so Access Server is reachable from the internet

  • A public IP address or DNS record for Access Server

  • Administrative access to:

    • The Access Server Admin Web UI

    • Routers, firewalls, or gateways on both networks

  • Distinct (non-overlapping) subnets for each network

Important

Subnets must differ between the separate networks for site-to-site to work with Access Server.

Example site-to-site setup

Diagram of a site-to-site network with Access Server and an OpenVPN client connector.

Notice that the diagram of our example setup includes the following IP addresses and subnets:

We'll use the IP addresses and subnets for our example procedure. As you set up your site-to-site VPN, use your specific IP addresses and subnets for your devices and networks in the appropriate steps.

Site-to-site VPN data communication traffic flow

How does data communication flow between the connected networks? Click on the images below to follow the traffic flow of data communication. It gives you a visual of what happens when a request from a computer in a branch office reaches an application server at the HQ network, and how that response makes it back. Here’s how the data travels:

Step 1: Allow access to private subnets (HQ side)

This step configures Access Server to route traffic to the HQ private network.

  1. Sign in to the Admin Web UI for your Access Server.

  2. Click Access Controls.

    • The Group and User Access Rules tab displays.

  3. Click the Global Access Rules tab.

  4. Click Route to enable routing.

  5. Ensure Allow access from these private subnets to all VPN client IP addresses and subnets is checked.

  6. Enter the network subnet where your Access Server is located—for our example, 192.168.70.0/24.

  7. Click Save and Restart.

Step 2: Create a site-to-site connector user

This user represents the branch gateway.

  1. Click User.

  2. Click Add New User.

  3. Enter a new username for your OpenVPN client.

  4. Click Save.

  5. Set Allow Auto-login to Enabled.

  6. Set the Auth method to Local.

  7. Set Configure VPN gateway to Enabled.

  8. Enter the subnet of the remote network of the OpenVPN client into the box for Network on the VPN client side—for our example, 10.0.60.0/24.

  9. Click Reset Password and enter a new password.

  10. Click Save and Restart.

    Important

    Ensure your site-to-site connector user has autologin privileges with local authentication.

Step 3: Configure routing on the HQ network

The HQ router must know how to reach the VPN and branch subnets. Add static routes pointing to Access Server's private IP.

  1. Configure your route table to include routes to the additional subnets for devices and networks:

    • For our examples, we added the following static routes:

      • Network 172.16.0.0 with subnet mask 255.255.240.0 through gateway 192.168.70.222.

      • Network 10.0.60.0 with subnet mask 255.255.255.0 through gateway 192.168.70.222.

  2. Refer to your router documentation as needed for adding static routes.

    Tip

    Note that we specify a subnet mask. Most routing equipment prefers subnets defined this way rather than the CIDR format (e.g.,/24, /20, and so on). You can look up tables to easily convert between them.

  3. Ensure firewalls allow traffic between these networks.

Step 4: Install and configure the OpenVPN client (branch side)

Use a Linux system (Ubuntu LTS recommended) as the branch gateway.

  1. Connect to the console for the branch system.

  2. Install the OpenVPN client:

    apt-get install openvpn

    Tip

    If the command doesn't succeed, check if the Linux system has the proper repository. For more details, refer to the instructions for adding it here:

  3. Download the auto-login profile using the Client Web UI or directly with cURL:

    • Option 1: Client Web UI:

      1. Open https://<Access_Server_IP_or_domain>.

      2. Sign in with the site-to-site user.

      3. Download the autologin profile.

      4. Place it in /etc/openvpn/ and rename it (e.g., headquarters.conf).

    • Option 2: Download directly with cURL:

      1. Navigate to the openvpn directory.

        cd /etc/openvpn/

      2. Run the command to download the profile:

        curl -k -u username:password1 "https://192.168.70.2222:943/rest/GetAutologin" --output headquarters.conf

        1

        Replace username/password with the site-to-site user credentials.

        2

        Replace 192.168.70.222 with your Access Server IP.

  4. Reboot the system.

    • The VPN should connect automatically.

Step 5: Enable IP forwarding on the branch gateway

IP forwarding allows the branch system to route traffic between networks.

  1. Check the current status:

    sysctl net.ipv4.ip_forward

    • If the value is 1, IP forwarding is already enabled; proceed to the next section.

    • If 0, enable it.

  2. Run the following command to enable it:

    sysctl -w net.ipv4.ip_forward=1

  3. Apply the changes:

    sysctl -p

  4. Reboot your Linux machine:

    reboot

Step 6: Configure routing on the branch network

Add static routes on the branch router pointing to the site-to-site connector.

  1. Configure your route table to include the additional subnets for the devices and networks:

    • For our example, we added the following static routes:

      • Network 172.16.0.0 with subnet mask 255.255.240.0 through gateway 10.0.60.55.

      • Network 192.168.70.0 with subnet mask 255.255.255.0 through gateway 10.0.60.55.

  2. Refer to your router documentation as needed for adding static routes.

    Tip

    Note that we specify a subnet mask. Most routing equipment prefers subnets defined this way rather than the CIDR format (e.g.,/24, /20, and so on). You can look up tables to easily convert between them.

  3. Branch traffic destined for HQ routes now goes through the VPN.

Step 7: Verify site-to-site connectivity

Confirm bi-directional traffic works as expected.

  1. Run ICMP (ping) tests:

    • From Access Server 192.168.70.222 → branch client 10.0.60.105.

    • From branch client → Access Server

    • From branch client → HQ server 192.168.70.200.

    • From HQ server → branch client.

  2. All tests should succeed.

    Note

    For our tutorial, we suggest verification with ICMP. Ensure it's allowed in the network. You can test with your preferred traffic (TCP, UDP, etc). ICMP is just a suggestion for ease of troubleshooting.

Troubleshooting

If traffic fails in one direction:

  1. Identify the failing path (example: 10.0.60.105 → 192.168.70.200).

  2. Run tcpdump simultaneously on:

    • The branch gateway (OpenVPN client)

    • Access Server

    • The destination host

  3. Observe where packets stop flowing.

Common issues include:

  • Missing or incorrect static routes.

  • Firewall rules blocking "unknown" subnets.

  • Cloud provider security group restrictions.

  • Incorrect LAN/WAN routing on gateways.

For additional diagnostics, see Troubleshoot Reaching Destinations over the VPN Tunnel.

Routing with a cluster setup

Routing for groups is more complicated if you have a cluster setup because each node needs a unique group default subnet. Access Server 2.12.0 and newer supports this use case. Refer to our documentation for details: Group Default IP Address Networks for Access Server.

In this section: