FAQ
Smarter by Design.Simpler for Business
TR7Enterprise Application Delivery & Security Platform

English

Türkçe

English

Türkçe

Appearance

Intermediate

What is SSL passthrough; when should I use passthrough instead of termination? ​

Short answer

In SSL passthrough, TLS is not opened on TR7: TR7 carries the encrypted connection as it is to the Backend Service, the TLS handshake is made between the client and the server, and the certificate is only on the server. In TR7, it is set up on an L7 TCP vService by selecting TCP (not TCP + TLS) in the frontend Protocol field; SSL Service stays off on the Backend Services and their addresses point to the TLS port of the servers. If more than one domain name will go to different servers, the SSL SNI Info condition and Conditional Backend Services (Content Switching) are used. It is preferred if the private key cannot be placed on TR7 or if the application itself will verify the client certificate; in this setup, WAF, HTTP conditions and HTTP actions are not used.

Background

SSL passthrough is the forwarding of encrypted traffic to the target server without it being decrypted at all on the intermediate device. The TLS session is established end to end between the client and the server; the intermediate device only balances the connection and cannot see the content. The only information the intermediate device can read is the SNI field in the unencrypted first packet of the TLS handshake (ClientHello): the domain name the client wants to connect to. In termination, TLS is terminated on the intermediate device; in bridging, the intermediate device terminates TLS and establishes a new TLS connection to the server.

Problem: The Encryption Must Not Be Opened on TR7 ​

That TR7 can see the traffic is what is wanted in most setups; WAF, conditions and actions rely on it. In some cases, however, the encryption must not be opened at all in the intermediate layer:

  • Due to corporate policy or an audit requirement, the private key must stay only on the application server; TLS termination requires a copy of the key to be on TR7.
  • The application itself wants to verify the certificate presented by the client (end-to-end mTLS).
  • The traffic is not HTTP and there is no need to look at the content (e.g. encrypted database or messaging protocols).

In these cases, TR7 must continue to distribute the load but must not touch the encryption.

Solution: Two Methods ​

In TR7, there is no separate option named "SSL passthrough": a frontend row that does not terminate TLS is passthrough. Method 2 adds routing by SNI on top of Method 1.

Your situationSuitable method
The private key cannot be placed on TR7; all connections will go to the same server groupMethod 1: L7 TCP vService, Protocol = TCP
There is more than one domain name on the same IP and port; each will go to different serversMethod 2: Passthrough + routing by SNI
WAF, content conditions or header actions are neededPassthrough is not suitable → termination: What is SSL offloading (termination), and how is it set up?
Content visibility and TR7–server encryption are needed togetherBridging → What is SSL bridging; how do I also encrypt the traffic to the backend?
  • How it works When TCP is selected in the frontend row, TR7 receives the connection at the TCP level and forwards the bytes as they are to the Backend Service; the TLS handshake is made by the server. The Certificate and SSL Security fields do not appear in the form.
  • Where it is openedLoad Balancer → Load Balancer vService List → Add → Type = L7 TCP → Frontend → Protocol = TCP
  • Requirement A valid certificate and a port listening for TLS on the servers; SSL Service off on the Backend Services
  • vService type L7 TCP
  • The vService type does not change An existing HTTP vService cannot be converted to passthrough; the Type field is selected only while creating. A new L7 TCP vService is created.

Step-by-Step Configuration ​

1
Adım 1 Add the frontend IP (if needed)

If the address the vService will listen on is not defined on TR7, it is added to the related interface with Add IP on the Network → Interfaces screen (how to add; in a cluster setup, as a VIP).

2
Adım 2 Open the Backend Service form

On the Load Balancer → Backend Services screen, Add is clicked (how to add). If the servers are already defined, steps 2–4 are skipped; it is checked that SSL Service is off on those Backend Services.

3
Adım 3 Define the server

The Backend Service Name is entered; the IP of the server and the port on which it listens for TLS are written in the Address field (e.g. 192.0.2.21 : 443). SSL Service is left off (default); if it is turned on, TR7 tries to establish a second TLS inside the already encrypted connection and the connection cannot be established.

4
Adım 4 Save the Backend Service

Add is clicked. Steps 2–4 are repeated for each server.

5
Adım 5 Open the vService add form

On the Load Balancer → Load Balancer vService List screen, Add is clicked (how to add).

6
Adım 6 Select the type and the name

L7 TCP is selected in the Type field (the default is HTTP); the Name is entered.

7
Adım 7 Define the frontend row

In the Frontend row, the Frontend IP is selected, Port = 443 is written, and Protocol = TCP in the Unencrypted group is selected. TCP + TLS in the Encrypted (TLS) group is not selected: that option terminates TLS on TR7 and requires a certificate.

8
Adım 8 Select the Backend Services

In the Default Backend Services table, the Backend Services from steps 2–4 (or a Backend Group that contains them) are selected with Add Backend Services. If the table is left empty, the connections are rejected.

9
Adım 9 Save

Save is clicked; if the vService is in the Enabled state, it starts receiving connections immediately. In a cluster setup, with the default auto-sync, the configuration is also sent to the peer device; if Manual Sync Mode is on, it is sent to the peer device manually.

The servers see the IP of TR7 as the source of the connection; the client IP cannot be carried with an HTTP header. If needed, Proxy (Proxy Protocol; the server must also support it) or SNAT = Use Client IP is used on the Backend Service (How do I pass the real client IP for non-HTTP TCP services?).

Verification ​

1Presented certificateClient side

The proof of passthrough is that the client sees the server's own certificate.

Command: openssl s_client -connect 203.0.113.10:443 -servername www.example.com

Expectedsubject and issuer show the certificate on the server
If a certificate warning is received, the name or the validity of the certificate on the server is checked; TR7 does not present a certificate in this setup.
2SessionsTR7 side

On the Live Stats screen of the vService, it is seen that the connections are distributed to the Backend Services.

ExpectedActive sessions on the Backend Services

Method 2: Passthrough + Routing by SNI ​

  • How it works TR7 reads the SNI in the ClientHello and forwards the connection to different Backend Services according to the domain name without opening the encryption. For each domain name, an SSL SNI Info condition and a Conditional Backend Services rule are defined; connections that match no rule go to Default Backend Services.
  • Where it is openedLoad Balancer → Conditions · L7 TCP vService → Conditional Backend Services
  • Requirement The L7 TCP vService from Method 1 (Protocol = TCP); clients sending SNI
  • vService type L7 TCP
  • Usable conditions Connection-level conditions: SSL SNI Info, Source IP, Destination IP, Destination Port, etc. Since TLS is not decrypted, the SSL Version and SSL Cipher conditions do not match on this frontend; Host, path and header conditions do not exist in L7 TCP.

Step-by-Step Configuration ​

1
Adım 1 Open the condition form

On the Load Balancer → Conditions screen, Add is clicked (how to add).

2
Adım 2 Define the SNI condition

The Condition Name is entered (e.g. sni-a); Criteria = SSL SNI Info is selected and the domain name is written in the Query field (e.g. a.example.com). The match is on the exact name and is case-insensitive; a wildcard (*.example.com) or more than one name cannot be entered.

3
Adım 3 Save the condition

Add is clicked. Steps 1–3 are repeated for each domain name; Add & Repeat keeps the form open.

4
Adım 4 Prepare the Backend Services

The servers of each domain name are added as Backend Services with steps 2–4 of Method 1; the addresses point to the TLS port of the servers, and SSL Service stays off.

5
Adım 5 Open the vService edit form

On the Load Balancer → Load Balancer vService List screen, the L7 TCP vService from Method 1 is selected and Edit is clicked (if there is no vService, it is created with steps 5–8 of Method 1). The Protocol value of the frontend row must be TCP.

6
Adım 6 Add the first rule

+ Conditional Backend Services in the header of the Backend Services table is clicked; the CONDITIONAL BACKEND #1 block opens above the table.

7
Adım 7 Define the rule

In the block, the SSL SNI Info condition from step 2 is selected as the condition; the Backend Services of that domain name are added to the Backend Services table of the block. Steps 6–7 are repeated for each domain name. The rules are evaluated from top to bottom, and the first matching rule is applied; the order is changed with drag and drop.

8
Adım 8 Select the target for non-matching connections

In the Default Backend Services table, the Backend Service to which the connections that send no SNI or match no rule will go is selected. If the table is left empty, these connections are rejected.

9
Adım 9 Save

Save is clicked. In a cluster setup, with the default auto-sync, the change is also sent to the peer device; if Manual Sync Mode is on, it is sent to the peer device manually.

Verification ​

1Routing by SNIClient side

A connection is made to the same address with two different domain names.

Command: openssl s_client -connect 203.0.113.10:443 -servername a.example.com · openssl s_client -connect 203.0.113.10:443 -servername b.example.com

ExpectedEach name returns the certificate of its own server

Common Mistakes ​

TCP + TLS is not passthrough

Despite its name, the TCP + TLS option in L7 TCP terminates TLS on TR7 and requires a certificate. For passthrough, TCP is selected in the Protocol field.

  • Turning on SSL Service on the Backend Service. SSL Service makes TR7 establish its own TLS connection to the server; in passthrough, since the connection already arrives encrypted, two TLS layers are stacked on top of each other and the connection cannot be established. This field belongs to termination and bridging configurations.
  • Looking for passthrough on an HTTP vService. An HTTP vService processes the incoming request as HTTP; a row left with Protocol = HTTP expects plain HTTP and cannot decrypt the encrypted connection. Passthrough is done only on an L7 TCP vService.
  • Expecting WAF or HTTP actions in passthrough. WAF, Cache, Compression, X-Forwarded-For, header and cookie actions exist only on an HTTP vService; on L7 TCP, L7 DDoS & Threat Protection and connection-level Actions can be used. If content inspection is needed, termination or bridging is selected.
  • Trying to differentiate with the SSL Version or SSL Cipher condition. These conditions read the TLS connection terminated by TR7; they do not match on a passthrough frontend. In passthrough, only the SSL SNI Info condition looks at TLS information.
  • Using the SSL SNI Info condition in protocols that do not send SNI. On a vService where the condition is defined, TR7 waits for the TLS handshake in the first packet of the connection; in protocols where the server speaks first (SMTP, FTP, those using STARTTLS), the acceptance of the connection is delayed by up to 10 seconds. These protocols are kept on a separate vService.
  • Forgetting certificate tracking. Since the certificate is not on TR7, the expiry notification and ACME renewal do not work for these servers; they are monitored separately on each server.

How it is done in the documentation

Related questions