Reverse Proxy Configuration

A reverse proxy is usually used to have a single point of access for the front end - or client facing - side of a service. Reverse proxies are typically implemented in a way to increase security, performance and reliability. They also allow to have the same service on multiple origin servers - or nodes - without the web client knowing about this architecture and complexity.

Using INETAPP with a reverse proxy is required in a multi-node environment when using additional servers to scale up the available workforce and provide better performance for parallel access of many users. A reverse proxy can also be used to simply provide a static, client facing access point to the INETAPP server in a DMZ.

It is recommended to forward the following headers to the original server:

  • X-Forwarded-Proto
  • X-Forwarded-Host
  • X-Forwarded-Port
  • X-Forwarded-Context

HAProxy

The HAProxy requires the following options:

# if the application is running using standard https ports
http-request set-header X-Forwarded-Port 443
http-request set-header X-Forwarded-Proto https if { ssl_fc }
 
# if the application is available at a specific subcontext
# e.g. https://mycompany.com/subcontext
http-request set-header X-Forwarded-Context /subcontext
 
# Setting the host is non standard
http-request set-header X-Forwarded-Host %[req.hdr(Host)]

NGinx

The NGinx requires the following options/*, which are also documented here*/:

# if the application is running using standard https ports
proxy_set_header X-Forwarded-Port 443;
proxy_set_header X-Forwarded-Proto https;
 
# if the application is available at a specific subcontext
# e.g. https://mycompany.com/subcontext
proxy_set_header X-Forwarded-Context /subcontext;
 
# Setting the host is non standard
proxy_set_header X-Forwarded-Host $remote_addr;

Apache

The Apache requires the following options:

# if the application is running using standard https ports
Header set X-Forwarded-Port 443
Header set X-Forwarded-Proto https
 
# if the application is available at a specific subcontext
# e.g. https://mycompany.com/subcontext
Header set X-Forwared-Context /subcontext

IIS

The IIS has a process that requires multiple steps to enable forwarding the headers.

  1. Enable forwarding of headers in the menu URL rewrite > Manage Server Variables... > Add and add the following headers:
    • HTTP_X_FORWARDED_PROTO
    • HTTP_X_FORWARDED_HOST
    • HTTP_X_FORWARDED_PORT
    • HTTP_X_FORWARDED_CONTEXT
  2. Set up the header fields in the reverse proxy rule as at the following table states
Server variable name Value Replace
HTTP_X_FORWARDED_PORT {SERVER_PORT} True
HTTP_X_FORWARDED_CONTEXT {URL} True
HTTP_X_FORWARDED_HOST {HTTP_HOST} True
HTTP_X_FORWARDED_PROTO https (only if HTTPS is enabled) True

The resulting web.config should look like this:

<?xml version="1.0" encoding="UTF-8"?>
<configuration>
    <system.webServer>
        <rewrite>
            <rules>
                <rule name="ReverseProxyInboundRule1" stopProcessing="true">
                    <match url="^api/v1/inet(.*)" />
                    <action type="Rewrite" url="http://localhost:9000{R:1}" />
                    <serverVariables>
                        <set name="HTTP_X_FORWARDED_PORT" value="{SERVER_PORT}" />
                        <set name="HTTP_X_FORWARDED_CONTEXT" value="{URL}" />
                        <set name="HTTP_X_FORWARDED_HOST" value="{HTTP_HOST}" />
                        <set name="HTTP_X_FORWARDED_PROTO" value="https" />
                    </serverVariables>
                </rule>
            </rules>
        </rewrite>
    </system.webServer>
</configuration>

Note: The IIS requires the header fields to be uppercase and combined by underscore instead of a hyphen.