Setting Up OpenVPN on OpenWrt Is Straightforward If You Know Where to Look
I spent three days last year debugging a VPN that kept dropping client connections only to realize the MTU was misconfigured on the gateway side. Happens more often than you'd think. Getting OpenVPN running through the LuCI interface on OpenWrt is genuinely manageable, and once it's working, it's one of those things you set and forget. First thing: make sure you're actually running OpenWrt 21.02 or later. The VPN setup menus changed significantly between versions and a lot of tutorials you'll find online are based on Chaos Calmer from 2015. It won't help you.
Securing Your Network With Openwrt A Stepbystep Guide To Setting Up An Openvpn Server With Luci
Log into your router's web interface and go to Services then OpenVPN. If you don't see that menu option, you probably need to install the package first. Run opkg update from the CLI followed by opkg install openvpn-easy-rsa luci-app-openvpn. That second package gives you the LuCI frontend. Without it you're stuck editing config files by hand, which works but isn't worth the hassle for most people. Once the packages are installed, you'll see the OpenVPN page with a server configuration section. Enable the server, pick a network interface, and choose your tunnel network. The default 10.8.0.0/24 subnet is fine for a single user connecting from home. If you're planning to run multiple remote sites or have a larger number of clients, bump it to a /22 or /20. I use /20 across my setups because I run separate subnets per office location and it saves me from rerouting headaches later. For the key generation, just let it use the defaults. EasyRSA handles everything. The first time you enable the server, LuCI will prompt you to generate the CA certificate, server key, and DH parameters. This can take a few minutes depending on your router's CPU. The Linksys WRT3200ACM crunches through it in about two minutes. A NanoPi R2S with its ARM cores is noticeably slower, maybe eight to ten minutes. Just leave it running.
Pushing routes to clients is where most people get confused. If you want clients to access your local LAN through the VPN, check the box that says "Use custom gateway" and enter your internal subnet, typically 192.168.1.0/24 or whatever your router is using. There's also an option to push a default route that sends all client traffic through the VPN tunnel. Use that if you want full tunneling, skip it if you only need LAN access and want to keep your client's internet traffic going directly through their local ISP. The DNS settings matter more than most guides mention. When you push DNS servers to clients, make sure they're resolvable from the OpenVPN tunnel. I once had a client complain their browser worked for five seconds then stalled because the VPN was pushing Google DNS (8.8.8.8) but the router's forwarding rules didn't allow outbound UDP on port 53 from the tunnel subnet. Pushing your OpenWrt router's IP as the DNS server is usually the cleanest approach since dnsmasq runs locally and respects your firewall rules properly. Client certificates are the next step. LuCI makes this relatively painless compared to manual OpenVPN setups. Go to the Clients section and add a new client. You'll generate a certificate and key pair right there. Download the OVPN file when it's done and give it to whoever needs access. The generated config bundles the CA cert, client cert, client key, and DH params into a single file. Import it on the client device and you're connected.
Get the Full Details
Here's something nobody tells you about client revocation. When someone leaves your organization or you suspect their device is compromised, revoking the certificate through LuCI doesn't automatically push the revocation list to already-connected clients. They stay connected until they disconnect and reconnect, which might never happen if the app runs in the background. The fix is straightforward: go to Services, OpenVPN, then click Rebuild Server. This regenerates the configuration with the updated CRL and restarts the daemon. Do it immediately after revoking a certificate. I learned that the hard way when a contractor still had VPN access three weeks after he left. Firewall configuration is another area that trips people up. OpenWrt should auto-create the necessary accept rules when you enable the server, but verify under Network then Firewall. You want to see an inbound rule on port 1194 (UDP by default) and the OpenVPN interface listed in the WAN zone or your custom VPN zone. If your router sits behind a CGNAT or a carrier-grade NAT setup, port forwarding from your upstream provider becomes necessary. There's nothing OpenWrt can do about that. A /29 or /28 IPv4 block from your ISP is almost always required for this to work cleanly without relying on port forwarding tricks. Performance is usually fine on modern OpenWrt routers. WireGuard would be faster if you were starting from scratch, but OpenVPN over TLS with AES-256-GCM handles typical home broadband speeds without breaking a sweat. The real bottleneck is almost always the client's upstream connection, not the router's encryption throughput. I've seen a GL.iNet GL-MT300N-V2 handle a steady 40 Mbps through OpenVPN without choking, while a heavily loaded RB3011UIACS passes through 80 Mbps comfortably. Your mileage depends on the silicon.
One edge case worth noting: if you're running an existing DHCP server on the tunnel interface and clients report getting IP conflicts after a router reboot, the issue is usually that easy-rsa keeps regenerating keys in /etc/openvpn/easy-rsa and the PKI database gets stale. Deleting the pki directory and rebuilding takes about twenty seconds and resolves it. The generated configs from old certificates still work, but new client registrations after a rebuild need fresh certificates downloaded again. Maintenance is minimal. Check the logs under System then Logging if clients report connection failures. The daemon logs to /var/log/messages and you'll see handshake failures, certificate errors, and route push issues all there. Most problems show up as "TLS Error: unauthenticated response from" or "CERT_VERIFY_FAILED" which tells you exactly what to fix. The whole setup takes about fifteen minutes on a decent router if you've done it before. First time might run closer to forty-five if you're reading the options and thinking through the routing decisions. There's no automation layer that replaces understanding what each field does, unfortunately. LuCI hides the complexity well enough for basic setups but the moment you need split tunneling with specific routes or mssfix adjustments for weird MTU paths, you'll end up editing /etc/config/openvpn directly anyway. That file is well-documented and every setting has a corresponding UCI option, so the jump isn't as rough as it looks.
