Tab - Basic

Section - General

section - Name
Field name
Each back-end group has a unique name.
The tenant of this back-end group. See also Multitenancy feature.

Section – Conditions

In this section, the dynamic back-end group selection condition based on the client's HTTP Host header information can be configured in the Client Host Header Pattern field.

Note that mappings with multiple back-end groups may require safety measures. See Dynamic back-end group selection for more information.

section - Multi Back-end Groups Conditions
Field name
Client Host Header Pattern
The back-end group resolution is based on the request HTTP header Host.
  • For each back-end group, a regex pattern must be configured to resolve the back-end group.
  • The resolution is case-insensitive.
  • Back-end groups are selected in the order of their unique priority value.
Sets the priority value of the back-end group selector with respect to the back-end groups of a mapping. The value can be between -999 (highest priority) and 9999 (lowest priority).

The HTTP header Host of a request is basically untrusted and can be manipulated.

  • Choose the Client Host Header Pattern as strictly as possible.
  • If strictness is not possible, e.g. for wildcard name setup (wildcard DNS records, wildcard TLS certificate), be aware that attackers could use dynamic back-end group selection to access all back-end groups accessible via this virtual host.

For requests that carry the same Host header but should be routed to different back-end groups, additional HTTP headers in the Tab - Expert Settings can be configured.

Client Host Header Pattern and additional Expert Settings header patterns are logically AND-linked. The first back-end group that matches will be used.

Section - Back-end Hosts

section - Back-end Hosts

This table contains the back-end host information of a back-end group that specifies how Airlock Gateway can reach a specific back-end host and how load balancing is achieved over multiple back-end hosts.

Table column name
This setting defines the back-end protocol which is used to connect to the back-end application. HTTP or HTTPS is possible.
Back-end Host
The back-end host entry defines the back-end system on which the back-end application runs. A valid entry is either an IP address or a fully qualified domain name (FQDN). When using an FQDN, make sure the name is resolvable through the DNS server defined under System Setup >> Network Services or through System Setup >> Hosts.
Port (optional)
Configuring a back-end port is optional if the default ports for HTTP (80) or HTTPS (443) are used. If different ports are used on the back-end system, make sure to configure the corresponding back-end port.
Back-end hosts can be in one of three modes:
  • Enabled: The back-end host is active and will be served with requests of existing user sessions and with requests of new user session.
  • No new Sessions: The back-end Host just receives requests of existing user sessions. Requests of new user sessions won't be delivered anymore to the corresponding back-end host. The back-end system will be starved.
  • Disabled: The back-end host won't be considered for any kind of request.
Set this flag to define one or several hosts as "Spare": Those hosts will be idle until one of the non-spare hosts fails its health checks and is therefore set to receive only reduced or no more traffic at all. At that point one of the spare servers is assigned the failed back-end host's weight value, and from then on receives requests in its place.
The state of each back-end host is either:
  • good: The back-end host responds to requests.
  • bad: The back-end host is not responsive.
  • n/a: No requests have been sent so far.
After an Airlock Gateway restart, all back-end hosts are in state "n/a" until requests are sent. Also, a newly created back-end host is in state "n/a" before it has received requests. See section in-band and out-of-band checks below for more information on how to schedule in-band and out-of-band health checks of back-end hosts.
Note: States of back-end hosts are not synchronized in an Airlock Gateway cluster. That is, the state of a back-end host can be "bad" in the active Gateway and "good" in the passive Gateway.
This value, in comparison with the weights of all other back-end hosts' in the same group, determines the relative amount of new sessions assigned to a specific back-end host. If all back-end hosts show the same value, sessions will be distributed equally amongst them.
The field takes values between 1 and 9999 .
In new mappings, the first back-end host receives a weight of 100 as well. Each additionally added back-end host receives a weight that is calculated as (sum(weights)*(n+1)/n))-sum(weights), where n is the number of already existing back-end hosts, and sum(weights) is the sum of their weight values. This results in the n-th added back-end host receiving 1/n-th of the sessions.
For a detailed explanation of Airlock Gateway's back-end load balancing features, see here.
This column contains a read-only value, which is calculated from the weight values of all connected back-end hosts. This percentage indicates the distribution of new sessions over the back-end hosts. Note that this distribution can only be achieved in the long run, with large session numbers. Airlock Gateway uses a random function to determine the back-end host to serve a specific session, and that random function is weighed by these percentages.
For back-end hosts in the "No new sessions" mode, the percentage will automatically be set to "0%". For disabled back-end hosts, the percentage will show a "-".
This column shows the number of active sessions on the back-end host. Click on the field to inspect these sessions in the Submenu – Session Viewer.

Section - Access

section - Access
Field name
Kerberos Environment
For information about Kerberos Environment settings for this back-end, see Section – Kerberos Environments.