Video summary

The VPN that can do everything Wireguard Can't - OpenVPN

Main summary

Key takeaways

Technology

Tech summary (OpenVPN vs WireGuard for “business/large network” use cases)

Why WireGuard may be insufficient for user-access VPN management

WireGuard is often described as limited at the protocol level for enterprise-style features. It lacks support for:

  • Strong certificate-based authentication (no CA / chain of trust model)
  • Username/password authentication options
  • Built-in multi-factor authentication (MFA) such as TOTP
  • Post-quantum key exchange (protocol cannot be expanded)
  • Load balancing across multiple servers (discussed as hard due to the protocol/key model)
  • Role/group based access controls and more advanced firewall policies

Because authentication is essentially based on static public/private key pairs (e.g., curve25519 keys), challenges include:

  • Harder key revocation/rotation (more manual work to revoke keys)
  • Complicated scaling when you need multi-server authority signing for large user populations

OpenVPN advantage: TLS-based ecosystem and flexibility

OpenVPN uses TLS-like key exchange (inherited from TLS), enabling broader authentication methods. It supports multiple authentication methods and combinations, including:

  • Certificates, public keys, usernames/passwords
  • Two-factor authentication (including TOTP)
  • Flexible server-side configuration and pushing settings to clients

The video covers both:

  • OpenVPN Community Edition (open source)
  • OpenVPN Access Server (commercial)

Both can achieve the same core capabilities, with a “nicer UI” in the paid product.


Tutorial / demo focus and steps shown

Scenario: Remote users accessing internal services (not “privacy VPN”)

Example use cases include:

  • Employees/remote users accessing corporate network resources (servers, backups, data integrity)
  • Home users accessing a centralized service such as a media server

Demo 1: MFA with OpenVPN Access Server (paid UI)

Setup

  • OpenVPN Access Server running on Kali Linux (server)
  • A client device also on Kali Linux (user)

Access Server features demonstrated

  • Create a user locally
  • Require MFA
  • Configure TOTP using a QR-code enrollment flow
  • Generate/download client connection profiles
  • Connect successfully using Network Manager on the client

Connection profile behaviors shown

  • Auto-login profile: established after basic credentials and MFA enrollment
  • Non-auto-login profile: requires login each time (depends on security requirements)

Demo 2: Same capability using OpenVPN Community Edition (open source)

Goal

Use username + password + TOTP using only the open-source server.

Manual client configuration

  • Specify server address
  • Use username/password authentication
  • Provide the server certificate
  • Trigger the MFA challenge flow during login

TOTP challenge mechanisms discussed (and why one works with Network Manager)

OpenVPN provides multiple challenge styles:

  1. Static challenge (older method)

    • Client prompts for a static challenge
    • Not compatible with Network Manager in the demo
  2. “Reply/response includes challenge” approach (intermediate method)

    • Works with the demo’s Network Manager setup
    • The video uses this approach with a custom script
  3. Newer approach: CR response

    • More flexible (e.g., can prompt web-based challenges)
    • Mentioned as supported by newer OpenVPN client apps (Windows/macOS/Android)
    • Not fully supported by older Network Manager plugin / older packaged OpenVPN

Custom Python verification flow (key technical detail)

A Python script validates:

  • Correct username/password
  • Then generates a challenge prompt for the user’s TOTP code
  • Finally verifies the provided TOTP using a TOTP library (PIOTP mentioned)

Anti-replay protection

  • Uses a state value described like a JWT-style structure:
    • username + time hashed with a secret
  • The state is included in the challenge so previously used codes can’t be replayed

Demo 3: Certificate authority + hardware token (stronger identity)

Why certs matter vs “static key spreadsheets”

For large user populations, OpenVPN’s certificate approach is presented as more scalable than manually managing many WireGuard keys.

Key elements of the certificate model:

  • Each user can have an individual certificate
  • A certificate authority (CA) signs user certificates
  • Servers trust the CA public key → certificates form a chain of trust
  • Revocation/rotation is easier via certificate lifecycle management

The video claims OpenVPN Access Server includes tooling for this and can interoperate with existing business PKI patterns.

Hardware token MFA example (UbiKey / PIV)

The demo describes a “more secure” MFA flow:

  • The UbiKey stores the certificate and credentials (key material)
  • The user authenticates with a PIN rather than username/password
  • The OpenVPN profile is updated to use the hardware-token certificate
  • Certificate is imported using UbiKey Manager into the token’s slot (PIV slot referenced as slot 9)
  • User connects by entering the token PIN and succeeds

Access control: restricting VPN users to network destinations

Core concept: IP addresses are not identity—OpenVPN bridges identity-to-IP

The video emphasizes:

  • IP address alone isn’t identity unless you can bind it to authenticated users/devices
  • OpenVPN can assign IPs dynamically while maintaining trust that the client is authenticated first

Two approaches described

  1. OpenVPN Community Edition

    • Uses server-side scripting/hooks (shell/Python) on client connect
    • Assigns IP subnet/DNS/routes using logic
    • Then the VPN server firewall enforces policies based on assigned subnets
  2. OpenVPN Access Server (commercial UI)

    • Adds UI-based groups/memberships
    • Tracks assigned IPs and automatically generates firewall / Netfilter rules
    • Supports group-based access rules, per-user overrides, and intergroup connectivity controls

Concrete example shown in Access Server UI

The demo shows:

  • Create a finance group
  • Apply policies:
    • Disable auto-login for the group (force interactive password)
    • Enforce MFA for the group
    • Optionally assign group subnet(s)
    • Add access rules mapping which internal IP ranges/services users can reach

It also demonstrates:

  • Route vs NAT behavior (Access Server is noted as more IPv4/NAT-centric; IPv6 support is doubted)
  • Intergroup connectivity restrictions (rules can prevent/allow group-to-group access)
  • Viewing aggregated rules that apply to a specific user (inherited + direct rules)

Main speakers/sources (as inferred from subtitles)

  • Primary speaker: the channel host/reviewer (name not provided in subtitles; references “my channel” and “I’m taking a look…”)
  • Products/sources referenced:
    • OpenVPN Community Edition (open source)
    • OpenVPN Access Server (commercial product)
    • Comparison baseline: WireGuard protocol
  • No other clearly identified named individuals are mentioned in the subtitles.

Rate this summary

Your feedback will help improve summaries.

Improve this summary

Reprocess with a stronger model when the summary feels incomplete or inaccurate.

Pro

Translate summary in another language

Pro

Ask questions to this video

Chat for follow-up questions, clarifications, and source-backed answers.

Coming soon

Share this summary

Original video