Tutorial: Deploy Access Server on GKE with the Helm Chart⁠

Overview⁠

This tutorial guides you through deploying OpenVPN Access Server on a Google Kubernetes Engine (GKE) Standard cluster using the Access Server Helm chart.

The deployment uses Ubuntu nodes, persistent storage, a regional static IP, and a single mixed-protocol external load balancer that exposes:

TCP 943 for the Admin Web UI and Client Web UI.
TCP 443 for web services and OpenVPN TCP connections.
UDP 1194 for OpenVPN UDP connections.

At the end of the tutorial, you'll have one Access Server pod running in GKE with persistent storage and a stable public IP for VPN and web traffic.

For other Kubernetes platforms, refer to the Kubernetes Helm tutorial. If you'd rather deploy Access Server on a Compute Engine VM instead of Kubernetes, refer to the Google Cloud VM guide.

How the GKE deployment works⁠

The Helm chart creates:

One Access Server pod.
Persistent storage for Access Server data.
A Kubernetes LoadBalancer Service.
One public IP for TCP 943, TCP 443, and UDP 1194.

Because the Service contains both TCP and UDP ports, this is a mixed-protocol load balancer.

This tutorial requires GKE version 1.34.1-gke.2190000 or newer. Versions from 1.34.1-gke.2190000 support the external IPv4 mixed-protocol load balancer used in this tutorial.

Prerequisites⁠

Before you begin, ensure you have:

A Google Cloud project with billing enabled.
Permission to create GKE clusters, Compute Engine addresses, and load balancers in the project.
GKE version 1.34.1-gke.2190000 or newer.
Google Cloud Shell, or a local machine with:
- Google Cloud CLI (gcloud).
- kubectl.
- Helm.
- gke-gcloud-auth-plugin.

This tutorial uses Cloud Shell, which provides the required Google Cloud command-line tools.

Create a GKE Standard cluster with Ubuntu nodes.

This tutorial uses the UBUNTU_CONTAINERD node image. Ubuntu nodes also provide the flexibility to install the Data Channel Offload (DCO) kernel module on the node if your kernel requires it.

Sign in to the Google Cloud console.
Select the project where you want to deploy Access Server.
Select Activate Cloud Shell.
If prompted, select Continue and authorize Cloud Shell.
- A terminal opens at the bottom of the page.
Confirm the active Google account:
```
gcloud auth list
```
Confirm the active Google Cloud project:
```
gcloud config get-value project
```
Set the cluster name and zone.
- For example:
```
CLUSTER_NAME=access-server-gke
ZONE=us-west1-b
REGION=$(echo "$ZONE" | sed -E 's/-[a-z]$//')
```
- Change access-server-gke and us-west1-b for your environment as needed.

Enable the required Google Cloud APIs:

gcloud services enable container.googleapis.com compute.googleapis.com

Create a one-node GKE Standard cluster with the UBUNTU_CONTAINERD node image:

gcloud container clusters create "$CLUSTER_NAME" \
  --zone "$ZONE" \
  --num-nodes 1 \
  --machine-type e2-standard-2 \
  --image-type UBUNTU_CONTAINERD

Configure kubectl to use the new cluster:

gcloud container clusters get-credentials "$CLUSTER_NAME" --zone "$ZONE"

Check the GKE version:

gcloud container clusters describe "$CLUSTER_NAME" \
  --zone "$ZONE" \
  --format='value(currentMasterVersion)'

Ensure the version is 1.34.1-gke.2190000 or newer.

Verify that the node is ready:

kubectl get nodes -o wide

Example output:

NAME                                         STATUS   ROLES    AGE    VERSION                 INTERNAL-IP   EXTERNAL-IP    OS-IMAGE
gke-access-server-gke-default-pool-abc123    Ready    <none>   106s   v1.36.4-gke.1391002   192.0.2.5     203.0.113.5   Ubuntu 24.04.4 LTS

Confirm that:
- STATUS is Ready.
- OS-IMAGE shows Ubuntu.

Reserve a regional static IP in the same region as your GKE cluster.

Using a reserved address keeps the load balancer's public IP stable if the Kubernetes Service changes.

Confirm the region variable:
```
echo "$REGION"
```
- If the variable is empty because you opened a new Cloud Shell session, set it again:
```
REGION=us-west1
```

Reserve a regional static IP named as-ip and store the reserved address in the IP variable

gcloud compute addresses create as-ip --region "$REGION"
IP=$(gcloud compute addresses describe as-ip --region "$REGION" --format='value(address)')

Display the address:
```
echo "$IP"
```
- Example output:
```
203.0.113.15
```

Keep this Cloud Shell session open. Later steps use the $IP variable.

Add the as-helm-chart repository to Helm.

Add the repository:

helm repo add as-helm-chart https://openvpn.github.io/as-helm-chart

Verify that the Access Server Helm Chart is available:

helm search repo as-helm-chart

Example output:

NAME                         CHART VERSION   APP VERSION   DESCRIPTION
as-helm-chart/openvpn-as     0.2.1           latest        A Helm chart for OpenVPN Access Server

Your chart version may differ from the example.

Install Access Server and configure the GKE load balancer.

The deployment uses:

privileged=true so Access Server can use the TUN device and required networking capabilities.
The regional static IP from Step 2.
cloud.google.com/l4-rbs: "enabled" to create a backend service-based load balancer.
externalTrafficPolicy: Local to preserve the original client IP address.

The backend service-based load balancer is required for the mixed-protocol Service that handles TCP and UDP traffic on the same public IP.

Install Access Server with the GKE load balancer settings:
```
helm install my-openvpn-as as-helm-chart/openvpn-as \
 --set securityContext.privileged=true \
 --set service.loadBalancerIP="$IP" \
 --set-string 'service.annotations.cloud\.google\.com/l4-rbs=enabled' \
 --set service.externalTrafficPolicy=Local
```
- The Helm chart creates a Deployment with one Access Server pod and persistent storage.
- The Helm value for the load balancer annotation produces:
```
cloud.google.com/l4-rbs: "enabled"
```
  This tells GKE to use a backend service-based regional external passthrough Network Load Balancer rather than the legacy target-pool implementation.
- externalTrafficPolicy: Local ensures that incoming traffic is sent only to a node with a ready Access Server pod and preserves the original client source IP.

Watch the pod startup:

kubectl get pods -w

Example output:

NAME                                         READY   STATUS    RESTARTS   AGE
my-openvpn-as-openvpn-as-6fc84554b6-rfc2p    0/1     Running   0          41s

Wait until the pod shows:
```
1/1   Running
```
Press Ctrl+C to stop watching.

Watch the Access Server Service:

kubectl get svc my-openvpn-as-openvpn-as -w

Example output:

NAME                         TYPE           CLUSTER-IP      EXTERNAL-IP    PORT(S)
my-openvpn-as-openvpn-as     LoadBalancer   203.0.113.10   203.0.113.15  943:31313/TCP,443:30193/TCP,1194:32206/UDP

Confirm that:
- EXTERNAL-IP displays the regional static IP from Step 2.
- TCP 943 is exposed.
- TCP 443 is exposed.
- UDP 1194 is exposed.
Press Ctrl+C to stop watching.

Verify the Helm installation:

helm status my-openvpn-as

Example output:

NAME: my-openvpn-as
LAST DEPLOYED: Sat Oct 10 15:29:32 2026
NAMESPACE: default
STATUS: deployed
REVISION: 1
DESCRIPTION: Install complete
RESOURCES:
==> v1/PersistentVolumeClaim
NAME                           STATUS   VOLUME                                     CAPACITY   ACCESS MODES   STORAGECLASS   VOLUMEATTRIBUTESCLASS   AGE
my-openvpn-as-openvpn-as-pvc   Bound    pvc-e0c635a1-2a94-47dd-8159-75e0cafb481c   5Gi        RWO            standard-rwo   <unset>                 81s

==> v1/Service
NAME                       TYPE           CLUSTER-IP      EXTERNAL-IP   PORT(S)                                      AGE
my-openvpn-as-openvpn-as   LoadBalancer   203.0.113.10    203.0.113.15  943:32442/TCP,443:31756/TCP,1194:31721/UDP   81s

==> v1/Deployment
NAME                       READY   UP-TO-DATE   AVAILABLE   AGE
my-openvpn-as-openvpn-as   0/1     1            0           82s

==> v1/Pod(related)
NAME                                        READY   STATUS    RESTARTS   AGE
my-openvpn-as-openvpn-as-6fc84554b6-rfc2p   0/1     Running   0          82s

Store the pod name in a variable:

POD=$(kubectl get pods -o name | grep openvpn-as | head -1)

Use the sacli command-line tool to verify the Access Server version:
```
kubectl exec -it "$POD" -- /bin/bash sacli version
```
- Example output:
```
3.2.3 (8444f22d)
```

For more information about sacli, refer to Tutorial: An Intro to the sacli Command-Line Utility.

Use the regional static IP to determine the Admin Web UI URL.

Use the IP variable to display the Admin Web UI URL:
```
echo "https://${IP}:943/admin"
```
- Example output:
```
https://203.0.113.15:943/admin
```
- You'll use this URL after retrieving the temporary administrative password.

The default Access Server administrative username is openvpn. The initial temporary password is written to the Access Server container logs.

Use the pod name variable to find the generated password:

kubectl logs "$POD" | grep -i pass

Example output:

Auto-generated pass = "JaaxMWUlE53b". Setting in db...

Record the temporary password.

If the password doesn't appear in the logs⁠

Set a new password with sacli, replacing <STRONG_PASSWORD> with a strong password:

kubectl exec -it "$POD" -- /bin/bash sacli \
  --user openvpn \
  --new_pass '<STRONG_PASSWORD>' \
  SetLocalPassword

Configure the address that VPN clients use to reach Access Server.

We recommend using a fully qualified domain name (FQDN) with a DNS A record that resolves to your regional static IP. You can also use the static public IP directly.

Configure the address in the Admin Web UI⁠

Sign in to the Admin Web UI.
Select VPN Server.
Under Server Address, enter the EXTERNAL-IP or your domain name in DNS hostname (or IP address).
Select Save and Restart.

Configure the address with sacli⁠

You can also configure the static IP from Cloud Shell.

Ensure the REGION variable is set.
Retrieve the regional static IP again. This ensures $IP is available even if Cloud Shell disconnected after Step 2:
```
IP=$(gcloud compute addresses describe as-ip \
  --region "$REGION" \
  --format='value(address)')
```

Store the pod name:

POD=$(kubectl get pods -o name | grep openvpn-as | head -1)

Set the Access Server hostname/IP value:

kubectl exec -it "$POD" -- /bin/bash sacli --key "host.name" --value "$IP" ConfigPut

Restart the Access Server services:

kubectl exec -it "$POD" -- /bin/bash sacli start

Use this procedure when you no longer need the deployment.

Uninstall the Access Server Helm release:
```
helm uninstall my-openvpn-as
```

Check the regional static IP:

gcloud compute addresses describe as-ip --region "$REGION" --format='value(address,status,users)'

After the load balancer releases the address, its status changes from IN_USE to RESERVED.

If you no longer need the regional static IP, delete it:

gcloud compute addresses delete as-ip --region "$REGION"

Delete the GKE cluster:

gcloud container clusters delete "$CLUSTER_NAME" --zone "$ZONE"

Confirm the deletion when prompted.

Limitations and known issues⁠

The following limitations apply when you deploy Access Server from a container image on GKE:

Failover mode: This feature isn't supported.
Layer 2 bridging: This mode isn't supported.
Fixed license keys: This license model isn't supported. Fixed keys can become invalid because a container deployment doesn't provide a persistent hardware fingerprint.
Data Channel Offload (DCO): DCO depends on the Linux kernel running on the GKE node. Containers use the host kernel, so DCO must be available there.
- Linux kernel 6.16 or newer: Access Server 3.2.0 and newer uses the DCO implementation based on upstream Linux kernel 6.16+. If the GKE node kernel includes DCO support, Access Server can use it without an additional module.
- Linux kernel older than 6.16: Install the DCO module on the Ubuntu GKE node before Access Server can use it. Refer to the DCO tutorial and DCO overview.
Performance: The additional container and Kubernetes networking layers can add latency and overhead. Evaluate performance requirements before using this architecture for heavily loaded deployments.
PAM authentication: Avoid PAM authentication for this deployment because user credentials stored inside the container aren't persistent.
Logs: Access Server sends logs to the container output. Retrieve them with:
```
kubectl logs <POD_NAME>
```

For more information about container deployment behavior, refer to the Docker guide.

Troubleshooting⁠

Submit a support ticket if you need assistance.

Start by checking the pod and Service status:

Check the Access Server pod:
```
kubectl get pods
```
If the pod doesn't start or become ready, describe it:
```
kubectl describe pod <POD_NAME>
```
Review its logs:
```
kubectl logs <POD_NAME>
```
For load balancer problems, inspect the Service and its events:
```
kubectl describe svc my-openvpn-as-openvpn-as
```

Use the following common issues to identify the next step.

Issue	Cause or resolution
`ErrImagePull`	Kubernetes couldn't retrieve the Access Server container image. Verify the image is available and that outbound network access works.
`CrashLoopBackOff`	Verify the pod is running with `privileged` access and can use `NET_ADMIN` and `/dev/net/tun`.
`LoadBalancerMixedProtocolNotSupported`	Ensure the cluster is running GKE `1.34.1-gke.2190000` or newer and that the Service includes `cloud.google.com/l4-rbs: "enabled"`.
Service `EXTERNAL-IP` stays `<pending>`	Describe the Service and review its Events section. Verify the regional static IP, GKE version, and backend service-based load balancer configuration.
`kubectl get nodes` returns `No resources found`	Verify that you created a GKE Standard cluster rather than an Autopilot cluster and that `kubectl` is using the intended cluster context.
Pod remains `Pending`	Verify that the node has sufficient CPU and memory and that the persistent volume can attach.
Pod stays `0/1` Running for more than five minutes	Check the pod events and logs. Verify `privileged`, `NET_ADMIN`, and `/dev/net/tun` access.
Client connects, but the connection profile contains a private IP	Configure the public hostname or regional static IP in Step 8, then issue an updated connection profile as needed.

For additional Google Cloud troubleshooting, refer to the GCP FAQ.

Tutorial: Deploy Access Server on GKE with the Helm Chart⁠

Overview⁠

How the GKE deployment works⁠

Prerequisites⁠

Limitations and known issues⁠

Troubleshooting⁠

Related resources⁠

Was this information helpful?