OpenVPN Client on Raspberry Pi: Install and Configure

A Raspberry Pi can run a VPN client while continuing to serve files, dashboards, or backups on your home network. The difficult part is not installing OpenVPN; it is understanding which connections change routes when the tunnel starts.

This walkthrough uses Raspberry Pi OS with systemd and a client profile supplied by your VPN administrator or provider. You will install the client, check its network boundaries, and verify startup without accidentally turning the Pi into a gateway for every other device.

Map your Pi's networks before connecting

Write down the Pi's LAN address, default gateway, and the remote networks you actually need. For example, your home LAN might be 192.168.50.0/24, while a private remote service lives in 10.20.0.0/24. Neither should overlap the VPN's tunnel address pool.

Use the Subnet & CIDR Calculator below to inspect those prefixes. Enter the home subnet, confirm its first and last usable addresses, and check that the Pi and gateway belong to it. Repeat for the remote range. This makes overlapping routes visible before they become an intermittent connection problem.

A client connection affects traffic originating on the Pi. It does not automatically protect phones, televisions, containers with independent networking, or other LAN devices. Sharing the connection requires additional forwarding and firewall design, which is deliberately outside this setup.

Keep a local console or a second LAN session available. A full-tunnel profile can change the return route of an SSH connection arriving through another network, even when authentication succeeds normally.

Install the client and protect the profile

Update the operating system through your normal maintenance process, then install OpenVPN. Check the Raspberry Pi documentation for supported OS releases and remote-access setup. Start with a working Ethernet connection if possible so Wi-Fi changes do not complicate troubleshooting.

The following assumes your downloaded profile is called home.ovpn. Review it before running it: OpenVPN profiles can reference scripts or external files, so accept configuration only from a trusted administrator.

sudo apt update
sudo apt install openvpn
sudo install -d -m 700 /etc/openvpn/client
sudo install -m 600 "$HOME/Downloads/home.ovpn" /etc/openvpn/client/home.conf
openvpn --version
ip -br address
ip route

The service profile name will be home, derived from home.conf. Do not retain extra public copies of a profile containing an embedded private key. If it references separate certificates or keys, install those securely too and use absolute paths in the configuration.

Some commercial profiles request a username and password in addition to certificates. Others use certificate authentication alone. Do not add password storage unless your server requires it. An encrypted private key may also require interactive unlocking, which needs planning before unattended startup.

Review routing and authentication settings

The OpenVPN community resources explain the client directives and their version-specific behavior. Preserve the supplied certificate authorities, remote-certificate verification, and modern cipher negotiation. Do not fix a failed handshake by disabling server identity verification.

For a password-authenticated profile, create /etc/openvpn/client/home.auth with two lines: the actual VPN username followed by its password. Use a privileged editor and set permissions to 600. Never paste those values into a ticket, chat, or repository.

These are optional additions to the existing profile, not a complete replacement configuration:

# Use only when the server requires username/password authentication.
auth-user-pass /etc/openvpn/client/home.auth
# Keep credentials out of OpenVPN's process memory after use.
auth-nocache
# Avoid accepting a server-pushed IPv4 default-route redirect.
# Enable these next two lines only for an approved split-tunnel design.
# pull-filter ignore "redirect-gateway"
# route 10.20.0.0 255.255.255.0

A split tunnel sends selected destinations through OpenVPN; a full tunnel aims to send general internet traffic through it. The commented filter ignores matching pushed redirect directives, but it is not a complete privacy policy: other routes, IPv6 settings, and DNS handling still need review.

If you only need a remote NAS, ask the administrator which subnet to route rather than blindly accepting or deleting every pushed option. The companion local printer and NAS routing guide explains how connected LAN routes interact with VPN policy.

Start manually, then enable startup

Test the systemd service before enabling it at boot. Raspberry Pi OS packages normally provide the openvpn-client instance unit shown below. If your installation differs, inspect its packaged units rather than inventing a service file.

sudo systemctl start openvpn-client@home
sudo systemctl status openvpn-client@home --no-pager
sudo journalctl -u openvpn-client@home -b --no-pager -n 60
ip -br address
ip route get 10.20.0.10
ip route get 192.168.50.20
sudo systemctl enable openvpn-client@home

Look for successful initialization in the log, then verify the selected interface for each destination. A tunnel interface appearing is not proof that traffic takes the intended path. Replace the example destinations with actual remote and local hosts you control.

Test an application connection to the remote service, not just ICMP. A server can block ping while accepting HTTPS or SSH. Conversely, successful ping does not prove that your application credentials, share permissions, or firewall rules are correct.

Reboot only after the manual checks pass. Confirm that startup does not wait forever for an interactive password. If troubleshooting remotely, leave your original LAN session open and verify a second session before disconnecting it.

Check DNS, IPv6, and failure behavior

On Linux, receiving pushed DNS options does not necessarily update the system resolver. Integration depends on the client package, resolver service, and any approved helper scripts. Inspect /etc/resolv.conf and, when systemd-resolved is active, use resolvectl status to see the active DNS servers and per-link domains.

Test a public hostname and a private remote hostname independently. If the remote IP works but its name does not, investigate DNS before editing routes. Avoid publishing private hostnames or sensitive query results in support logs.

A full-tunnel IPv4 route does not automatically tunnel IPv6 traffic. Confirm whether your VPN supports IPv6, intentionally blocks it, or leaves it outside the tunnel. Follow your provider's documented approach rather than assuming the presence of tun0 covers both families.

Stopping OpenVPN generally restores ordinary routing; it does not create a kill switch. If continued direct access would expose a sensitive workload, design and test a separate egress firewall with a local recovery path. Review general privacy trade-offs in the VPN & Online Privacy category.

Finally, revisit the subnet planning tool whenever you change routers or travel networks. A new LAN sharing a remote subnet can break an otherwise unchanged profile. Record intended routes, DNS behavior, and a rollback command such as stopping the client service alongside your backup configuration.

Key takeaways

• Verify nonoverlapping subnets before enabling the tunnel, especially when remote access must coexist with local services.
• Protect the client profile and credentials with restricted permissions and preserve certificate verification.
• Test routes and real application connections before enabling unattended startup.
• Treat DNS, IPv6, and failure-time egress as separate checks, not automatic consequences of connecting OpenVPN.