Page Comparison

...

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:

...

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.

...

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

...

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.

...

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:

...

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

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