--- title: 'Tutorial: Create a Site-to-Site Network with Access Server' canonical: https://openvpn.net/as-docs/tutorials/tutorial--site-to-site-network/ product: Access Server Docs description: Create a site-to-site VPN to connect your business networks using Access Server — secure access through an encrypted OpenVPN tunnel. --- # Tutorial: Create a Site-to-Site Network with Access Server ## Overview A [site-to-site VPN](https://openvpn.net/use-cases/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 Notice that the diagram of our example setup includes the following IP addresses and subnets: | 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 | 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 **Configuration \> VPN Settings**. 3. Under **Routing**, and **Should VPN clients have access to private subnets (non-public networks on the server side)?**, click **Yes, using Routing**. 4. Click **Specify the private subnets to which all clients should be given access (one per line)**. 5. Enter the network subnet where your Access Server is located—for our example, 192.168.70.0/24. 6. Ensure that **Allow access from these private subnets to all VPN client IP addresses and subnets** is set to **Yes**. 7. Select **Save Settings** and **Update Running Server**. ## Step 2: Create a site-to-site connector user This user represents the branch gateway. 1. Click **User Management \> User Permissions**. 2. Enter a new username for your OpenVPN client. 3. Click **Allow auto-login**. 4. Click **More Settings**. 5. Select **Local** for the **Auth method**. 6. Enter a new password. 7. Set **Configure VPN Gateway** to **Yes**. 8. Enter the subnet of the remote network of the OpenVPN client into the box for **Allow client to act as VPN gateway for these client-side subnets**—for our example, 10.0.60.0/24. 9. Select **Save Settings** and **Update Running Server**. > **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: | 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. > **Tip** > > Note that we specify a [subnet mask](https://openvpn.net/as-docs/v3/subnet-mask-cheat-sheet.md). 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: > > - [Community Wiki](https://community.openvpn.net/Pages/OpenVPN%20software%20repos) 3. Download the auto-login profile using the Client Web UI or directly with cURL: - **Option 1: Client Web UI:** 1. Open `https://`. 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 ``` Replace `username`/`password` with the site-to-site user credentials. 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](https://openvpn.net/as-docs/common-technical-questions/#6--what-is-ip-forwarding--and-how-do-i-enable-it-on-linux-) 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: | 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. > **Tip** > > Note that we specify a [subnet mask](https://openvpn.net/as-docs/v3/subnet-mask-cheat-sheet.md). 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](https://openvpn.net/as-docs/vpn-destination-issues.md). ## 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](https://openvpn.net/as-docs/v3/user-group-ip-addresses.md). --- Prev: [Site-to-Site and Gateway Configurations](https://openvpn.net/as-docs/tutorials/site-to-site-and-gateway-configurations.md) Next: [Tutorial: Configure Client-Side Subnet Routing in Access Server](https://openvpn.net/as-docs/tutorials/tutorial--client-side-subnets-routing.md) Index: https://openvpn.net/as-docs/llms.txt