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

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:

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.

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.

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:

   Device	IP address
   Access Server (OpenVPN server)	192.168.70.222
   Site-to-site connector (OpenVPN client)	10.0.60.55

   Network	Subnet
   Headquarters	192.168.70.0/24
   OpenVPN virtual network	172.16.0.0/20
   Branch office	10.0.60.0/24

   • 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.

3. Ensure firewalls allow traffic between these networks.

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

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:password "https://192.168.70.222:943/rest/GetAutologin" --output headquarters.conf

        1. 1

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

        2. 2

           Replace 192.168.70.222 with your Access Server IP.

4. Reboot the system.

   • The VPN should connect automatically.

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

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:

   Device	IP address
   Access Server (OpenVPN server)	192.168.70.222
   Site-to-site connector (OpenVPN client)	10.0.60.55

   Network	Subnet
   Headquarters	192.168.70.0/24
   OpenVPN virtual network	172.16.0.0/20
   Branch office	10.0.60.0/24

   • 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.

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

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.

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 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.