Page Comparison

...

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

Connection Types Between Device and UMS

For a successful configuration it is important to understand the different connection types.

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.

UMS to ICG 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.

Communication via Reverse Proxy

The diagram shows the device to UMS connection via a Network Component like Azure Application Gateway. The required connections are listed for SSL Offloading. The diagram shows one HTTPS connection which is necessary for device onboarding (Client Certificate request) and the following WebSocket connection where Mutual TLS and Client Certificate forwarding is required.

Communication via Azure Application Gateway

Some Reverse Proxies like NGINX support a Mutual TLS configuration with optional Client Certificate check. These Reverse Proxies can handle both required UMS connections with one configured listener. The Azure Application Gateway does not support this feature. The two types of connections used must be handled separately. According to this the Azure Application Gateway configuration must contain two separate listeners with corresponding rules.

The UMS supports the separation of the Onboarding and the WebSocket connections. The following diagram shows an overview of a device to UMS connection via the Application Gateway.

The HTTPS listener for device onboarding could use the standard https Port (443) and forwards direct to UMS.
In this example, the HTTPS listener for WebSocket connection listens on Port 8443 and uses mutual TLS for the Client Certificate Check and adds it to the Request Header, so that the UMS can verify it.

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.

...

## 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;
	}
}

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;

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.

...

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: 

• 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 configuration example:

  Image Modified

  
  
  

• 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,

  NGINX: Example Configuration for as Reverse Proxy in IGEL OS with SSL Offloading

  /wiki/spaces/ENLITEUMSE/pages/74450494 .

  The other configuration is required for the onboarding endpoint.

  NGINX configuration example:
  
  

  Code Block

  # 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; }

  
  
  

• Configuration of two endpoints (that is, two Virtual Servers / Listeners) on the Reverse Proxy / Loadbalancer. One endpoint is configured for the device onboarding and another one for the WebSocket connection.

Azure Application Gateway configuration example:

Image Modified

UMS HA environment with Reverse Proxy, Loadbalancer

...

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 IGEL License Portal (ILP), the IGEL 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.

UMS Endpoint Paths for Reverse Proxy Integration

The paths required for OS 12 device connections to the UMS (via a reverse proxy) are:

• Root path: /device-connector/device/*

• Detailed paths:

  • /device-connector/device/ws-connect

  • /device-connector/device/portforwarding

  • /device-connector/device/.well-known/est/*

• App proxy path: /ums-appproxy/*

The device communication is always TLSv1.3.

In case the UMS Web App should be used via a reverse proxy, the following paths are required:

• /wums-app/*

• /webapp/*

The device communication is TLSv1.2 or TLSv1.3.