With passthrough, can I route to different backends based on SNI?
Short answer
Yes, on an L7 TCP vService. Frontend Protocol = TCP is selected (TLS is not decrypted); an SSL SNI Info condition is created for each domain name and bound to the related Backend Services with Conditional Backend Services rules. TR7 reads the SNI in the first message of the TLS handshake (ClientHello) and forwards the connection to the correct server without decrypting it. The condition performs an exact name match (case-insensitive). This method cannot be used on an HTTP vService because TLS is terminated on TR7, and on a Network vService because SNI is not read.
Problem: More Than One Site Shares the Same IP, but the Certificates Are on the Servers
While more than one HTTPS site shares the same IP and port, the certificates and private keys may have to stay on the servers. TR7 needs to send the connection to the correct server according to the domain name requested by the client, without opening TLS.
Solution
On an L7 TCP vService that performs passthrough, each domain name is distinguished with an SSL SNI Info condition and bound to its own Backend Services with a Conditional Backend Services rule.
SSL SNI Info + Conditional Backend Services
- How it works The condition compares the SNI in the ClientHello by its exact name; the connection is forwarded to the Backend Services of the matching rule, and those that match no rule go to the Default Backend Services.
- Where it is openedLoad Balancer → Conditions · L7 TCP vService → Conditional Backend Services
- Requirement An L7 TCP vService with Protocol = TCP; clients sending SNI
- vService type L7 TCP
Step-by-Step Configuration
On the Load Balancer → Conditions screen, Add is clicked (how to add).
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 the exact name; a wildcard (*.example.com) or more than one name cannot be entered.
Add is clicked. Steps 1–3 are repeated for each domain name; Add & Repeat keeps the form open.
On the Load Balancer → Backend Services screen, Add is clicked (how to add). If the servers are already defined, steps 4–6 are skipped; it is checked that SSL Service is off on those Backend Services.
Backend Service Name is entered; the server's IP and the port it listens on with TLS are written in the Address field (e.g. 192.0.2.21 : 443). SSL Service is left off (default); the connection is forwarded to the server encrypted, as it is.
Add is clicked. Steps 4–6 are repeated for each server of each domain name.
On the Load Balancer → Load Balancer vService List screen, the L7 TCP vService that performs passthrough is selected and Edit is clicked. If it does not exist yet, Add is clicked, Type = L7 TCP is selected, and Name is entered (how to add).
In the Frontend row, Frontend IP is selected; Port must be 443 and Protocol must be TCP in the Unencrypted group. TCP + TLS in the Encrypted (TLS) group terminates TLS on TR7; in that case, the SSL SNI Info condition does not match.
+ Conditional Backend Services in the header of the Backend Services table is clicked; the CONDITIONAL BACKEND #1 block opens above the table.
In the block, the first SSL SNI Info condition created in steps 2–3 is selected as the condition; the Backend Services of that domain name are added to the block's Backend Services table. Steps 9–10 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.
In the Default Backend Services table, the Backend Service is selected to which the connections that do not send SNI or match no rule will go. If the table is left empty, these connections are rejected.
Save is clicked (the same button is also used for a new vService). 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
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
Each name returns the certificate of its own serverCommon Mistakes
- Selecting TCP + TLS for Protocol. TCP + TLS terminates TLS on TR7 and requires a certificate; for passthrough, Protocol must be TCP.
- Using a wildcard in the condition. SSL SNI Info compares the exact name; a separate condition and rule are written for each domain name.
- Using it with protocols where the server speaks first. On a vService with the condition defined, TR7 expects the TLS handshake in the first packet of the connection; in SMTP, in FTP or in any protocol that uses STARTTLS, SNI cannot be read and the acceptance of the connection is delayed by up to 10 seconds. These protocols are kept on a separate vService.
- Turning on SSL Service on the Backend Service. In passthrough, since the connection already arrives encrypted, two TLS layers are stacked on top of each other and the connection cannot be established.
- Looking for this condition on an HTTP vService. An HTTP vService terminates TLS; there, the distinction by domain name is made with Virtual Hosting or Host conditions, and this is not passthrough.
How it is done in the documentation
