✕
Eval Contact

Have any questions?

1-877-991-1809
[email protected]
✕
Partner Portal
Eval Contact
Skip to main content
Print

SSL VPN

Overview

A SSL based VPN can run in TAP and TUN mode. TAP mode work in L2 layer and TUN mode work in L3 layer.

In ZWAN configuration, VPN can be created in TAP mode to support configurations such as SITE to SITE with an option to assign an IP address so that it has the flexibility to run either in L2 or L3 layer. By creating an Ethernet (Layer 2) connection between the two LANs, in addition to routing, bridging, bonding, VLAN are also possible over the VPN Tap interface.

In order to establish VPN connection between two endpoint, both X509 CA Certificate (a common certificate) and then host specific certificate are imported. One end works in Server mode and another end works in Client mode. Server listen on a particular Local IP:Port and Client connects the Server IP (Remote IP):Port from a Local IP. The overlay protocol for VPN tunnel could be either TCP or UDP. The underlay data transferred over the tunnel can be encrypted and compressed.

ZWAN also supports creating the VPN in TUN mode to support configurations such as SITE to MOBILE or more commonly known as Road Warriors.

Functionality

Authentication

x509 Certificate based authenticaton

SSL VPN is mutual authentication. Server authenticates Client and vice versa. Server can accept any Client connection as long the both use same CA certificate and the Host certificate are generated and signed by the same CA certificate. Additionally, peer connection can be filtered based on Certificate Common Name (CN).

Important note: If the CA private key (and Cert) is compromised, then malicious user can generate host certificate using the CA certificate and get into the RSA infrastructure. If the CA private key is compromised, then it must the deleted from all the ZWAN Controller. If the host private key is compromised, then it must the added to the CRL (discussed in detail in X509 section)

Pre Shared Key authentication

Pre-Shared Key (PSK) is a client authentication method that uses a string as a passphrase of printable ASCII characters, to generate unique encryption keys for each remote VPN client. PSK is not the default authentication method when creating a VPN tunnel endpoit, x509 is the standard and stronger. Make sure both side has same PSK.

LDAP

LDAP (Lightweight Directory Access Protocol) acts as a central directory service for OpenVPN, allowing it to verify user credentials against an existing user database instead of relying on local accounts on the OpenVPN server. This offers several advantages:

  • Centralized Management: User accounts and permissions are managed in one place, simplifying administration and reducing the risk of inconsistencies.
  • Scalability: LDAP can handle a large number of users efficiently, making it suitable for growing organizations.
  • Integration: OpenVPN can seamlessly integrate with existing directory services like Active Directory, OpenLDAP, or FreeIPA.

OAUTH

OAUTH (Open Authorization) offers a more distributed approach for OpenVPN authentication. Instead of directly verifying usernames and passwords, OpenVPN acts as an OAUTH client. It interacts with an OAUTH provider on the zWAN Director to handle user authentication.

OAUTH_MFA

OAUTH (Open Authorization) offers a more distributed approach for OpenVPN authentication. It interacts with an OAUTH provider on the zWAN Director to handle user authentication with additional Multi Factor Authentication support

Supported Encryption

  • AES-256-CBC
  • AES-256-GCM

Compression

LZO real-time compression algorithm is used; data is compressed in an adaptive manner.

SITE-TO-SITE Tunnel:

Configuration Parameters:

  • When configured as server role, specify local ISP IP address and local port;
  • whereas in Client role, specify local ISP IP, and remote (server) ISP IP or Hostname and Port.
  • The port must be unique and should not be conflict with other VPN tunnel configuration in the same edge controller.
  • The supported authentication types are X509 and PSK
  • Peer mutual authentication will be based on either X.509 Certificate or Pre Shared Key (PSK)
  • When X509 authentication is choosen, peer connection can be filtered based on Certificate Common Name (Remote-CN)
  • PSK can be generated from UI. Use the same PSK both side (by copy/paste).
  • User can enter their PSK or Generate a new one in SSLVPN/IPsec creation menu itself.
  • One to One supported with both PSK and x509 certificates
  • One to Many supported with x509 certificates
  • Refer openvpn manpage for any optional custom parameters.

Create Tunnel

tunnel

Authentication Types

tunnel

Generate PSK:

tunnel

Edit Tunnel

tunnel

Connected Clients

The connected clients can be viewed by clicking the Connected clients icon respective to each tunnel

tunnel

SITE-TO-MOBILE Tunnel:

Configuration Parameters:

  • Can be configured only in a Server role. Please select the local IP address and local port;
  • The port must be unique and should not be conflict with other VPN tunnel configuration in the same edge controller.
  • Peer mutual authentication will be based on either X.509 Certificate or LDAP or OAUTH or OAUTH_MFA
  • Only UDP protocol is supported in this mode
  • When X509 authentication is choosen, peer connection can be filtered based on Certificate Common Name (Remote-CN)
  • OAUTH configuration is added at a Director level for each user. The Client ID and Client Secret needs to be provided. Multiple endpoint url tokens can be provided.
  • When using LDAP, provide the LDAP URL and appropriate values in the fields specified

Create Tunnel

tunnel

Authentication Types

tunnel

  • LDAP

tunnel

  • OAUTH

tunnel

  • OAUTH_MFA

The Remote Endpoint URL or OAUTH Provider Token URL is the address of your Identity Provider or the Reverse Proxy that handles the secure (TLS) connection. The Redirect URI is the URL of that same Reverse Proxy, or alternatively, the EC default OpenVPN Auth port (http://:9000). If you're using local self-signed certificates for testing, you don't need to specify a Redirect URI, as it will automatically default to https://:9000. When neither reverse proxy nor local self signed certificates are used, it will default to HTTP connection which is not recommended, other than for testing purposes. When a reverse proxy is in use, it terminates the TLS connection for both URLs before forwarding traffic to the Identity Provider and the EC Authentication port. It is highly recommended to use a reverse proxy in production environments.

The CA certificate used by the reverse proxy should be imported on the EC to validate the issuer of the certificate.

Using self-signed certificates can generate security warnings on the Client's browser pages.

tunnel

A sample NGINX Reverse Proxy configuration for a locally hosted Identity Provider and the OpenVPN OAUTH server hosted on the EC

Locally Hosted Identity Provider

server {
  listen 443 ssl;
  listen [::]:443 ssl;

  ssl_certificate <Customer Host certificate>;
  ssl_certificate_key <Customer Host private key>;

  ssl_session_cache shared:le_nginx_SSL:10m;
  ssl_session_timeout 1440m;
  ssl_session_tickets off;

  ssl_protocols TLSv1.2 TLSv1.3;
  ssl_prefer_server_ciphers off;

  ssl_ciphers "ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305:DHE-RSA-AES128-GCM-SHA256:DHE-RSA-AES256-GCM-SHA384";

  error_page 497 https://$host:$server_port$request_uri;

  location / {
    proxy_pass http://<IP address of locallty hosted IDP>:9080/;
    proxy_http_version 1.1;
    proxy_set_header Upgrade $http_upgrade;
    proxy_set_header Connection "upgrade";
    proxy_set_header Host $http_host;
    proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
    proxy_set_header X-Real-IP $remote_addr;
    proxy_set_header X-Forwarded-Host $host;
    proxy_set_header X-Forwarded-Server $host;
    proxy_set_header X-Forwarded-Port $server_port;
    proxy_set_header X-Forwarded-Proto $scheme;

    proxy_buffer_size          128k;
    proxy_buffers              4 256k;
    proxy_busy_buffers_size    256k;
  }
}

OpenVPN OAUTH Server

server {
  listen <TLS termination port to listed on the Reverse proxy server> ssl;
  listen [::]:<TLS termination port to listed on the Reverse proxy server> ssl;

  ssl_certificate <Customer Host certificate>;
  ssl_certificate_key <Customer Host private key>;

  ssl_session_cache shared:le_nginx_SSL:10m;
  ssl_session_timeout 1440m;
  ssl_session_tickets off;

  ssl_protocols TLSv1.2 TLSv1.3;
  ssl_prefer_server_ciphers off;

  ssl_ciphers "ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305:DHE-RSA-AES128-GCM-SHA256:DHE-RSA-AES256-GCM-SHA384";

  location / {
    proxy_pass http://<IP of the Edge controller>:9000/;

    proxy_set_header Host $host;
    proxy_set_header X-Real-IP $remote_addr;
    proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
    proxy_set_header X-Forwarded-Proto $scheme;
    proxy_set_header X-Forwarded-Host $host; # Crucial for some apps
    proxy_set_header X-Forwarded-Port $server_port; # Crucial for some apps

    proxy_http_version 1.1;
    proxy_set_header Upgrade $http_upgrade;
    proxy_set_header Connection "upgrade";

    proxy_buffer_size          128k;
    proxy_buffers              4 256k;
    proxy_busy_buffers_size    256k;
  }
}

Export Client Profile .OVPN File

The .ovpn file can then be imported into the OpenVPN Connect. Click on "Export Client Profile" in the options

tunnel

Selecting a certificate selection is not mandatory and is used for additional protection if need be.

tunnel

The downloaded .ovpn file can be uploaded to the OpenVPN Connect Application

tunnel

Edit Tunnel

tunnel

Connected Users

The connected users can be viewed by clicking the Connected clients icon respective to each tunnel

tunnel

Tunnel Info:

Here,

  • VPN tunnel can be enabled/disabled
  • VPN tunnel can be deleted
  • ADD IP or VLAN to the tunnel interface for Site-To-Site Tunnels

tunnel

Expected behaviour in the system:

Once VPN tunnel is successfully created, it will create VPN tap or tun interface, example VPN00.

  • The VPN tap interface can be used for Bond, Bridge or can assign IP. VLAN can be created on top of VPN Tunnel interface.
  • The VPN tun interface the base IP of the DHCP subnet is automatically assigned and it will act as the DHCP server for all Mobile clients

VPN tunnel interface status

VPN interface has the follownig states:

  • WAIT -- Waiting for initial response from server/client.
  • AUTH -- Authenticating with server.
  • CONNECTED -- Initialization Sequence Completed.
  • RECONNECTING -- A restart has occurred.
  • CONNECTING -- OpenVPN's initial state.
  • EXITING -- A graceful exit is in progress.
  • DOWN -- SSL VPN is disabled

SSLVPN Color Status in UI:

  • GREEN: WAIT, AUTH, CONNECTED, RECONNECTING
  • RED: CONNECTING, EXITING
  • GRAY: DOWN

CrossLink Failover for SSL VPN tunnels

When SSLVPN Site-To-Site tunnels in Client Mode are assigned affinity to a NetBalancer gateway, cross link failover functionality is enabled by default. When the interface that the SSL VPN tunnel is running on fails or the Net Balancer gateway fails, the SSL VPN tunnel is restarted on another active gateway tunnel belonging to the same Net Balancer branch.

Tunnel Usage

In SDWAN, tunnels are used in Load Balancer. It can work without Load Balancer too. Load Balancer groups multiple VPNs that connects to the same branch. On top of the tunnel functionality its adds Load Balancing and Link fault tolerance to the Branch to Branch connections.

Known Limitation

  • Currently only 99 SSL VPN tunnel can be created per ZWAN controller.
Table of Contents