Page tree
Skip to end of metadata
Go to start of metadata

This panel allows to configure the incoming and outgoing elements of a tunnel. The view is divided into two areas:

  • an Incoming area, which specifies the tunnel's listening parameters – that is, the data flow coming from the clients,

  • and an Outgoing, which specifies the parameters for transmission to the backend.

Incoming

Incoming type

IP

Selects the listening IP address. The list is defined in the IP Addresses section.

IPv4 and IPv6 routes are supported.

High Availability

This setting enables or disables support for a virtual IP address defined beforehand in the High Availability section.

Poller / Polling

In this mode, requests are fetched regularly from another WAF in the cluster then sent to a backend. This mode aims at enhancing the security by ensuring the WAF device or any other device belonging to the same DMZ cannot be used in a bounce attack.

The Polling requires a tunnel in Pooling mode on another WAF in the cluster. A Pooling tunnel allows to locally keep requests that will be fetched by a Polling tunnel.

To use this mode, select a tunnel in Pooling mode and specify a server name. To configure a tunnel in pooler mode, see the outgoing part below.

Traffic between the Poller tunnel and Pooling tunnel is automatically encrypted. The SSL in incoming is enabled when selecting the mode. A certificate server is required.

A Poller tunnel has to be created on a standalone reverse proxy (without any other tunnels attached).

Some reverve proxy and tunnel values are automatically forced at runtime to enhance Pooling/Poller mode performances

The Block Unknown hostnames option is always desactived on the reverse proxy hosting the Poller tunnel. This option is handled by the reverse proxy hosting the Pooler tunnel (first element in the chain). To configure a tunnel in Pooling mode, see the outgoing part below.

List of forced values for the reverse proxy: Max request per child (0), Keepalive (enabled), Keepalive timeout (15s) and the Max Keepalive Requests (0). Values are usually configured in a reverse proxy profile.

List of forced values for the tunnel: ProxyPass Time-to-live (ttl) from the tunnel Advanved parameters (14s).

Port

The TCP listening port. Values can be between 1 and 65535. Generally the value is 80 for HTTP and 443 for HTTPS.

To enable HTTPS, not only must you specify an appropriate port, generally 443, but you also need to select a SSL Ciphers profile in the Incoming Tunnel: SSL section.

With the Poller mode

Port cannot be set when the tunnel is configured as a Poller, this value is automatically retrieved from the Pooling tunnel.

Server Name

The name of the expected HTTP Host header. This is generally the hostname as seen by the clients when the standard ports (80 and 443) are used. When non-standard ports are used, the port must be specified.

Examples:

  • example.com
  • www.example.com
  • www.example.com:8080
  • www.example.com:8443

A single host is authorized in this parameter. If several Hostnames are used on this tunnel, add the aliases in Server Alias.

An empty value is possible, in which case the tunnel will process the request regardless of the HTTP Host header, unless the Request on unknown hostnames setting of the associated Reverse Proxy is enabled.

Server Alias

Optional setting. Specifies the additional Hostnames for which the Tunnet must accept requests. Several values can be specified, separated by one or several spaces. The rules concerning specifying non-standard ports are the same as for the Server Name parameter.

Unknown hostnames

If a request is made with a Host HTTP header different from the one specified in Server Name or Server Alias, it may be blocked by the Request on unknown hostnames settings of the associated reverse proxy.

HTTP/2

Enable the HTTP/2 protocol on tunnel incoming connections.

The SSL option has to be enable on tunnel incoming connections to use HTTP/2. If a browser do not support HTTP/2 protocol, the connection will be performed with the HTTP/1.1 protocol.

Protocol description:

HTTP/2 protocol is an improvement of the HTTP/1.1 version which include the following features:

  • binary format, instead of textual,
  • data encryption through HTTP/2 over TLS,
  • fully multiplexed, instead of ordered and blocking. It allows many HTTP requests and responses simultaneously in only one TCP connection,
  • uses header compression to reduce overhead,
  • allows servers to “push” responses proactively into client caches (not supported by the product).

All those features will mainly reduce loading time and provide encryption at the same time.

Restrictions: Connection Reuse

 The HTTP/2 protocol allows reuse of TLS connections under certain conditions: if you have a certificate with wildcards or several altSubject names, browsers will reuse any existing connection they might have. Example:

You have a certificate for a.example.org that has as additional name b.example.org. You open in your browser the url https://a.example.org/, open another tab and load https://b.example.org/.

Before opening a new connection, the browser sees that it still has the one to a.example.org open and that the certificate is also valid for b.example.org. So, it sends the request for second tab over the connection of the first one.

Tunnels using these two Server Names will need the same SSL configuration to be able to reuse the connection, otherwise the connection will be rejected and the following errors will appear on the user and proxy side:

Tunnel error:

Hostname a.example.org provided via SNI and hostname b.example.org provided via HTTP have no compatible SSL setup

Client browser error:

Misdirected Request

The client needs a new connection for this request as the requested host name does not match the Server Name Indication (SNI) in use for this connection.

Outgoing

Proxy Type

A tunnel can operate in four different modes: Reverse, Forward requestForward remote and Pooling.

Reverse

The Reverse mode is a proxy server that appears to the client just like an ordinary web server. No special configuration on the client is necessary. The client makes ordinary requests for content in the namespace of the reverse proxy. The reverse proxy then decides where to send those requests and returns the content as if it were itself the origin.

This is the default tunnel mode.

Forward

The Forward mode is a proxy server that sits between the client and the backend. In order to get content from the origin server, the client sends a request to the proxy naming the origin server as the target. The proxy then requests the content from the origin server and returns it to the client.

Forward request

Forward request mode allows a request to be transferred to an external web server. An ACL must be configured (in the Proxy Request from field) to prevent the server being used by unauthorized users.

  • Proxy request from: list of source IP addresses that can use the proxy. This list is constructed in the form of IP addresses with a CIDR mask. Several addresses can be listed, separated by commas.

Unknown hostnames

A tunnel configured in Forward request mode must have the hostnames of the backends in its Server Alias list, or the request will be blocked. This behavior can be changed by changing the Request on unknown hostnames / Block settings of the associated reverse proxy.

Forward remote

The purpose of Forward remote mode is to send a request via another proxy server.

  • Remote proxy IP/Host: the IP address or hostname of the remote proxy.
  • Remote proxy port: the port number of the remote proxy.

Pooler / Pooling

In this mode, the traffic is not forwarded directly to the backend, the tunnel locally keeps requests that will be fetched regularly by another WAF in the cluster. This mode aims at enhancing the security by ensuring the WAF device or any other device belonging to the same DMZ cannot be used in a bounce attack.

For this mode, an outgoing IP and port are required. A Poller tunnel on another WAF box is needed to fetch requests from this Pooling tunnel and send them to a backend. To configure a tunnel in Poller mode, see the Incoming part above.

Traffic between the Pooler tunnel and Poller tunnel is automatically encrypted. The SSL in outgoing is enabled when selecting the mode.

A Pooling tunnel has to be created on a standalone reverse proxy (without any other tunnels attached).

Some reverve proxy and tunnel values are automatically forced at runtime to enhance Pooling/Poller mode performances

List of forced values for the reverse proxy: Max request per child (0), Keepalive (enabled), Keepalive timeout (15s) and the Max Keepalive Requests (0). Values are usually configured in a reverse proxy profile.

List of forced values for the tunnel: ProxyPass Time-to-live (ttl) from the tunnel Advanved parameters (14s).

Backend balancer

Enables or disables the backend balancing function for several backends. A Backend Balancing configuration must be present.

Backend IP/host

The IP address or hostname to which requests are to be sent after processing by a Workflow. An IPv4 address has to be specified, or a hostname. IPv6 addresses are not supported.

The hostname must be resolved either by having entered the Hostname/IP correspondence in the Hosts parameters of the Box, or by having enabled DNS resolution.

Backend Port

The destination TCP port. The value can be between 1 and 65535. This is the port on which the Backend server expects to receive requests.

To enable HTTPS toward the backend, not only must you specify an appropriate port (generally 443), but you also need to select a SSL Ciphers profile in the Outgoing Tunnel - SSL section.