1. Based on OSS software

Access Server is based on open source software. This means you can
create clients for whatever platform or device without restrictions,
develop a UI using the management interface while at the same time
interoperate with all of the more advanced features of OpenVPN AS such
as multi-factor authentication.

2. Challenge/Response authentication

This functionality allows Access Server users to develop their own
authentication modules that can initiate an authentication
challenge/response sequence. This means that the authentication module
can ask the user any number of questions, and get their responses back,
in order to decide whether or not to allow access. All Access Server
clients have integrated support for this functionality, which operates
on top of the existing OpenVPN auth system. This functionality can be
supported by any OpenVPN client, not just the AS clients.

3. Single sign-on capability

By using custom authentication modules it's possible to implement
single-sign on, where signing into the VPN automatically
pre-authenticates the web applications that end-users need to access
through the VPN. For example, the auth module can query an LDAP server
to get authentication status.  If authentication succeeds, it can obtain
a session token from LDAP and transmit it (via the OpenVPN control
channel) to a Python script running on the client, which can then (for
example) set a cookie in the web browser.  This can  all be done in a
few lines of custom code, because the AS makes the LDAP API available to
the customer module, as well as a data transmission API that allows
transmission of arbitrary data to client-side python scripts via the
OpenVPN control channel.

4. Running scripts securely on clients

Access Server has a much more flexible model for client-side script
execution than OpenVPN (OSS). For one, the AS allows scripts to be
pushed to clients, but includes many safeguards (such as script signing)
to prevent abuse of this capability.  AS allows Python scripts to be
pushed to any AS client regardless of what OS it is running. If AS
client is being used, it is guaranteed that a Python 2.6 interpreter is
always available.

Furthermore, it is possible to execute scripts in the context of the
desktop user instead of the root context of the OpenVPN daemon. In fact,
this turns this script-pushing capability into "Secure Application
Delivery". This can also be used for things like single sign-on.

5. MacOS X Keychain and Windows Crypto API integration

AS clients fully support the both MacOS X keychain and Windows Crypto
API for key storage. This feature improves security of AS because no
OpenVPN client configuration file contains the private key. This support
is configuration-free in the sense that the appropriate certificate and
private key are selected by scanning the keystore for keys signed by the
OpenVPN CA cert. From administrator perspective both MacOS X and Windows
keychains look the same, i.e. their differences have been abstracted away.

6. MacOS X integration

There are a number of ways that the AS Mac client goes beyond the
OpenVPN (OSS) client:

1. Full Keychain support
2. Solid support for pushed DNS servers
3. Integration with OS X SystemConfiguration framework for
generating VPN Connect/Disconnect events
4. A real desktop client (instead of a Java applet).

7. Load balancing/failover capabilities

AS is tightly integrated with UCARP for failover. Configuration sync
takes place between the primary and backup nodes, so only a single node
needs to be managed. The backup node will kick in immediately with the
current configuration if the primary node fails.

8. API support

AS has a full XML-RPC API with hundreds of methods that can control and
monitor every aspect of the AS. Even the AS client is fully API driven.
In fact, even the AS web client is simply an Ajax app that interacts
with the OpenVPN backend via a client-side XML-RPC API. This API can be
used for a number of other things.

9. Multi-daemon support

The AS knows how to instantiate multiple OpenVPN daemons on a given box
and load balance between them to get maximum performance from all CPUs.
This is tricky to do with OpenVPN (OSS) by itself.

10.  Adaptive protocol support

AS can be configured to have OpenVPN daemons listening on both TCP and
UDP ports. Further, the client will adaptively try UDP first, then fall
back to TCP if that fails. All this is fully automatic.

11.  Web-free VPN

AS has a mode where all web functionality can be completely disabled on
both server and client. This means AS can be run with only the OpenVPN
TCP and UDP ports open to the internet, and the AS client can be used
without touching a browser. This avoids having to take browser-related
security issues into account.

12. Bundled profiles

Using OpenVPN (OSS) in large deployments can be cumbersome as one needs
to distribute configuration files to clients somehow. Access Server
allows an executable installer to be bound with the client configuration
file for a user. In practice, one can easily generate a DMG installer
for Mac or an MSI installer for Windows that already has the user's
config file attached to it.

13. Universal bundled profiles

Because the Access Server clients allow the user's certificate and
private key to be located in the system certificate store (Crypto API on
Windows or Keychain on Mac), it's possible to make an OpenVPN client
configuration that is universal in the sense that you can give the same
configuration file to every user. This feature, in combination with
bundled profiles, allows one to have a single installer that can be
deployed to all client machines running the same operating system.
Further, there is no security-sensitive information in the installer,
because the profile that is bound to it lacks any private key.

14. CRL support

AS support for CRLs goes beyond what OpenVPN (OSS) offers. One can
modify the CRL file on the fly and the changes take effect immediately.
It's also possible to include CRLs for multiple branches in the cert
chain. In fact the AS will even bump off a user that is already
connected, if a real-time change to the CRL revokes their certificate.

15. Local subnet blocking

This feature allows clients to block off access to the local subnet
except for the gateway.