How to share the same port for VPN and HTTP

Author: Nikos Mavrogiannopoulos

One of the advantages of ocserv is that is an HTTPS-based protocol and it is often used over 443 to allow bypassing certain firewalls. However the 443 TCP port is typically used by an HTTP server on a system. This section will describe two methods on how to collocate ocserv with a web server.

We recommend the first method, as it has no inherent limitations, as opposed to the second which should be considered experimental only.

Method 1: SSL termination on ocserv

haproxy

An method to collocate ocserv and an HTTPS server on port 443, is by using the server name indication (SNI) present on the first SSL/TLS ClientHello message, and forwarding traffic according to the name present.

In the example below we assume that the web server and ocserv have to be setup to use an alternative port, e.g., ocserv uses 4443, and the web server uses 4444. We also assume that the web server responds to www.example.com, while the vpn server, to vpn.example.com. An example configuration of haproxy that will redirect the traffic to the appropriate server is shown below.

frontend www-https
   bind 0.0.0.0:443
   mode tcp
   tcp-request inspect-delay 5s
   default_backend bk_ssl_default

backend bk_ssl_default
   mode tcp
   acl vpn-app req_ssl_sni -i vpn.example.com
   acl web-app req_ssl_sni -i www.example.com

   use-server server-vpn if vpn-app
   use-server server-web if web-app
   use-server server-vpn if !vpn-app !web-app

   option ssl-hello-chk
   server server-vpn 127.0.0.1:4443 send-proxy-v2
   server server-web 127.0.0.1:4444 check

In order for ocserv to obtain information on the incoming session, we have enabled the proxy protocol in haproxy's configuration (with the send-proxy-v2 option). That requires ocserv's configuration to contain the following:

listen-proxy-proto = true

If you are hosting multiple websites on your webserver this alternative configuration may be more suitable for you as it does not require you to have each hostname fully specified (tested on haproxy 2.2 LTS):

defaults
    timeout connect         10s
    timeout client          1m
    timeout server          1m

frontend www-https
   bind 0.0.0.0:443
   mode tcp
   tcp-request inspect-delay 5s
   tcp-request content accept if { req.ssl_hello_type 1 }

   use_backend bk_vpn         if { req_ssl_sni vpn.example.nl }

   use_backend bk_ssl_default if { req_ssl_sni -i -m end .nl  }
   use_backend bk_ssl_default if { req_ssl_sni -i -m end .com }
   use_backend bk_ssl_default if { req_ssl_sni -i -m end .eu  }

   # In case of missing SNI information fallback to the VPN backend.
   # This is needed for older openconnect versions (as present in Ubuntu 18.04 LTS)
   default_backend bk_vpn

backend bk_vpn
   mode tcp
   option ssl-hello-chk
   server server-vpn 127.0.0.1:4443 send-proxy-v2

backend bk_ssl_default
   mode tcp
   option ssl-hello-chk
   server server-web 127.0.0.1:4444 check

sniproxy

An alternative method to collocate ocserv and an HTTPS server on port 443, is by using SNI and forwarding traffic accordingly. This example is identical to the previous, but we use sniproxy.

Sniproxy allows sharing the HTTPS port as long as the clients advertise the host name they connect to using server name indication (SNI). This is true for the majority of web browsers today. For this to work the web server and ocserv have to be setup to use an alternative port, e.g., ocserv uses 4443, and the web server uses 4444. A configuration of sniproxy that will redirect the traffic to the appropriate server is shown below.

listener 0.0.0.0:443 {
   protocol tls
   table TableName

   #we set fallback to be ocserv as older versions of openconnect 
   #don't advertise the hostname they connect to.
   fallback 127.0.0.1:4443
}

table TableName {
   # Match exact request hostnames
   vpn.example.com 127.0.0.1:4443
   www.example.com 127.0.0.1:4444
   .*\\.net    127.0.0.1:4444
}

Method 2: SSL termination on external program

To collocate ocserv and an HTTPS server on port 443, haproxy (or similar proxy applications) could be used. haproxy allows forwarding the HTTPS port data to arbitrary servers, based on various criteria. This method, however, has few limitations based on the fact that ocserv does not "see" the SSL session. * It cannot enforce client certificate authentication. * It cannot derive any keys needed for the DTLS session. * It cannot enforce the framing of the SSL/TLS packets, and that breaks some assumptions of openconnect client.

Nevertheless, it may be useful on certain scenarios.

The configuration required for haproxy is something along the lines:

frontend www-https
    bind 0.0.0.0:443 ssl crt /etc/ocserv/cert-key.pem
    default_backend ocserv-backend

backend ocserv-backend
    server ocserv unix@/var/run/ocserv-conn.socket check

and ocserv must be configured to accept cleartext connections on ocserv-conn.socket file. That can be achieved using the following configuration snippet.

# Accept connections using a socket file. The connections are
# forwarded without SSL/TLS.
listen-clear-file = /var/run/ocserv-conn.socket

Note that in that case ocserv will not have enough information for the client's IP address. That can be fixed by instructing haproxy to provide that information via the Proxy Protocol (supported by ocserv 0.10.7 and later). To enable that feature add to ocserv.conf the following.

listen-proxy-proto = true

In haproxy.conf you need to enable the following options.

backend ocserv-backend
    server ocserv unix@/var/run/ocserv-conn.socket send-proxy-v2 check

You could also enable the haproxy's "send-proxy-v2-ssl-cn" option, if you perform client certificate verification in haproxy and expect ocserv to trust the user name provided by it.