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.
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
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
}
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.