OPNSense VPN Server

Posted inprofessional, technology, work

I deployed an OPNSense router for my home network about a year ago, running on the exceptional Protectli Vault 1610 and could not be more pleased with how everything functions: a definite improvement over the capable-but-no-longer-supported Linksys LRT224.

Unfortunately, establishing VPN capability has not been nearly as straight-forward: OPNSense dramatically revamped the process without removing outdated documentation. Determining what was and what is takes some effort. Web searches and AI queries were no better. My multiple attempts to intuit how to adapt to this new paradigm consistently failed. Until this week.

Finally, OPNSense published up-to-date documentation – though not yet retracting the out-of-date docs – with which I created my VPN server. I thought I should share for those are also struggling.

OPNSense References

Server-Side Configuration

Some nuances or hiccups I ran into which creating my VPN server.

Users

  • User Groups: For successful authentication users must be associated with at least one user group regardless of permissions assigned to the group. Rather than reusing the admins group, I created the new group vpn_user with no permissions assigned.
  • Users: The recommended best practice is to create unique users for each person, server, process, etc. connecting to your local network. Choose the appropriate Group membership for the new user. Privileges can remain Nothing selected.
  • One-Time Passwords: If you desire one-time passwords for extra security, click the OTP seed button to show the QR code that is registered with Google Authenticator.

Certificate and Keys

  • Intermediate CA: The Setup Self-Signed Certificates reference creates an intermediate CA; supported but not necessary and not used in the reference pages.
  • Certificate Issuer: Select your root certificate authority from the Issuer drop-down. If you run a local DNS server, specify your internal network domain name in the DNS Domain Names field.
  • Client Certificate: The Common Name field should match a user’s username for per-user client certificates.
  • Exporting the Certificate Chain: Not required for creating a VPN server. Save yourself the hassle.

One-Time Password

  • Token Length: Must be 6: AFAIK Google Authenticator doesn’t/can’t provide an eight-character token.

VPN Server Instance

  • Server (IPv4): Species the subnet for the VPN clients. Must not overlap existing subnets in your network and should not be routable.
  • Authentication: When implemented, your one-time password access server; otherwise Local Database. VPN clients must always provide username/password, but this just determines whether OTPs are also necessary,
  • String User/CN Matching: Remember the suggestion that the certificate common name for the client matches the username? By selecting, OpenVPN requires that both user and common name match for security purposes.
  • Local Network: One or more subnet masks identifying your local subnets to which the VPN user is allowed access.
  • DNS Domain list: The domain for resolving not fully-qualified host names, necessary when you have an internal DNS server for local resources.
  • DNS Servers: Your local DNS server, if applicable. Otherwise, the public Cloudfare or Google DNS servers are addequate.

WAN Firewall Rules

  • Port 1194 Pass-through: Simple rule that allows OpenVPN traffic to be processed.

VPN Client Export

  • Hostname: Specifies to where the client connects, either a fully-qualified domain name or an IP address. To avoid hard-coding IP addresses, especially if the address is dynamic, use a dynamic DNS resolver such as DuckDNS.
  • P12 Password/confirm: Optional (I believe) but more secure if provided. The VPN client prompts for the password before installing the configuration and connecting to the VPN server.
  • Enable static challenge (OTP): When checked, the user must also provide the code from Google Authenticator during authentication with the VPN server. Otherwise, only username/password authentication occurs.
  • Export: Export your client configuration. The zip archive contains the OpenVPN configuration for the remote client.

Client-Side Configuration

  • VPN Client: On MacOS, OpenVPN Connect did not support all options exported by OPNSense. Instead, I installed Tunnelblink which didn’t complain. NOTE: I did not check that the OpenVPN Connect installed by Homebrew was up-to-date.
  • Exported Configuration: Copy the exported client configuration to your “remote” desktop or server. The folder created when the zip file is expanded contains the OpenVPN profile and CA certificate to be installed into Tunnelblink.
  • Load Self-Signed Certificate Authority: The exported configuration folder contains a file with the suffix .p12 which must be converted into a PEM-encoded file for Tunnelblink using the command openssl pkcs12 -in <client_configuration>.p12 -out ca.crt -nokeys -clcerts. Import ca.crt into Tunnelblink.
  • Load Profile: To install the profile, drag the OpenVPN configuration onto Tunnelblink. Select the configuration, click on Connect, provide your username, password and, optionally, the one-time password.

Server Observability

Navigate to VPN >> OpenVPN >> Connection Status to see what VPN clients are connect. Navigate to VPN >> OpenVPN >> Log File to help debug connection problems.

Final Thoughts

Not too difficult once you find the up-to-date documentation. More importantly, I now can access and maintain my home network when I am away. Wonderful!

Tags: