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

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.

Polling

In this mode, the traffic is not received from the client, but is rather pulled off another WAF device in what is called the Pooling Mode.

This mode aims at enhancing the security by ensuring the other WAF device or any other device belonging to the same DMZ cannot be used in a bounce attack.

This section will list the available Poolers on your cluster, from which you want to process traffic.

You are not allowed to create a Poller on a Reverse Proxy already containing one other Tunnel.

Pooling performances

Pooling performances with default Reverse Proxy and system configuration are not suitable for high loaded websites. To get the best possible performances, contact Technical Support for Reverse Proxy and system parameters tunning.

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 Cipher profile in the Incoming Tunnel: SSL section.

Port cannot be set when the tunnel is configured as a poller, because 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 Tunnel 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.

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

Reverse mode is the initial behavior. It requires no particular configuration.

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: A list of 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.

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

Backend balancer Enabled

Enables or disables the load balancing function for several backends. A Load 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 can be specified, or a hostname (which must then be resolved, either by having entered the Hostname/IP correspondence in the Hosts parameters of the Box, or by having enabled DNS resolution.IPv6 addresses are not supported. This is the port on which the Backend server expects to receive requests.

Backend Port

The destination TCP port. The value can be between 1 and 65535.

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

Pooling

In this mode, the traffic is not forwarded to the backend, but is kept locally to be fetched regularly by an other WAF device, in what is called the Pooling Mode.

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.

You are not allowed to create a Pooler on a Reverse Proxy already containing one other Tunnel.

Pooling performances

Pooling performances with default Reverse Proxy and system configuration are not suitable for high loaded websites. To get the best possible performances, contact Technical Support for Reverse Proxy and system parameters tunning.