Please note that this information is provided as a courtesy only and support services are not offered for any of the features described in this article.
On this page
Introduction
There are environments in which the TWCloud applications need to be fronted by a proxy. The most widespread use case for this is port restrictions whereby the native ports cannot be exposed. Typically, all external traffic is restricted to a single port, such as 443, which is allowed to traverse corporate firewalls or proxies.
In order to configure a proxy, we first need to understand the traffic flows, since each traffic flow needs to be addressed. Teamwork Cloud is composed of 3 services (Webapp, Authserver, Teamwork Cloud), which need to expose 4 traffic flows (or port bindings) to function.
- Webapp (native port 8443 - http/s)
- Authserver (native port 8555 - http/s)
- Teamwork Cloud
- REST API (native port 8111 - http/s)
- Client Communication (native port 3579 -TCP cleartext or native port 10002 - TLS/TCP encrypted) - 10002 is the default port used by the client and is configured in the TWCloud Admin Settings page
Additionally, if the FlexNet license server is running on the same instance with the same port constraints, a TCP proxy must be created for it, forwarding to our cameo vendor daemon (native port 1101 - TCP).
Since in TCP/IP you can only bind a single instance of a port to an IP address, the instance will need to have multiple IP addresses in which to bind each traffic flow.
Traffic flows are tied to frontends (the part of the proxy that is exposed to the external world, which receives the requests and forwards to the backends) and backends (handling of the actual requests).
The number of IP addresses required depends on the type of proxying which we configure.
There are 2 types of proxying - TCP (in which case the proxying is done at Layer 4 of the OSI model) or HTTP (in which case the proxying is done at Layer 7 of the OSI).
Layer 4 proxying is the lighter-weight of the 2 methods since it simply forwards incoming packets from the frontend to its associated backend. In this case, we need 4 IP addresses (5 if proxying FlexNet as well) in order to bind to each data flow.
Layer 7 proxying inspects the actual content of the data coming through the proxy. Therefore, SSL termination takes place at the proxy. In doing so, we can now manipulate the data coming through and take specific actions. Since each of the HTTPS services exposes a path (/webapp for the TWCloud Admin Console, /osmc for the REST API, and /authentication for the authserver), we can treat the incoming data as a single flow (a single frontend), and have the proxy send the request to the respective backend based on the path of the request.
There are 2 classes of proxies/load balancers. Hardware (such as F5 Big-IP, Cirtix NetScaler) which are external to the application instance, and software (such as nGinx, HAProxy) which can be run externally (on a dedicated instance) or on the same instance as the application.
Proxy configuration
This document will outline how to deploy both Layer 4 (TCP) and Layer 7 (HTTPS) proxies utilizing both nGinx and HAProxy. The Layer 7 configuration is a hybrid configuration in that it also includes Layer 4 proxying for the MD client data stream and FlexNet server.
When we initially deploy Teamwork Cloud, we specified a local IP address. This will become the IP address for the Webapp frontend. Keep in mind that the native ports (8443, 8111, 8555, MD↔TWCloud port, and the cameo vendor daemon for FlexNet) bind to all interfaces.
For this example, we have an instance with 5 IP addresses - 10.254.254.31 (Webapp), 10.254.254.32 (REST), 10.254.254.33 (Authserver), 10.254.254.34 (MD↔TWC), and 10.254.254.35 (FlexNet).
The configurations are the most basic configurations in order for the system to operate. You may add features or change behaviors by modifying these files.
It is noteworthy that in order to simplify all of the aspects of certificates, you should either use a wildcard certificate or one which contains SAN's for all of the public fqdn's and/or IP addresses.
In order to facilitate the deployment, we have prepackaged installation scripts and template files which will install the proxies from the respective repositories as well as generate the basic configuration files.
nGinx
Layer 4 Proxy
As depicted in the TCP Proxy Context IBD, we have 5 frontends listening on port 443. Therefore, the instance must have 5 local IP addresses to which to bind port 443.
After deploying the Proxy, we need to make some changes to authserver.properties in order to allow the proxied TWCloud Admin console access.
Layer 7 Proxy
As depicted in the HTTP Proxy Context IBD, we have 3 frontends listening on port 443. Therefore, the instance must have 3 local IP addresses to which to bind port 443.
After deploying the Proxy, we need to make some changes to authserver.properties in order to allow the proxied TWCloud Admin console access. Unlike the TCP Proxy where each stream was bound to its own IP address, all 3 HTTPS streams are handled by a single frontend. Therefore, the serverver.public.host, in this case, is the primary IP address.
In a Layer 7 HTTPS proxy, SSL termination takes place at the proxy. For this to take place, you will need a PEM encoded file containing the private key and certificates for the server, including the full certificate chain.
HAProxy
The default package for HAProxy is 1.5, which is EOL. A package for HAProxy 1.8 is also available in an alternate repository.
The provided scripts contain versions to install both the default (1.5) and the alternate (1.8).
Layer 4 Proxy
As depicted in the TCP Proxy Context IBD, we have 5 frontends listening on port 443. Therefore, the instance must have 5 local IP addresses to which to bind port 443.
After deploying the Proxy, we need to make some changes to authserver.properties in order to allow the proxied TWCloud Admin console access.
Layer 7 Proxy
As depicted in the HTTP Proxy Context IBD, we have 3 frontends listening on port 443. Therefore, the instance must have 3 local IP addresses to which to bind port 443.
After deploying the Proxy, we need to make some changes to authserver.properties in order to allow the proxied TWCloud Admin console access. Unlike the TCP Proxy where each stream was bound to its own IP address, all 3 HTTPS streams are handled by a single frontend. Therefore, the serverver.public.host, in this case, is the primary IP address.
In a Layer 7 HTTPS proxy, SSL termination takes place at the proxy. For this to take place, you will need a PEM encoded file containing the private key and certificates for the server, including the full certificate chain.