The short answer: OpenVPN Access Server and Pritunl are both self-hosted VPN servers built on the OpenVPN protocol. Access Server decides access per user and per group on a single server, with no feature tiers. Pritunl decides access per server: groups choose which server a user can join, and everyone on that server gets the same routes, with many features reserved for its Premium or Enterprise plans.
Both products are self-hosted VPN servers built around the OpenVPN protocol, and both are administered through a web console. The structural difference is where access is decided. Access Server evaluates access per user and per group, down to protocol, subnet, IP, port, and application domain name. Pritunl decides at the server: groups determine which VPN server a user may connect to, and every user connected to that server receives its full route set. Most differences below follow from that, and from Pritunl's tier structure, which gates a large share of its functionality behind Premium or Enterprise.
At a glance
- Access decision point. Access Server applies per-user and per-group rules to control access to resources, at the global, group, and user levels. Pritunl's groups govern which server a user may connect to. Routes are configured per server, with no user or group scoping. Differentiated access in Pritunl means provisioning separate servers.
- Protocols. Access Server runs OpenVPN over TCP and UDP. Pritunl offers OpenVPN and WireGuard for client connections, and WireGuard or IPsec for site-to-site links, with IPsec site-to-site gated to Enterprise.
- Clients. Access Server has the OpenVPN Connect app on Windows, macOS, iOS, Android, and ChromeOS. The official Pritunl client covers macOS, Windows, and Linux only. There's no official mobile client, and Pritunl's documentation directs mobile users to a third-party OpenVPN client.
- Identity. Access Server is a SAML service provider and authenticates VPN connections against SAML, LDAP, RADIUS, or PAM, with several authentication mechanisms able to run simultaneously. By default, Pritunl uses single sign-on for profile download and console login, then checks the identity provider's API to confirm the user still exists before each connection. An optional server setting requires SSO authentication on every connection. Pritunl has no native LDAP integration; Active Directory is reached through RADIUS.
- Licensing structure. Access Server is a single software product licensed by connection count, with no feature tiers. You can share the connection count across several servers. Pritunl licenses per server with unlimited users and devices, and gates SSO, the REST API, HA, multiple administrators, auditing, and most routing features behind Premium or Enterprise.
- Source availability. Access Server is commercial software built on the open-source OpenVPN protocol. Pritunl publishes its source code, but its repository carries a custom license that restricts commercial use and prohibits distribution of modifications, so it isn't an OSI-approved open-source license.
Tier basis: Pritunl columns describe the most comprehensive tier, Enterprise. Rows note where a capability is not available in all plans. Access Server has no tiers, so its column carries no plan caveats.
Notes on Pritunl's tier structure
Because gating recurs across many rows, the pattern is summarized here rather than repeated:
- Community (free) is a single server and does not include SSO, the REST API, HA or replicated servers, multiple administrators, advanced auditing, device authentication, or most routing features.
- Enterprise-gated: all single sign-on, the REST API, the Python plugin system, device authentication, automatic failover, replicated servers, VXLAN, IPsec site-to-site links, multi-cloud VPC peering, AWS VPC integration, DNS mapping and forwarding, server route NAT control, bridged VPN mode, advanced auditing, multiple administrators, InfluxDB monitoring, and user PIN policy.
- Premium-gated: configuration synchronization, email key distribution, Chromebook support, port forwarding, gateway links and failover gateway links, secondary-authentication bypass, and additional themes.
- Multiple administrators is Enterprise, so Community and Premium are effectively single-administrator.
When to choose Access Server vs. Pritunl
Access Server fits when:
- Different users or groups need different levels of network access from the same server, rather than being separated onto different servers.
- Access must be restricted at protocol, port, or application-domain granularity, not just by subnet route.
- Identity comes from LDAP, or you need the VPN server itself to be the SAML service provider for every VPN connection without a per-server setting or a vendor-specific client.
- Several identity backends must operate at once: one group on SAML, another on LDAP, and service accounts locally.
- Mobile devices are a significant part of the fleet, and a vendor-published mobile client matters.
- You want deployment from a published cloud marketplace image, a virtual appliance, or an airgapped install. Access Server is listed on AWS, Google Cloud, Microsoft Azure, Oracle Cloud, DigitalOcean, and IBM Cloud, and ships as a virtual appliance for VMware ESXi, Hyper-V, and Docker.
- Predictable licensing matters: one product, priced by connection count, with no capability withheld at a lower tier.
- MFA administered inside the VPN product, with a documented account-lockout policy, is a requirement.
Pritunl fits when:
- WireGuard is a required client protocol, or IPsec is required for site-to-site links.
- The deployment model is many small nodes behind a shared MongoDB cluster rather than a smaller number of larger servers.
- Multi-cloud VPC peering across AWS, Google Cloud, and Oracle Cloud, with automated route-table management, is a primary requirement.
- Ubiquiti EdgeRouter or UniFi hybrid-cloud links are part of the topology.
- Per-server licensing with unlimited users and devices suits the commercial shape better than per-connection pricing.
- Device identity binding to a TPM or Apple Secure Enclave, with an admin approval workflow, is a specific requirement.
- Published concurrent-client scale evidence matters. Pritunl documents a 20,000-client test from 2016.
Where the choice is close: basic full-tunnel or split-tunnel remote access for a population that all needs the same access, on desktop platforms, administered by one team. Both do this well. The deciding factors are usually whether access must differ between users on one server, whether mobile clients matter, and whether tiered feature gating is acceptable.
Architectural trade-off
The two products put policy in different places. Access Server is a VPN concentrator that evaluates each user's and group's rules on the server they connect to, so one server can serve many access profiles. Pritunl treats the server as the unit of policy: a server carries one route set, groups decide who may join it, and servers run as nodes that share configuration through a MongoDB database. The points below weigh that difference and test where common claims hold.
Where Pritunl's per-server model can help
- Nodes read shared state from MongoDB, so adding capacity means adding hosts, and Enterprise can replicate a server across hosts for failover.
- Per-server billing with unlimited users means cost doesn't rise with headcount. A large population that all needs the same access can run on a few servers at a predictable price.
- Auditing access is simple: who can reach a network is answered by reading which groups are attached to the server that routes it.
- The same server can offer OpenVPN and WireGuard, so teams can move clients to WireGuard without standing up separate infrastructure.
Trade-offs and claim-vs-reality
- The claim that Pritunl offers "group-based access control" holds for admission, not for scope. Groups decide which server a user joins, but everyone on a server gets its full route set. Pritunl's developer has said the intended way to give groups different routes is to create multiple servers, so each new access profile adds a server to run and, on paid plans, to license.
- "Unlimited users" pricing holds per server. Because differentiated access requires more servers, cost follows the number of distinct access profiles rather than headcount. Access Server prices by concurrent connection and applies per-group rules, including domain-based routing, on one server.
- MongoDB is a required dependency. It's one more stateful system to size, patch, back up, and keep available, and the VPN depends on it. Access Server can run as a single server or as an active-active cluster.
- Per-connection single sign-on is available in Pritunl, but it's an Enterprise feature, it's off by default, and it's a server setting. Without it, connections rely on a cached certificate plus an identity-provider status check.
- Pritunl's full feature set is tied to its own client, which Pritunl describes as offering "full functionality with support for both OpenVPN and WireGuard" on macOS, Windows, and Linux. Mobile users connect through a third-party OpenVPN client, so WireGuard and other client-dependent features don't reach phones and tablets.
- The "open source" label depends on the definition. Pritunl's source is public, but its license restricts commercial use and bars distributing modifications. Organizations whose procurement rules require an OSI-approved license should check this early.
Technology & Solution Components
|
|
OpenVPN Access Server |
Pritunl |
|---|---|---|
|
Technology |
Standalone or clustered software VPN server. Self-hosted; control plane and data plane both on customer infrastructure |
Distributed clustered VPN server. All servers are equal peers with no master and no single point of failure; all coordination, inter-server messaging, and log storage run through a shared MongoDB database. |
|
Tunneling protocols |
OpenVPN over TCP and UDP. Data channel AES-256-GCM by default, ChaCha20-Poly1305 configurable; control channel TLS-Crypt v2 by default |
Client connections over OpenVPN or WireGuard. Site-to-site links over WireGuard or IPsec, with IPsec site-to-site gated to Enterprise. |
|
NAT traversal / relay |
Not applicable — clients connect inbound to the server |
Not applicable — clients connect inbound to the server |
|
IPv6 support |
Not for the server's listening side. Access Server is primarily an IPv4 system and requires an IPv4 address for its OpenVPN daemons to process incoming connections. The tunnels themselves can transport IPv6 packets |
Supported inside the tunnel in three modes — NAT with private IPv6 addresses, a routed IPv6 subnet giving each client a public routable address, and routed subnet with Proxy NDP. All three provide IPv6 internet access to clients including IPv4-only clients. Server-side IPv6 requires an IPv6 interface and address. Fully supported on WireGuard connections |
|
Open source |
Partially — the OpenVPN protocol core is open source and auditable; the Access Server management layer is proprietary |
Marketed as open source, but the repository carries a custom license, not an OSI-approved one. It states the licensee "may not use Software for commercial purposes," that modifications to source code cannot be distributed as derivative works, and that source or binary products cannot be resold or distributed |
|
Supported OS for server install |
Ubuntu LTS, Debian, Red Hat Enterprise Linux, CentOS |
AlmaLinux (primary; full SELinux support), Rocky Linux, RHEL, Amazon Linux (no SELinux profiles), Ubuntu 24.04. All Pritunl development and testing is done on AlmaLinux |
|
Virtual appliances |
VMware ESXi, Microsoft Hyper-V, Docker |
None published |
|
Cloud marketplaces |
AWS, Microsoft Azure, Google Cloud, DigitalOcean, Oracle Cloud, IBM Cloud, Vultr |
None. Pritunl's documentation states directly that it "does not publish any AMIs or marketplace images," and warns that community AMIs bearing the Pritunl name are unverified and could compromise the installation |
|
Offline / airgapped install |
Supported — offline activation via OpenVPN Support with a fixed license key |
Not documented. Every Pritunl server also sends an hourly outbound version-check request to Pritunl's notification endpoint |
|
Client availability |
OpenVPN Connect app on Windows, macOS, iOS, Android, ChromeOS. Linux is not served by the Connect app — Linux uses the OpenVPN 3 Linux client, the open-source openvpn CLI package, or the NetworkManager-openvpn plugin. All OpenVPN-protocol compatible clients, routers, NAS, and other devices can be used. |
Official Pritunl Client on macOS, Windows, and Linux only, with a graphical and a command-line interface; Linux ships separate desktop-GUI and CLI packages. No official mobile client — Pritunl states an official client "is not available on mobile devices but any OpenVPN client can be used," with only the individual profile links working on mobile. Chromebook support is Premium |
|
Profile distribution / enrollment |
Connection profile distributed by file, by server URL, by custom token URL, from the Client Web UI self-service portal, or bundled into a pre-configured OpenVPN Connect installer (Windows and macOS). Global configuration file (.ocfg) predefines profiles, proxies, and preferences for MDM-style mass deployment. |
Profile added by URI or tar file. A configuration sync runs before connecting and before reconnecting, so server-side changes propagate without client changes. Configuration synchronization and email key distribution are Premium |
|
Router / gateway device support |
OpenVPN-compatible routers are supported, and such a device can act as a gateway client for site-to-site or point-to-site routing |
Ubiquiti EdgeRouter and UniFi UDM via Pritunl Link, connecting as static IPsec hosts. Constraint: "Static hosts are not able to automatically pull changes to the link configuration from the Pritunl server." Enterprise |
|
Database |
SQLite by default; MySQL supported |
MongoDB, required. Clustering references a MongoDB replica set; MongoDB Atlas is a documented option |
|
Deployment convenience option |
Access Server Link — browser-based deployment to AWS, Azure, or GCP with automatic DNS and TLS certificate provisioning, managed from Access Server Hub. The admin web interface is proxied through OpenVPN's infrastructure while VPN tunnel traffic continues to flow directly between users and the customer's own server |
Self-hosted only. No Pritunl-operated hosted or orchestrated deployment option |
|
Pricing model |
Based on number of connections. Free tier for a small number of simultaneous connections, a time-limited trial at higher connection counts, incremental add-on connections as usage grows, and a custom price at high connection counts. Single product — no feature tiers; no capability is withheld at a lower price point |
Licensed per server, with unlimited users and unlimited devices at every tier. Community is a single server. Feature availability varies substantially by tier |
Possible Use Cases
|
|
OpenVPN Access Server |
Pritunl |
|---|---|---|
|
Remote access |
Yes, with user- and group-level access control rules |
Yes, over OpenVPN or WireGuard. Access is uniform for all users connected to a given server |
|
ZTNA (per-application access) |
Yes — delivered by the Zero Trust Application Broker (domain routing). DNS queries for permitted domains resolve to a mapped address from an internal pool (100.64.0.0/10 by default) and Access Server DNAT-translates server-side to the real destination, so a client can only resolve and reach the domains its rules permit and never learns the address of anything else. Rules scope globally, per group, or per user, giving per-application grants rather than flat subnet access |
Not in the VPN product. Enforcement is network-level routing only, with no per-application or domain-based brokering. Pritunl sells a separate product, Pritunl Zero, described as a zero trust server providing authenticated access to web applications and SSH — a reverse proxy covering HTTP and SSH only, not a capability of the VPN server |
|
Site-to-site with client as gateway |
Yes — site-to-site and point-to-site routing are documented capabilities |
Yes, via Network Links, which route a subnet behind an OpenVPN client to the server. Pritunl Link additionally peers VPCs across AWS, Google Cloud, and Oracle Cloud in hub-and-spoke or mesh topologies. Enterprise |
|
IoT |
Supported for devices able to run an OpenVPN-protocol client, or reached behind a gateway client |
Any device running an OpenVPN or WireGuard client can connect. No IoT-specific provisioning documented |
Security
|
|
OpenVPN Access Server |
Pritunl |
|---|---|---|
|
User and user-group based granular access control |
Yes — access rules per user and per group. Least privilege at protocol, subnet, IP, or port level, including application domain names. Per-user rules can be layered on top of group rules. Group membership is mapped from RADIUS, LDAP, and SAML during authentication. |
Server-level only. Groups determine which server a user may connect to — "Only users in a group associated with the server will be allowed to connect." Routes are a server-level construct with a network CIDR and a NAT toggle and no user or group scoping field, so every user on a server receives that server's full route set. |
|
Device posture / context checks |
Available, but implemented through post-authentication Python3 scripts rather than a turnkey UI — device registration by MAC address or UUID, application presence and version compliance, and IP allowlisting for location context |
Device identity, not posture. Device authentication binds a device using a TPM or Apple Secure Enclave, with non-extractable keys, plus an admin approval workflow using a four-digit verification PIN. Enterprise |
|
Certificate and key management |
Built-in X.509 certificate authority and PKI with a multi-CA management page in the Admin Web UI, or integration with an external PKI (e.g., SecureW2). Automatic annual CA renewal since Access Server 2.9. |
Pritunl issues user certificates as one of its authentication layers, and resource pooling pre-generates certificates and parameters. CA lifecycle management for the VPN product — rotation, cross-signing, revocation interface — is not documented |
|
Account lockout |
Authentication failure lockout policy — default 3 consecutive failed attempts within 15 minutes, threshold and timeout configurable |
Not documented. No lockout policy, failed-attempt threshold, or rate limit appears in Pritunl's security or documentation pages |
|
Published certifications |
OpenVPN publishes SOC 2 Type 2, ISO/IEC 27001:2022, HIPAA, and GDPR compliance for its business. Access Server also supports running in FIPS mode on RHEL and Ubuntu — a configuration capability, not a CMVP cryptographic module validation |
None published. No SOC 2, ISO 27001, FIPS, or HIPAA claim appears on Pritunl's site or documentation; auditing is described as supporting regulatory compliance generically |
APIs and Integrations
|
|
OpenVPN Access Server |
Pritunl |
|---|---|---|
|
API |
XML-RPC and REST |
REST Enterprise |
|
External systems integrations |
Via post-authentication Python3 scripts, which can implement custom MFA, ZTNA checks, and automated group assignment. Documented MFA plug-in integrations include LastPass and Duo. |
Python plugin system for custom authentication logic. All Enterprise |
User Authentication
|
|
OpenVPN Access Server |
Pritunl |
|---|---|---|
|
SAML |
Yes — SAML SSO for VPN user authentication and for Admin Web UI login. Group mapping from the SAML assertion is performed by a post-authentication Python3 script executed during authentication, rather than by a built-in attribute-mapping UI. The script reads the assertion's group claim and assigns the user to the corresponding Access Server group, so IdP-driven group membership is applied at each login |
SAML covers profile download and web-console login, not tunnel establishment. Per-connection enforcement is a provider-API check instead. SAML providers: Okta, OneLogin, Microsoft Entra ID, JumpCloud, Auth0. Because enforcement is an API existence check rather than an assertion exchange, group changes and de-provisioning propagate through provider API checks rather than a SAML group claim. Enterprise |
|
Other directory authentication |
LDAP, RADIUS (PAP, CHAP, MS-CHAP v2), and PAM against local OS accounts. Local authentication uses SHA256 password hashes in the user properties database. Multiple authentication systems can run simultaneously — one default, with others configured per group or per user |
RADIUS. Active Directory is supported through RADIUS, not LDAP or ADFS. No native LDAP integration. Enterprise |
|
OAuth / OIDC |
Not supported |
OAuth for Google Workspace and Slack. No generic OIDC connector documented. Enterprise |
|
IdP-driven user and group provisioning — mechanism |
Group membership is resolved at authentication time: LDAP and RADIUS group lookups, or SAML group claims read by a post-authentication script, with automated group assignment scriptable at the same point. |
No SCIM and no directory sync. The documented mechanism is a provider-API check at connection time confirming the user still exists and is enabled, plus group-name matching for RADIUS and Active Directory. |
|
MFA / two-step authentication |
Built into the product — MFA via TOTP authenticator apps including Google Authenticator and Duo, with centralized controls in the Admin Web UI to enable, disable, or reset MFA across users. Additional or replacement factors can be implemented in post-authentication scripts. |
Google Authenticator TOTP; push notification via Duo, OneLogin, or Okta; YubiKey; Duo hardware tokens; and a six-digit user PIN combinable with another factor. Pritunl claims "up to five layers of authentication. Including a user certificate, six digit user pin, two-factor authenticator, single sign-on and mobile push authentication." User PIN policy, Duo, and SSO-based push are Enterprise; Premium includes a secondary-authentication bypass option |
|
Periodic re-authentication / session control |
Authentication failure lockout policy as above (default 3 failures in 15 minutes). Session and re-authentication behaviour is configurable through server settings |
No configurable session expiry, maximum session duration, or forced periodic re-authentication setting is documented |
Global Scale, Performance, QoS, Routing
|
|
OpenVPN Access Server |
Pritunl |
|---|---|---|
|
Scalability |
Server clustering for horizontal scale — add nodes rather than resizing a single server. Nodes are distributed by DNS round-robin, all active simultaneously, sharing credentials and certificates and presenting as a single Access Server to users, under a single shared subscription across the cluster. Nodes can be geographically distributed to place servers closer to users. Data Channel Offload performs encryption and decryption in kernel space, multi-threaded across server CPUs, avoiding the user-space round trip; OpenVPN describes order-of-magnitude performance gains. A client does not require DCO to connect to a DCO-enabled server |
Published test of 20,000 concurrent clients across ten VPN nodes and one MongoDB server, sustained eight hours with no errors or disconnects. |
|
Seamless handover on server failure |
Within a cluster, another node picks up load if one node has an outage. Session continues without reauthentication. A separate active-standby failover mode is also available, in which a second standby server takes over — both servers must be on the same LAN |
Automatic failover is Enterprise |
|
Redundancy / high availability |
Active-active clustering and active-standby failover mode, both included in the product rather than gated behind a higher tier |
Replicated hosts should reside on the same local network. Automatic failover, replicated servers, and VXLAN are Enterprise; failover gateway links are Premium |
|
Routing features |
Split tunneling; NAT mode (client-initiated connections only) and Routing mode; site-to-site and point-to-site routing; domain-name-based routing. Zero Trust Application Broker (domain routing) intercepts DNS queries for permitted domains and returns a mapped address from an internal pool (100.64.0.0/10 by default) instead of the real IP, then DNAT-translates server-side to the true destination — so the client never learns the address of anything it is not authorized to reach. |
Split tunneling by route configuration, replacing the default 0.0.0.0/0 with specific subnets. Per-route NAT toggle. DNS mapping of client addresses to .vpn names, DNS forwarding, and a configurable DNS server list. Network mapping remaps an overlapping route to a different subnet of the same size, which require NAT. Server route NAT control, DNS mapping and forwarding, AWS VPC integration, and bridged VPN mode are Enterprise; port forwarding is Premium. |
Admin Access Control & Logging
|
|
OpenVPN Access Server |
Pritunl |
|---|---|---|
|
Logs |
Connection logs recording user identity, IP address, connection duration, and metadata — viewable, filterable, and exportable, with granular per-user activity detail and a real-time connection snapshot for troubleshooting. Remote logging to a local or external syslog server. Reports for performance and usage insight. Instant diagnostic file generation for support cases |
Log messages stored in MongoDB so they can be viewed from any host in the cluster, with fallback to a local file when the database is unreachable. Viewable through the CLI or the web console. No native syslog or remote-logging destination is documented |
|
Administrator audit log |
Yes, via server debug flags written to /var/log/openvpnas.log rather than a dashboard audit view. Logs all activity between Access Server and its configuration databases — who authenticated, which settings they changed, and the source IP. |
Administrator and user audit stored in the database and viewable per user from any host in the web console. Enterprise |
|
Admin access control / multiple administrators |
Two roles: admin and user. Any user account can be elevated to admin, which grants management of the VPN server; multiple administrators are therefore supported. |
Multiple administrators is Enterprise — Community and Premium are effectively single-administrator. |
|
SIEM export |
Remote syslog to an external server |
A local JSON journal file, one audit event per line, rotated across five files. Pritunl describes this as a structured JSON format for SIEM integration, but a customer-supplied log shipper is required — no built-in forwarder, syslog target, or SIEM connector is documented. Enterprise |
Special Claims
Pritunl capabilities with no corresponding functionality in the Access Server.
|
Capability |
Detail |
|
WireGuard client protocol |
WireGuard alongside OpenVPN for client connections. |
|
IPsec site-to-site links |
IPsec as a site-to-site transport, including static-host links to third-party gateways. Enterprise |
|
Multi-cloud VPC peering |
Pritunl Link peers VPCs across AWS, Google Cloud, and Oracle Cloud in hub-and-spoke or mesh topologies, with automated route-table management and link failover. Enterprise |
|
Device authentication bound to hardware |
Device identity anchored in a TPM or Apple Secure Enclave with non-extractable keys, plus an admin approval workflow. Enterprise |
|
Dynamic firewall |
When enabled, the VPN port is not left open to the internet |
|
Dual web-server design |
External Golang process validates path and JSON struct types before forwarding to a localhost-bound internal Python process, with an additional NaCl-signed session token validated by the external process |
|
DNS mapping of connected devices |
Client addresses mapped to .vpn hostnames. Enterprise |
|
Bridged VPN mode |
Layer 2 bridging. Enterprise |
Access Server capabilities with no equivalent in Pritunl's model: per-user and per-group access control at protocol, subnet, IP, port, and application-domain granularity; the Zero Trust Application Broker with DNS interception and server-side DNAT; SAML evaluated at VPN authentication rather than only at profile download; native LDAP and PAM authentication; multiple simultaneous authentication systems selectable per user or group; a documented account-lockout policy; a built-in multi-CA certificate authority with automatic annual renewal and CA cross-signing; a vendor-published mobile client; published cloud marketplace images across seven providers; virtual appliance images for ESXi and Hyper-V; offline and airgapped installation; native syslog export; kernel-space Data Channel Offload; SOC 2 Type 2, ISO/IEC 27001:2022, HIPAA, and GDPR compliance published for the business; and a single-tier product in which no capability is withheld at a lower price point.
Support
|
|
OpenVPN Access Server |
Pritunl |
|---|---|---|
|
Support |
24 x 7 chat, email and ticketing support. Support SLA available. |
Email support and community forums at every tier. Email is routed by issue severity — general, priority, and outage addresses — rather than by subscription tier. No published SLA, no phone support, and no tier-differentiated response-time commitment |
FAQ
What is the main difference between OpenVPN Access Server and Pritunl?
Where access is decided. Access Server applies per-user and per-group rules on one server, down to protocol, port, and domain name. Pritunl decides which server a user may join, and every user on that server receives the same routes.
Is Pritunl a VPN?
Yes. Pritunl is a self-hosted VPN server that supports OpenVPN and WireGuard for client connections, and WireGuard or IPsec for site-to-site links.
Is Pritunl safe?
Pritunl uses the established OpenVPN and WireGuard protocols, and its source code is public. As with any self-hosted VPN, safety depends on how it's configured, patched, and monitored, including the MongoDB database it requires. Features such as SSO, device authentication, and advanced auditing need the Enterprise plan.
Is Pritunl open source?
Pritunl's source code is publicly available, but it's released under a custom license that restricts commercial use and prohibits distributing modifications. That's not an OSI-approved open-source license. Access Server is commercial software built on the open-source OpenVPN protocol.
Does Pritunl have a mobile app?
No. Pritunl's official client runs on macOS, Windows, and Linux. On iOS and Android, Pritunl recommends using any OpenVPN client. Access Server users can install OpenVPN Connect on Windows, macOS, iOS, Android, and ChromeOS.
Can Pritunl give different users different access on the same server?
Not by route. Routes are set per server, so different access levels mean separate servers. Access Server applies different rules to different users and groups on the same server.
Does Pritunl support LDAP or Active Directory?
Pritunl has no native LDAP integration. It connects to Active Directory through RADIUS, using Windows Network Policy Server. Access Server supports LDAP natively, alongside SAML, RADIUS, PAM, and local authentication, and can run several at once.
How is Access Server licensed compared to Pritunl?
Access Server is licensed by concurrent connection, with no feature tiers, and one subscription can be shared across multiple servers and clusters. You can try it free with two connections. Pritunl bills per server with unlimited users and places many features in its Premium and Enterprise plans.
Does Access Server support WireGuard?
No. Access Server runs the OpenVPN protocol over TCP and UDP. If WireGuard is a hard requirement for client connections, Pritunl supports it.
Related posts
- OpenVPN Access Server vs. NetBird: Which Fits Your Team
- OpenVPN Community Edition vs. Access Server: What's the Difference?
- Self-hosted ZTNA with domain routing in Access Server
- Mesh-VPN Trade-Offs: Performance, Ops and Security Guide
- Access Server Link: a self-hosted VPN for AWS, Azure, and GCP
- Access Server or Community Edition?
- Compare OpenVPN products