The load balancer can be connected to the outside world to allow access to the jtel System from the internet.

Connecting the LB to the outside world directly

Not recommended

This is not the recommended approach. If you do decide to do this, then consider the following carefully.

  • DO NOT CONNECT THE INTERNAL NETWORK INTERFACE DIRECTLY TO THE INTERNET. 
    There are more ports open in the firewall on the load balancer for the operation of the solution than just the http and https ports.
    The load balancer should be given a second network interface with the public IP address.

  • Only open port 80 and port 8080 on the second network interface.

  • Consider installing additional protection such as fail2ban to protect against some attacks.

  • Consider using https only.

Connecting the LB to the outside world via a firewall

The following ports should be forwarded to the jtel Load Balancer:

  • Port 80
  • Port 443

It is highly recommended to install a certificate for your domain on the load balancer.

See also SSL/TLS Certificates - Self-signed certificate and Role LB - Certificates for load balancers.

Note: you can use https only (i.e. open only port 443 in the firewall) if you do not require http access. See below for details of extra configuration required in the load balancer to do this.

Connecting the LB to the outside world via a reverse proxy

The preceeding reverse proxy should perform the following tasks:

  • SSL Offloading
    Decode https using an installed certificate, and forward decoded http requests to the jtel load balancer onto port 80.

  • Insert the following headers into the http request:
    X-Forwarded-For 
    X-Forwarded-Proto

Note: this configuration must be performed by the administrators of the reverse proxy and depends on the exact reverse proxy used.

Addition LB Configuration if only Port 443 is opened (via Firewall or via previous Reverse Proxy)

If only port 443 is available to the outside world, then the following must be considered:

  • All requests to the jtel webservers must include the https protocol in the URI.

Because of redirections which are made in the web application, it is necessary to inform the web server that the redirected URL should refer to https and not http.

This is achieved using the X-Forwarded-Proto header in most webservers. Wildfly can do this. However, JBOSS does not do this correctly and so haproxy must be configured to perform this task.

JBOSS

When running JBOSS webservers, add the following to haproxy.cfg in the backend configuration section for jtel_portal and jtel_soap

http-response   replace-header Location http:(.*) https:\1
This is because JBOSS does not process the X-Forwarded-Proto header correctly when redirections are made.

Wildfly

When running Wildfly on the webservers, the configuration, make sure the following is in standalone.xml on the http listener:

proxy-address-forwarding="true"

For example:

<http-listener name="default" socket-binding="http" max-post-size="20971520" enable-http2="false" proxy-address-forwarding="true"/>

The wildfly servlet container deals with the protocol differences correctly on its own by interpreting the X-Forwarded-Proto header.


  • No labels