How to Set Up a Corporate VPN for Secure Remote Work

Setting up a corporate VPN is no longer a luxury reserved for large enterprises — it is a baseline requirement for any company that allows remote work. In 2026, with credential stuffing attacks breaking records and the hybrid model firmly established, protecting traffic between an employee's laptop and internal resources is non-negotiable. In this guide, I will walk you through setting up a corporate VPN from scratch, comparing the most widely used protocols, and explaining when it makes sense to migrate to Zero Trust Network Access (ZTNA).

I have been managing network infrastructure for a distributed team for nearly two years. I started with OpenVPN because it was what I knew, migrated to WireGuard when throughput became a bottleneck, and today I operate a hybrid model with ZTNA for SaaS applications and VPN for access to legacy on-premise systems. The part nobody mentions in tutorials is the work involved in certificate management and access revocation — that is where most DIY setups break in production.

Why your company needs a corporate VPN in 2026

Remote work exposes the company to networks you do not control: home Wi-Fi, coworking spaces, coffee shops. Without a VPN, traffic between the employee's device and internal servers travels in plaintext or relies solely on the application's TLS — which is not always sufficient for sensitive data such as code repositories, databases, or admin dashboards.

According to Fortinet, over 65% of enterprises reported VPN-related security incidents in 2025, typically due to stolen credentials or overly permissive configurations. A VPN alone does not solve everything, but it is the encrypted transport layer that prevents passive interception and man-in-the-middle attacks on untrusted networks.

Beyond security, there is the regulatory aspect. Companies handling European customer data (GDPR) or Brazilian data (LGPD) need to demonstrate that remote access is encrypted and auditable. A properly configured corporate VPN meets both requirements with centralized logging and granular access control.

WireGuard vs OpenVPN: which protocol to choose

The protocol choice is the first relevant technical decision. The two serious contenders in 2026 are WireGuard and OpenVPN. IPSec/IKEv2 still exists but is increasingly restricted to compatibility scenarios with legacy hardware.

According to Palo Alto Networks, WireGuard delivers nearly double the throughput at one-quarter the CPU usage compared to OpenVPN. The reduced codebase also makes security audits easier — less code means a smaller attack surface.

However, WireGuard uses UDP exclusively, which can be blocked by restrictive corporate firewalls. If your employees work from client offices or environments with aggressive firewall policies, OpenVPN running over TCP on port 443 (disguised as HTTPS) may be the only viable option. In January 2026, Mullvad VPN officially deprecated OpenVPN support, signaling the market trend in favor of WireGuard.

Practical recommendation

For most companies, start with WireGuard as the default protocol. Keep an OpenVPN server as a fallback for employees on restrictive networks. This dual approach covers 99% of scenarios without compromising performance.

Step by step: configuring WireGuard as a corporate VPN

I will describe the setup using an Ubuntu 24.04 LTS server in the cloud (AWS, GCP, or any VPS). The process applies to any modern Linux distribution with kernel 5.6 or later.

1. Install and enable WireGuard on the server

WireGuard has been in Ubuntu's official repositories since version 20.04. Installation is straightforward: update system packages, install the wireguard package, and enable IPv4 packet forwarding in sysctl.conf. Then generate the server key pair with wg genkey and configure the wg0 interface in /etc/wireguard/. The configuration file should specify the listen port (usually 51820/UDP), the server's private key, and firewall rules via PostUp and PostDown for NAT masquerading.

2. Configure firewall and network rules

Open UDP port 51820 in the security group or server firewall. Configure iptables to allow forwarding between the WireGuard interface (wg0) and the main network interface. NAT masquerading ensures VPN clients access the internet and internal resources using the server's IP as the source. Do not forget to persist rules with netfilter-persistent so they survive reboots.

3. Generate configurations for each employee

Each device needs a unique key pair. Generate the client's private key, derive the public key, and add a [Peer] block to the server configuration with the assigned IP and the client's public key. On the client side, create the configuration file with the private key, the VPN IP address, and the server's public endpoint. The AllowedIPs parameter defines what goes through the VPN — use 0.0.0.0/0 to tunnel all traffic, or specify only corporate subnets for split tunneling.

4. Distribute configurations securely

Never send WireGuard configuration files via email or Slack — they contain the device's private key. Use a secure channel: in-person delivery via QR code (the WireGuard mobile app supports scanning), or a corporate password manager like 1Password or Bitwarden. Ideally, automate provisioning with tools like Ansible or Terraform to scale without relying on manual distribution.

Multi-factor authentication: the layer you cannot skip

Pure WireGuard uses cryptographic key authentication without native MFA support. To add an extra layer, there are three viable approaches in a corporate environment.

The first is using a wrapper like Tailscale, which runs on top of WireGuard and integrates with identity providers (Okta, Azure AD, Google Workspace) with built-in MFA. The second is implementing certificate-based authentication with periodic rotation, where access depends on both the WireGuard key and a valid X.509 certificate issued by the corporate CA. The third is positioning the VPN behind an authentication portal that validates MFA before allowing traffic into the tunnel.

The most pragmatic approach for small and medium businesses is Tailscale or Headscale (self-hosted alternative). Both abstract WireGuard's complexity and add SSO authentication with MFA, group-based ACLs, and automatic key rotation — all without managing per-employee manual configurations.

When a VPN is not enough: migrating to ZTNA

A corporate VPN operates with a binary trust model: either the user is inside the network (trusted) or outside (untrusted). Once authenticated, the employee usually has broad access to the internal network. This is problematic because if credentials are compromised, the attacker inherits all that access.

ZTNA (Zero Trust Network Access) inverts this model with the principle "never trust, always verify." Instead of placing the user inside the network, ZTNA connects the authenticated user directly to the specific application they need to access — and nothing else. Each request is evaluated in real time considering user identity, device posture, location, and behavioral patterns.

According to Zscaler, ZTNA eliminates the network attack surface by design. If credentials are stolen, access is restricted to the specific authorized application — not the entire network. Additionally, ZTNA removes the bottleneck of backhauling traffic through a central data center, improving performance for cloud applications.

Hybrid model: VPN + ZTNA

In practice, migrating to ZTNA is rarely a clean cut. Most companies adopt a hybrid model during the transition: ZTNA for SaaS and web applications (where it works perfectly), and VPN for access to legacy on-premise systems that depend on network-level connectivity. Solutions like Cloudflare Access, Zscaler Private Access, and Twingate allow gradual ZTNA implementation without shutting down the VPN all at once.

Device management and endpoint security

A VPN protects traffic in transit but does not solve the problem of compromised devices. If an employee's laptop is infected with malware, the VPN tunnel merely gives the malware an encrypted path to internal resources. That is why the VPN needs to be combined with an endpoint security strategy.

MDM (Mobile Device Management) ensures each remote device is enrolled, encrypted, running updated software, and compliant with security policies before accessing corporate resources. Tools like Microsoft Intune, Jamf (for macOS), and Fleet (open source) enforce device posture requirements as a precondition for VPN connection.

EDR (Endpoint Detection and Response) complements MDM with real-time behavioral monitoring. As highlighted by NordVPN, solutions like CrowdStrike Falcon or SentinelOne detect anomalous behavior and can remotely isolate a compromised device before the incident spreads across the corporate network via VPN.

Common mistakes in corporate VPN configuration

After configuring and maintaining corporate VPNs in different contexts, these are the mistakes I see repeated most frequently:

• Not revoking access for former employees: without an offboarding process that includes VPN key revocation, the company keeps doors open for people who are no longer on the team. Automate this by integrating the VPN with your identity directory (AD, Okta).
• Using split tunneling without criteria: split tunneling improves performance by routing only corporate traffic through the VPN, but it also means the device is simultaneously exposed to the public internet. Define clear rules about which subnets go through the VPN.
• Ignoring logs and monitoring: a VPN without centralized logging is a security blind spot. Configure log export to a SIEM and monitor for anomalous patterns such as connections at unusual hours or from unexpected geolocations.
• Static keys without rotation: WireGuard keys that are never rotated accumulate risk. Implement periodic rotation (every 90 days is a good starting point) or use solutions like Tailscale that handle automatic rotation.
• Not testing failover: if the VPN server goes down, all remote employees lose access. Configure at least two servers in different regions with automatic failover via DNS or load balancer.

Conclusion

The corporate VPN remains a fundamental piece of remote work security, even with the rise of ZTNA. The smart choice in 2026 is WireGuard as the default protocol for its superior performance and auditable codebase, combined with MFA via identity provider integration and endpoint monitoring. For companies already operating primarily in the cloud, the natural path is a gradual migration to ZTNA while keeping the VPN as a fallback for legacy systems. What matters most is not which technology you choose, but ensuring that the configuration is maintained, audited, and that access is revoked when necessary — because the best VPN in the world does not protect against a key that should have been deactivated six months ago.