Tutorial: Troubleshoot and Optimize VPN Performance in Access Server⁠

Monitor CPU utilization while reproducing the VPN performance issue:

1. Connect to the Access Server console.

2. Run:

   top -1

3. Press 1 to display utilization for each CPU core.

4. Reproduce the slow VPN connection while monitoring the output.

5. Check whether:

   • One core is consistently at or near full utilization.

   • All cores are heavily utilized.

   • The openvpn or Access Server processes are consuming most of the available CPU.

   • CPU utilization remains low while throughput is poor.

6. Press q to quit.

High CPU utilization can indicate that encryption, packet processing, or other Access Server workloads are limiting throughput.

Hardware AES acceleration, commonly identified by the AES New Instructions (AES-NI) CPU feature, can significantly improve AES cipher performance.

1. Run the following to check if your CPU has hardware AES:

   grep -m1 -o 'aes' /proc/cpuinfo

   • Example output:

     aes

2. If aes appears, the CPU supports hardware AES acceleration. AES-256-GCM will generally provide strong performance on this hardware.

3. If aes doesn't appear, a cipher such as CHACHA20-POLY1305 may perform better on the system.

Use OpenSSL to estimate the system’s raw encryption capacity. The test measures cipher throughput only. It doesn't include:

• OpenVPN packet framing.

• Packet identifiers and authentication.

• Tunnel interface processing.

• Context switching.

• Network latency or packet loss.

Therefore, actual VPN throughput will be lower than the OpenSSL result.

1. To test a single process:

   openssl speed -evp aes-256-gcm -seconds 10 -bytes 1420

   This tests AES-256-GCM with 1,420-byte buffers for 10 seconds.

2. To test multiple CPU cores:

   openssl speed -evp aes-256-gcm -seconds 10 -bytes 1420 -multi 2

   • Example output:

     root@openvpnas:~# openssl speed -evp aes-256-gcm -seconds 10 -bytes 1420 -multi 2
     Forked child 0
     Forked child 1
     +DT:AES-256-GCM:10:1420
     +DT:AES-256-GCM:10:1420
     +R:12206839:AES-256-GCM:10.000000
     +R:12292238:AES-256-GCM:10.000000
     Got: +H:1420 from 0
     Got: +F:25:AES-256-GCM:1733371138.00 from 0
     Got: +H:1420 from 1
     Got: +F:25:AES-256-GCM:1745497796.00 from 1
     version: 3.0.13
     built on: Tue Jun  2 19:33:25 2026 UTC
     options: bn(64,64)
     compiler: gcc -fPIC -pthread -m64 -Wa,--noexecstack -Wall -fzero-call-used-regs=used-gpr -DOPENSSL_TLS_SECURITY_LEVEL=2 -Wa,--noexecstack -g -O2 -fno-omit-frame-pointer -mno-omit-leaf-frame-pointer -ffile-prefix-map=/build/openssl-gza1f8/openssl-3.0.13=. -fstack-protector-strong -fstack-clash-protection -Wformat -Werror=format-security -fcf-protection -fdebug-prefix-map=/build/openssl-gza1f8/openssl-3.0.13=/usr/src/openssl-3.0.13-0ubuntu3.11 -DOPENSSL_USE_NODELETE -DL_ENDIAN -DOPENSSL_PIC -DOPENSSL_BUILDING_OPENSSL -DNDEBUG -Wdate-time -D_FORTIFY_SOURCE=3
     CPUINFO: OPENSSL_ia32cap=0xfffa32234f8bffff:0x1c07ab
     AES-256-GCM    3478868.93k

     1. 1

        -multi 2 spawned two independent workers, one per core (Forked child 0, and Forked child 1).

     2. 2

        This means Child 0 encrypted 12206839 buffers of 1420 bytes in 10 seconds.

     3. 3

        This means Child 1 encrypted 12292238 buffers of 1420 bytes in 10 seconds.

     4. 4

        This means Child 0 processed 1733371138 bytes/s = 12206839 x 1420 = ~17.33GB in 10s (1.733GB/s).

     5. 5

        This means Child 1 processed 1745497796 bytes/s = 12292238 × 1420 = ~17.45GB in 10s (1.745GB/s).

     6. 6

        The aggregate cipher throughput reported in units of 1000 bytes/s (k = 1000 here, not 1024). So this is 3478868930 bytes/s — and it's simply the sum of the two children (1.733 GB/s + 1.745 GB/s).

   • Conclusion:

     Per core: ~1.73 GB/s ≈ 13.9 Gbit/s

     Both cores (aggregate): ~3.48 GB/s ≈ 27.8 Gbit/s

     This CPU can encrypt ~14 Gbit/s on a single core

   • The result indicates that raw AES encryption capacity is unlikely to be the bottleneck at substantially lower VPN speeds.

Access Server can run multiple VPN daemons to use the available CPU cores.

1. Connect to the Access Server console and get root privileges.

2. Check the number of CPU cores:

   sacli GetNCores

   • Example output:

     2

3. Check the configured VPN daemons:

   sacli ConfigQuery | grep "n_daemons"

   • Example output:

       "vpn.server.daemon.tcp.n_daemons": "2",
       "vpn.server.daemon.udp.n_daemons": "2",

4. The configured number of TCP and UDP daemons should generally match the number of available CPU cores. To set both values to the detected CPU core count:

   sacli --key "vpn.server.daemon.tcp.n_daemons" --value "`sacli GetNCores`" ConfigPut
   sacli --key "vpn.server.daemon.udp.n_daemons" --value "`sacli GetNCores`" ConfigPut

5. Restart the Access Server services:

   sacli start

6. Repeat the performance test after the restart.

Data Channel Offload (DCO) moves OpenVPN data-channel processing into the operating-system kernel, reducing context switching and improving VPN throughput.

For background information, refer to OpenVPN Data Channel Offload (DCO).

1. Verify that DCO is active and used by Access Server:

   sacli support | grep ovpn-dco

   • Example output:

     ovpn-dco availability: True, ovpn version: ovpn-net-next/main-7.0.0-rc4-48671cb

2. The output should report that DCO is available.

3. Verify the DCO interfaces:

   ip -details link show | grep ovpn

   • Example output:

         ovpn addrgenmode random numtxqueues 1 numrxqueues 1 gso_max_size 65536 gso_max_segs 65535 tso_max_size 65536 tso_max_segs 65535 gro_max_size 65536
         ovpn addrgenmode random numtxqueues 1 numrxqueues 1 gso_max_size 65536 gso_max_segs 65535 tso_max_size 65536 tso_max_segs 65535 gro_max_size 65536
         ovpn addrgenmode random numtxqueues 1 numrxqueues 1 gso_max_size 65536 gso_max_segs 65535 tso_max_size 65536 tso_max_segs 65535 gro_max_size 65536
         ovpn addrgenmode random numtxqueues 1 numrxqueues 1 gso_max_size 65536 gso_max_segs 65535 tso_max_size 65536 tso_max_segs 65535 gro_max_size 65536
         ovpn addrgenmode random numtxqueues 1 numrxqueues 1 gso_max_size 65536 gso_max_segs 65535 tso_max_size 65536 tso_max_segs 65535 gro_max_size 65536
         ovpn addrgenmode random numtxqueues 1 numrxqueues 1 gso_max_size 65536 gso_max_segs 65535 tso_max_size 65536 tso_max_segs 65535 gro_max_size 65536

4. Depending on the installed Access Server and DCO version, the interface name may contain ovpn or ovpn-dco.

5. If DCO isn't installed or available, refer to Tutorial: Install, Verify, and Troubleshoot OpenVPN DCO in Access Server.

For the best performance, use a client platform and configuration that support DCO. Windows and Linux clients support DCO.

Test the connection using both UDP and TCP.

Use UDP whenever the network permits it. Running a TCP-based application inside a TCP VPN tunnel can create competing retransmission and congestion-control behavior, sometimes called TCP-over-TCP performance degradation. Packet loss can cause throughput to decrease sharply.

TCP on port 443 remains useful on restrictive networks that block or throttle UDP. The recommendation to prefer UDP is about performance, not reachability.

Run the same throughput test:

1. Over a UDP VPN connection.

2. Over a TCP VPN connection.

3. Compare the results.

A substantially faster UDP result can indicate that TCP transport behavior is contributing to the slow VPN connection.

MTR combines traceroute and repeated ping tests. It can help show where packet loss or latency begins along the network path.

1. Install MTR on the client. (On Windows, use WinMTR.)

2. Connect to the VPN.

3. Run MTR against the target resource behind Access Server:

   mtr -rwzbc 100 203.0.113.10

   • Example output:

     Start: 2026-07-13T10:15:02+0000
     HOST: client-laptop            Loss%  Snt  Last   Avg  Best  Wrst StDev
       1. AS12345 192.0.2.1          0.0%  100   1.2   1.4   1.1   3.0   0.3
       2. AS12345 198.51.100.10      0.0%  100   8.5   9.1   8.2  15.0   1.1
       3. AS64500 198.51.100.22     18.0%  100  12.0  12.4  11.8  22.0   1.6
       4. AS64500 203.0.113.9        0.0%  100  12.1  12.6  11.9  20.0   1.4
       5. AS12345 203.0.113.10       0.0%  100  12.3  12.8  12.0  19.0   1.3

4. Interpret packet loss:

   • Don't assume that packet loss reported at a single intermediate hop represents real end-to-end loss.

   • In the example, hop 3 reports 18% loss, but later hops report 0%. This usually means that the router is deprioritizing ICMP responses addressed to itself while continuing to forward traffic normally.

   • Packet loss is more likely to be genuine when it:

     • Begins at one hop.

     • Continues through each subsequent hop.

     • Appears at the final destination.

5. Interpret latency:

   • Review the Avg column.

   • A large increase at one hop that remains relatively stable afterward can represent a normal long-distance or provider transition.

   • Latency that continues increasing across subsequent hops may indicate congestion or another deteriorating condition along the path.

   • High latency reduces responsiveness even when measured throughput is acceptable. Packet loss can reduce both responsiveness and throughput.

The maximum transmission unit (MTU) is the maximum packet size an interface or tunnel can carry without fragmentation.

An MTU mismatch can cause large packets to be fragmented or dropped. This MTU fragmentation may produce poor throughput even when packet loss tests appear normal.

1. Check the VPN interface MTU:

   ip addr | grep mtu|grep as0

   • Example output:

     112: as0t0: <POINTOPOINT,NOARP,UP,LOWER_UP> mtu 1420 qdisc noqueue state UNKNOWN group default qlen 1000
     113: as0t1: <POINTOPOINT,NOARP,UP,LOWER_UP> mtu 1420 qdisc noqueue state UNKNOWN group default qlen 1000
     114: as0t2: <POINTOPOINT,NOARP,UP,LOWER_UP> mtu 1420 qdisc noqueue state UNKNOWN group default qlen 1000
     115: as0t3: <POINTOPOINT,NOARP,UP,LOWER_UP> mtu 1420 qdisc noqueue state UNKNOWN group default qlen 1000

   • In this example, the VPN interface MTU is 1420. For information about changing this setting in the Admin Web UI, refer to VPN Server — MTU settings.

2. Find the largest packet that doesn't fragment:

   • On a Linux client:

     ping -M do -s 1472 <target>

   • On a Windows client:

     ping -f -l 1472 <target>

3. If the test fails because fragmentation is required, reduce the payload size until the ping succeeds.

• For IPv4 ICMP:

  • Total packet size = ICMP payload + 8-byte ICMP header + 20-byte IP header

  • For example:

    • 1500 = 1472 + 8 + 20

• For TCP over IPv4:

  • MTU = TCP payload + 20-byte TCP header + 20-byte IP header

  • The TCP payload limit is called the maximum segment size (MSS).

  • For an MTU of 1500:

    • MSS = 1500-20-20

    • MSS = 1460

Cloud providers often limit network performance based on the virtual-machine size or service tier.

Review your provider's documentation for:

• Maximum ingress and egress bandwidth.

• Burst bandwidth limits.

• Per-instance packet-processing limits.

• Shared versus dedicated CPU resources.

• Additional bandwidth charges.

• Regional or inter-zone transfer constraints.

Ensure that the Access Server instance size supports the expected number of users and aggregate VPN throughput. A smaller instance may reach its provider-imposed network limit even when CPU usage appears low.

iperf3 is a useful tool for measuring network throughput because it avoids disk, browser, and web-server performance variables.

The following tests isolate different parts of the connection:

1. Client to the Access Server public IP, outside the VPN.

2. Client to the Access Server VPN IP, through the tunnel.

3. Client to a target resource behind Access Server.

Comparing the results helps identify where throughput decreases. This example assumes the client is a Linux machine.

A file download provides an additional real-world throughput test.

1. Connect to the console (root privileges aren't required, as we use a non-privileged port).

2. On Access Server, create a 1GB file and serve it:

   mkdir ~/tmp-web-server/
   cd ~/tmp-web-server/
   dd if=/dev/zero of=./file1gb.dd bs=1M count=1024

3. Serve the directory over TCP port 8080:

   python3 -m http.server 8080

   • Ensure that:

     • Port 8080 is allowed through the applicable firewall or cloud security group.

     • Access is limited to the required test client where possible.

     • No other service is using the port.

4. Test outside the VPN by downloading the file from the client:

   wget http://<server-ip>:8080/file1gb.dd

5. Record the reported download speed.

6. Test through the VPN by connecting the client to the VPN and running:

   wget http://<vpn-internal-server-ip>:8080/file1gb.dd

7. Compare the results.

8. After testing, stop the Python HTTP server on the Access Server by pressing Ctrl+C.

9. Remove the temporary file and directory when they're no longer needed:

   rm -rf ~/tmp-web-server

Review the full path between:

• The VPN client.

• Access Server.

• The private target resource.

Where possible:

• Deploy Access Server geographically close to the users.

• Deploy Access Server close to the target resources.

• Avoid routing traffic across unnecessary regions or networks.

• Reduce intermediate gateways, proxies, and inspection devices.

• Use private cloud networking between Access Server and target resources.

• Investigate sustained latency increases or packet loss at provider boundaries.

The best deployment location minimizes the combined network delay between the users, Access Server, and the protected resources.