Google Cloud (GCP) Site-to-Site Business VPN with OpenVPN Access Server

Introduction

In today’s interconnected digital landscape, securing your cloud resources while ensuring seamless internal access is paramount. This comprehensive guide will walk you through setting up a robust Site-to-Site VPN connection between your local network (LAN) and Google Cloud Platform (GCP) using OpenVPN Access Server. Designed for tech-savvy readers and Linux enthusiasts, this tutorial provides a step-by-step approach to establishing a secure, private tunnel, enhancing your network security and cloud connectivity. Dive in to transform your hybrid infrastructure with confidence and precision!

Understanding Site-to-Site VPNs with OpenVPN on GCP

What is a Site-to-Site Business VPN?

A Virtual Private Network (VPN) traditionally creates a secure, private tunnel between an individual machine (like a laptop) and a server. A Site-to-Site Business VPN takes this concept further, establishing a secure, encrypted tunnel directly between two distinct networks – for instance, your corporate Office LAN and a Google Cloud Virtual Private Cloud (VPC). This setup allows devices across both networks to communicate securely as if they were part of the same private infrastructure.

Imagine your company has critical applications or data hosted on Google Cloud. Instead of employees accessing these resources directly over the public internet, a Site-to-Site VPN ensures all traffic flows through a dedicated, encrypted tunnel. While this traffic still traverses the public internet, the encryption within the tunnel safeguards your data from interception, providing a vital layer of network security. All devices on your local network can seamlessly send and receive traffic from your GCP resources, making it an ideal solution for hybrid cloud environments.

Why OpenVPN Access Server on Google Cloud?

Deploying OpenVPN Access Server from the GCP Marketplace simplifies the complex process of setting up a robust VPN gateway. It offers a user-friendly interface for managing connections, users, and routing policies, making it an excellent choice for businesses looking for scalable and reliable cloud connectivity. OpenVPN’s strong encryption standards and flexibility make it a preferred solution for securing communications between diverse network environments, especially when integrating a Linux-based local gateway.

Prerequisites for Your Linux Gateway VPN Setup

Before embarking on this detailed setup, ensure you meet the following essential prerequisites:

Google Cloud Account & Billing

You must have an active Google Cloud account with billing enabled. Without billing, you won’t be able to provision the necessary cloud resources. OpenVPN Access Server typically offers a free tier for a limited number of connections (e.g., 2 free connections), allowing you to test this setup without immediate charges. For this guide, we’ll leverage the free connection tier.

Dedicated GCP Project

To maintain organizational clarity and prevent interference with existing resources, it’s highly recommended to create a new, dedicated project within Google Cloud for this VPN setup. This isolates your VPN infrastructure, making management and potential teardown much simpler.

Linux Machine as Your LAN Gateway

You’ll need a dedicated Linux machine on your local network to function as the gateway. This machine will be responsible for routing all traffic between your local LAN and your GCP VPC via the VPN tunnel. A crucial configuration point here is ensuring that your local LAN subnet and your Google Cloud subnet ranges absolutely do not overlap. Overlapping IP ranges will lead to routing conflicts and prevent the VPN from functioning correctly. For instance, if your GCP subnet is 10.20.0.0/24, your LAN subnet might be 192.168.1.0/24. You can determine your Linux machine’s subnet using:

ip route

Enabling Essential GCP APIs

For Google Compute Engine VM instances to run and for OpenVPN Access Server to deploy successfully, the Compute Engine API must be enabled. This API is fundamental for creating custom VPC networks and provisioning the virtual machine that hosts your OpenVPN Access Server.

Step-by-Step Deployment: GCP Site-to-Site VPN with OpenVPN

Step 1: Crafting Your Custom VPC in Google Cloud

Begin by navigating to your Google Cloud Console. From the left-hand navigation menu, select “VPC Network” and then “VPC networks.” If the Compute Engine API is not yet enabled, you’ll be prompted to do so here. Click on “Create VPC Network.”

Configure your custom VPC with the following settings:

• Name: openvpn-s2s-vpc (or similar)
• Description: (Optional)
• MTU: Set automatically (recommended for simplicity)
• Subnet creation mode: Custom
• Private IPv6 address settings: Leave unchecked

Under “New Subnet,” define its properties:

• Name: openvpn-s2s-subnet (or similar)
• Description: (Optional)
• Region: Select a region near you (e.g., us-east4)
• IPv4 Stack type: IPv4 (single-stack)
• Primary IPv4 range: 10.20.0.0/24 (Crucially, ensure this doesn’t overlap with your local LAN!)
• Private Google Access, Flow logs, Hybrid Subnets: Keep off.

Leave firewall rules unchecked for now; we’ll configure them specifically for OpenVPN later. Set “Dynamic routing mode” to “Regional” and “Best path selection mode” to “Legacy (default).” Finally, click “Create.” You’ll see your new VPC and its associated subnet listed in the console.

Step 2: Deploying OpenVPN Access Server from GCP Marketplace

Head to the OpenVPN Access Server listing on the Google Cloud Marketplace. Review the details, then click “Get Started.” Ensure the correct project is selected, agree to the terms, and click “Deploy.” You may be prompted to enable additional APIs (e.g., Google Config API); allow this to proceed with VM deployment.

You’ll be redirected to the deployment form. We’ll use Terraform-based deployment:

• Deployment name: openvpn-as-gcp (or similar)
• Deployment Service Account: New Account (create a new service account)
• Region and Zone: Match your VPC region (e.g., us-east4, us-east4-a)
• Machine Type: General purpose, E2 series, e2-medium (sufficient for a VPN gateway)
• Boot Disk: Balanced Persistent Disk, 10GB storage
• Network Configuration:
  • Existing Vpc Name: openvpn-s2s-vpc
  • Existing Subnet Name: openvpn-s2s-subnet
  • Subnet Ip Cidr Range: 10.20.0.0/24
  • IP Forwarding: Enable (this is mandatory!)
  • Source IP Range: 0.0.0.0/0 (for initial setup, restrict later in production)
  • OpenVPN Ports: (Leave defaults)

Click “Deploy.” The process will take a few minutes to complete.

Step 3: Accessing the OpenVPN Access Server Admin UI

Once deployed, navigate to the “Details” tab of your deployment. Here you’ll find the Admin Portal URL, your username (typically openvpn), and a temporary, randomly generated password. Save these credentials securely and prioritize changing the password after your first login.

Click the Admin Portal URL. You’ll likely encounter a browser privacy warning due to the self-signed SSL certificate. Click “Advanced” and “Proceed to [IP_ADDR] (unsafe)” to continue. Log in with the provided username and password, then accept the license agreement. You now have access to the OpenVPN Access Server Admin UI.

Step 4: Configuring OpenVPN Access Server for Site-to-Site Routing

To enable proper site-to-site communication, configure the Access Server:

1. Global Access Rules: Go to “Access Controls” > “Global Access Rules” > “IP Addresses and Subnets.” Select “Route” instead of “NAT” and add your GCP subnet (10.20.0.0/24) and your local LAN subnet (e.g., 192.168.1.0/24). Click “Save.”
2. InterClient Communication: Go to the “InterClient Communication” tab and select “allow user-to-user connections.” Click “Save.”
3. Restart Access Server: For changes to take effect, click the “Restart Server” prompt at the top of the Admin UI.

Step 5: Generating and Downloading the OpenVPN Connection Profile

This profile is the key for your Linux gateway to connect to the OpenVPN server. Go to “Users” and click on the openvpn user. Navigate to the “Connection Profiles” tab, then click “New Connection Profile.” In the popup, click “Download” and save the .ovpn file (e.g., profile-userlocked.ovpn) to your local Linux machine’s Downloads directory.

Step 6: Setting Up Your Local Linux Gateway Machine

Your local Linux machine will serve as the physical endpoint for your Site-to-Site VPN.

1. Check Local LAN Subnet and Interface: Open a terminal and run ip route to identify your local LAN subnet (e.g., 192.168.1.0/24), interface (e.g., wlx5091e326480e), and the machine’s IP address (e.g., 192.168.1.11).
2. Install OpenVPN Client:

   sudo apt update
   sudo apt install openvpn -y

3. Go to Downloads Directory: Navigate to where you saved the .ovpn file.

   cd ~/Downloads

4. Connect to OpenVPN Access Server: Execute the command, providing the OpenVPN username and password when prompted.

   sudo openvpn --config profile-userlocked.ovpn

   Important: Leave this terminal window open! The OpenVPN client will continue running in this session. Closing it will terminate the VPN tunnel.

Step 7: Verifying the VPN Tunnel Interface and Routes

Open a *new* terminal window on your Linux gateway (leaving the OpenVPN client running in the first).

1. Check VPN Tunnel Interface:

   ip a | grep tun0

   You should see a tun0 interface, confirming the VPN tunnel is established.

2. Check Routing Table:

   ip route

   Observe entries showing your local LAN subnet, interface, and critically, routes indicating traffic destined for GCP subnets or the OpenVPN server’s public IP using your local LAN interface, and new routes via the tun0 interface.

This confirms your Linux machine has received a VPN tunnel IP (e.g., 172.27.224.2) and the tunnel is active.

Step 8: Enabling IP Forwarding on Your Linux Gateway

For your Linux machine to act as a true site-to-site gateway, it must be able to forward packets between your local LAN interface (e.g., wlx5091e326480e) and the VPN tunnel interface (tun0).

1. Enable IP Forwarding Temporarily:

   sudo sysctl -w net.ipv4.ip_forward=1

   Verify with cat /proc/sys/net/ipv4/ip_forward; it should return 1.

2. Enable IP Forwarding Permanently: Edit the sysctl configuration file:

   sudo nano /etc/sysctl.conf

   Uncomment (remove # from) the line #net.ipv4.ip_forward=1. Save and exit (CTRL+O, Enter, CTRL+X). Apply changes:

   sudo sysctl -p

Step 9: Configuring NAT and Forwarding Rules with iptables

With the OpenVPN tunnel active and IP forwarding enabled, we now configure iptables to manage traffic flow between your LAN and the VPN tunnel. While this tutorial uses NAT for simplicity, a cleaner routed setup with a static route on your local router is preferred for production environments.

First, note your network details (replace with your actual values):

1. Add NAT Rule for Local LAN Traffic: This translates local LAN traffic’s source IP when it’s sent towards GCP through the VPN tunnel.

   sudo iptables -t nat -A POSTROUTING -s 192.168.1.0/24 -d 10.20.0.0/24 -o tun0 -j MASQUERADE

2. Allow Forwarding from LAN to VPN Tunnel:

   sudo iptables -A FORWARD -i wlx5091e326480e -o tun0 -s 192.168.1.0/24 -d 10.20.0.0/24 -j ACCEPT

3. Allow Return Traffic from VPN Tunnel to LAN:

   sudo iptables -A FORWARD -i tun0 -o wlx5091e326480e -s 10.20.0.0/24 -d 192.168.1.0/24 -m state --state RELATED,ESTABLISHED -j ACCEPT

4. Verify NAT Rule:

   sudo iptables -t nat -L POSTROUTING -v -n

5. Verify Forwarding Rules:

   sudo iptables -L FORWARD -v -n

6. Save iptables Rules Permanently: If not already installed, install iptables-persistent:

   sudo apt install iptables-persistent -y

   During installation, select ‘Yes’ to save IPv4 rules. Then, save your current rules:

   sudo netfilter-persistent save

Step 10: Establishing a Static Route in Google Cloud for Your LAN

GCP needs to know how to send traffic back to your local LAN. Create two static routes:

Go to Google Cloud Console > VPC Network > Routes > Create route.

Route 1: To Local LAN Subnet

Click “Create.”

Route 2: To OpenVPN Tunnel Subnet (Crucial for Linux Gateway)

You need a route for the internal VPN tunnel subnet that OpenVPN assigns. Find this subnet by running ip a on your Linux gateway and looking at the tun0 interface’s IP, then determining its subnet (e.g., if tun0 has 172.27.224.2, the subnet is likely 172.27.224.0/20 as configured by OpenVPN).

Click “Create.”

Step 11: Implementing GCP Firewall Rules for LAN-to-GCP Traffic

Now, allow traffic from your local LAN and the VPN tunnel into your GCP VPC. Go to Google Cloud Console > VPC Network > Firewall > Create firewall rule.

Firewall Rule 1: Allow Local LAN to GCP

Click “Create.”

Firewall Rule 2: Allow OpenVPN Tunnel to GCP

Click “Create.”

Step 12: Creating a Test VM Inside the GCP VPC

To verify the VPN tunnel, create a simple VM within your GCP VPC that has only a private IP address. Go to Google Cloud Console > Compute Engine > VM Instances > Create instance.

Under the “Networking” section:

• Leave firewall options unchecked.
• Do NOT check “Enable IP forwarding.”
• Under “Network interfaces,” edit the interface:
  • Network: openvpn-s2s-vpc
  • Subnetwork: openvpn-s2s-subnet
  • External IPv4 address: None (This is crucial to prove traffic routes via the VPN)

Click “Create.” Note down its private IP address (e.g., 10.20.0.3).

Step 13: Verifying Site-to-Site VPN Connectivity

This is the moment of truth! We’ll confirm if your local Linux gateway can reach the private GCP VM via the OpenVPN tunnel.

1. Keep OpenVPN Tunnel Running: Ensure the terminal window where the OpenVPN client is running remains open and shows “Initialization Sequence Completed.”
2. Ping the Private GCP Test VM from the Local Linux Gateway: Open a new terminal on your local Linux gateway and ping the test VM’s private IP:

   ping 10.20.0.3

   If you receive replies, your Site-to-Site VPN is successfully established and functioning!

3. Verify the Route Used for the GCP Private IP:

   ip route get 10.20.0.3

   This command should show that the traffic is routed via your tun0 interface, confirming the VPN tunnel’s active role. You can further confirm the tun0 IP with ip a show tun0.

Production Considerations for a Robust VPN Solution

While this guide gets your Site-to-Site VPN running, consider these improvements for a production environment:

1. Static External IP for OpenVPN VM: Reserve a static external IP address for your OpenVPN Access Server VM in GCP. This prevents the Admin URL and client profiles from breaking if the VM restarts and gets a new ephemeral IP.
2. Restrict Firewall Rules: Tighten GCP firewall rules and OpenVPN Access Server security group settings. Limit Admin UI and SSH access to only known and trusted public IP addresses, rather than leaving ports open to 0.0.0.0/0.
3. Dedicated Linux Gateway: Use a dedicated server machine or a robust router with Linux capabilities for your local site’s gateway instead of a temporary desktop. This ensures higher availability and performance.
4. Routed Setup on Local Router: Instead of relying solely on NAT on your Linux gateway, configure a static route on your local network’s primary router. This “cleaner” routed setup directs traffic for your GCP subnet directly to your Linux gateway’s LAN IP, simplifying network diagnostics and improving performance.
5. Monitoring and Logging: Implement robust monitoring for your OpenVPN Access Server and VPN tunnel status. Configure logging to a centralized system for easier troubleshooting and security audits.

Conclusion

You’ve successfully established a secure Site-to-Site VPN using OpenVPN Access Server on Google Cloud (GCP) with a Linux gateway. This setup ensures that your internal network can privately and securely access resources within your GCP VPC, bypassing direct exposure to the public internet. From VPC creation and Access Server deployment to configuring routes, firewall rules, and enabling IP forwarding on your Linux machine, every step was meticulously covered. By implementing the production notes, you can elevate this secure cloud connectivity solution to enterprise-grade standards, ensuring reliable and secure communication across your hybrid infrastructure.

FAQ

Question 1: What is the primary benefit of a Site-to-Site VPN over a client VPN for businesses?

Answer 1: The primary benefit is that a Site-to-Site VPN creates a persistent, secure tunnel between entire networks (e.g., your office LAN and GCP VPC), providing network-wide access to cloud resources for all devices on your local network without individual client software. In contrast, a client VPN establishes a tunnel for a single device, requiring each user to connect independently. Site-to-Site VPNs are essential for seamless cloud connectivity and managing hybrid environments with enhanced network security.

Question 2: Why is enabling IP forwarding crucial on the Linux gateway machine?

Answer 2: IP forwarding is crucial because it instructs the Linux kernel to act as a router. Without it, the machine would only process packets destined for itself. By enabling IP forwarding, the Linux gateway can receive packets from your local LAN interface (e.g., wlx5091e326480e) and forward them to the VPN tunnel interface (tun0) towards GCP, and vice-versa, effectively routing traffic between the two networks. Without this, traffic cannot traverse the gateway to reach the VPN tunnel.

Question 3: What are common troubleshooting steps if the VPN tunnel isn’t working after setup?

Answer 3: If your Site-to-Site VPN isn’t functioning, check these common areas:

• IP Address Overlap: Double-check that your local LAN subnet and GCP VPC subnet do not overlap. This is a frequent cause of routing failures.
• Firewall Rules: Verify all GCP firewall rules (ingress/egress for LAN, tunnel, and Access Server) and local Linux iptables rules. Ensure necessary ports are open and traffic is allowed between interfaces and subnets.
• GCP Static Routes: Confirm the static routes in GCP correctly point your local LAN subnet and the OpenVPN tunnel subnet to your OpenVPN Access Server VM’s internal IP as the next hop.
• OpenVPN Logs: Review the OpenVPN Access Server logs in GCP and the OpenVPN client logs on your Linux gateway for error messages. These often provide specific clues about connection issues, certificate problems, or routing misconfigurations.
• IP Forwarding Status: Re-verify that net.ipv4.ip_forward is set to 1 on your Linux gateway.

Read the original article