This article describes the Universal Management Suite (UMS) and IGEL Cloud Gateway (ICG) Integration with Network components like Firewalls and Reverse Proxies.

For Reverse Proxy configuration examples, see:

UMS Network Configurations

The diagram shows a network configuration with possible network boundaries where network components like Reverse Proxies, Proxies, Firewalls and Loadbalancer can be placed.


There are typically three different positions for these components:

  • Device and ICG Server
  • Device and UMS Server
  • ICG and UMS Server

Device to ICG / UMS Communication

The communication of the devices to UMS or ICG consists of two different types. Regular HTTPS calls for the device registration and a WebSocket connection with Mutual TLS for device management. These must be considered for Proxy, Reverse Proxy and Firewall configuration.

ICG UMS Communication

The communication of the UMS to the ICG is also based on WebSocket and regular HTTPS calls. Every request is initialized by the UMS and uses Mutual TLS. A HTTPS Proxy can be configured for these connections in the UMS.

In case a Network Component is placed between these servers be aware of these connections. Connection problems could be observed when Deep Packet Inspection (DPI) is activated on a Firewall. The chapter SSL Offloading is only applicable for device to UMS / ICG connections. It is not supported for the communication between ICG and UMS.

SSL Passthrough

SSL Passthrough passes encrypted HTTPS traffic from a client to the server and back again without any decryption or deep packet inspection. The HTTPS traffic is not manipulated so this configuration of network components shouldn’t have any impact on the ICG or UMS functionality. Please refer to the documentation of your Web Component for the appropriate settings.


Example

nginx – one possible configuration of passthrough:

## tcp LB and SSL passthrough for backend ##
stream {
	upsream umsserver{
		server 192.168.1.100:8443 max_fails=3 fail_timeout=10s;
		server 192.168.1.100:8443 max_fails=3 fail_timeout=10s;
	}
	server{
		listen 443;
		proxy_pass umsserver;
		proxy_next_upstream on;
	}
}
CODE

The configuration must be added to the nginx config file:

user nginx;
worker_process auto;
error_log /var/log/nginx/error.log warn;
pid		  /var/run/nginx.ped;
events{
	worker_connections 1024;
}
http {
	include		/etc/nginx/mime.types;
	default_type application/octet-stream;
	sendfile	on;
	#tcp_nopush		on;
	keepalive_timeout 65;
	#gzip on;
	include/etc/nginx/conf.d/*.conf;
}
include/etc/nginx/passthrough.conf;
CODE

SSL Offloading

SSL Offloading means that the network component terminates the SSL connection and decrypts the data. This decrypted data could be sent directly to the Server which also sends decrypted data to the network component which handles the encryption.

The Network component could also inspect the decrypted traffic und encrypt it again before sending it to the server. The UMS supports only this type of communication with encrypted data until now. The diagram shows the required tasks for SSL Offloading on the Network Component for the device to UMS direction.


The Steps to configure SSL Offloading of a Network Component:

  • Configure Listener for SSL Termination. This includes:
    • Port: UMS Web Port
    • Key and Certificate: UMS Web Key and UMS Web Certificate
  • Configure Client Certificate Check and Client Certificate Forwarding. This includes:
    • SSL Client Certificate Check
    • Read SSL Client Certificate and add it to a Forwarded Header
  • If necessary, configure the WebSocket Upgrade Header

The processing of forwarded Client Certificates must be activated on UMS side. The configuration file is 
(Install Dir)/IGEL/RemoteManager/rmguiserver/conf/appconfig/application.yml.

igel:
 client-cert-forwarding:
	enabled: false
	client-cert-forwarded-header: X-SSL-CERT
CODE


Set client-cert-forwarding -> enabled to true.

The forwarding Header can be configured. The X-SSL-CERT Header value can be changed but be aware to change the corresponding value in the network component configuration.
The ICG configuration is analog except for the ICG Port, ICG KEY and ICG Certificate parameters.
The processing of forwarded Client Certificates must also be activated on ICG side.
The configuration file is (Install Dir)/IGEL/icg/usg/conf/application-prod.yml

Required Features of the Network Component

Client Certificate check and forwarding

The OS12 device uses two types of connections to the UMS. One is a direct https connection to onboard the device and get a Client Certificate. The other one is a WebSocket connection for managing the device with mutual TLS.
So, the used Reverse Proxy must at least implement one of the following configuration options: 

  1. The Client Certificate check is optional, so the connection will always be forwarded but the certificate is only added when a valid certificate has been sent. Additionally, the WebSocket Upgrade must be supported. 

    F5 Big-IP Example


  2. Path dependent forwarding configuration must be supported. The nginx Reverse Proxy supports this type. The listing shows a configuration for the WebSocket endpoint which requires the Client Certificate, add it to the http header and add the WebSocket Upgrade header. See also, IGEL UMS Configuration for the External Load Balancer / Reverse Proxy: Example for NGINX with SSL Offloading

    The other configuration is required for the onboarding endpoint:

    # Configuration for WebSocket Endpoints
 location~/device-connector/device/(ws-connect|portforwarding) {
	proxy_pass https://umsserver;
	proxy_set_header X-SSL-CERT $ssl_client_escaped_cert;# client certificate in current connection
	proxy_set_header Upgrade $http_upgrade; #Set upgrade header
	proxy_set_header Connection $connection_upgrade;
}
#Configuration for all other endpoints
 location / {
	proxy_pass https//umsserver;
	proxy_ssl_trusted_certificate ssl/ssl-cert-chain.cer;
	proxy_ssl_protocols TLSv1.3;
}
    CODE

UMS HA environment with Reverse Proxy, Loadbalancer

The device to UMS / ICG connection can be load balanced.
The UMS Web certificate and ICG certificate must correspond to the IP or Fully Qualified Domain Name of the servers and configured network component. Consider the Subject Alternative Names of the certificate. Wildcard certificates are possible. Be aware to set the UMS cluster address and the UMS public address.
The example shows a nginx upstream server configuration with multiple UMS server entries.

upstream umsserver {
	server 192.168.27.96:8843 max_fails=3 fail_timeout=10s;
 	server 192.168.27.96:8843 max_fails=3 fail_timeout=10s;
 	server 192.168.27.96:8843 max_fails=3 fail_timeout=10s;
 }
CODE


IGEL Cloud Service Configuration

The communication to the IGEL Cloud might be influenced also by network components. In case of the device onboarding via the Onboarding Service the OBS must be reachable for the device. The UMS server also connects to the IGEL Cloud Services. Here the required reachable services are the Onboarding Service (OBS), the License Portal, the App Portal and the Insight Service. These connections can go over a Proxy but must be configured in the UMS. A network component like a firewall with Deep Packet Inspection could result in connection problems.