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

English

Türkçe

English

Türkçe

Appearance

Intermediate

Can I define more than one vService on the same IP:port? ​

Short answer

Yes, in HTTP vServices, with Virtual Hosting. Virtual hosting is turned on in each vService that will share the same IP:port, and the domain names that belong to that vService are written; TR7 sends the request to the correct vService by looking at the Host header in unencrypted traffic and at the SNI in HTTPS. For sharing to work, the Virtual hosting list must be filled in all the vServices, and the frontends of all of them must be in the same encryption class (all HTTPS or all unencrypted). Without Virtual hosting, the same IP:port cannot be used in a second vService.

Problem: Why Are Multiple Sites Needed on the Same Address? ​

Public IP addresses are limited; most organizations publish many sites from port 443 of a single public IP. Each site needs to have its own Backend Services, rules and security settings. Giving the same IP:port to two vServices normally leads to a collision (Port collision); TR7 needs to understand which site the incoming request belongs to.

Solution ​

Sharing the Address with Virtual Hosting ​

  • How it works A request arriving at the shared IP:port is directed to the related vService according to the domain name: the Host header is used in unencrypted traffic, and the SNI in TLS is used in HTTPS. Each vService runs independently with its own certificate, profiles and Backend Services.
  • Where it is opened vService → Virtual Hosting → domain name list
  • Requirement The list being filled in all the sharing vServices; all of them being in the same encryption class
  • vService type HTTP only
  • Backend Service side No change is required.

Step-by-Step Configuration ​

1
Adım 1 Open the first vService's edit form

On the Load Balancer → Load Balancer vService List screen, the existing vService that uses the address is selected and the Edit button is clicked.

2
Adım 2 Turn on Virtual hosting and write the domain names

The Virtual Hosting switch is turned on (the first domain name row opens), and the domain names that belong to this vService (e.g. a.example.com) are written in lowercase. The wildcard character (*.example.com) can be used. If the unencrypted frontend is on a port other than 80, the domain name is written together with the port (e.g. a.example.com:8080).

3
Adım 3 Save the first vService

The Save button is clicked.

4
Adım 4 Upload the certificate (for HTTPS and if it is not on TR7)

If the certificate of the second domain name is not on TR7, it is uploaded with Certificates & PKI → SSL/TLS Certificates → Add (How do I upload my certificate to TR7; which formats are supported?).

5
Adım 5 Open the second vService's form

A new HTTP vService form is opened with Load Balancer → Load Balancer vService List → Add; the Name is entered.

6
Adım 6 Turn on Virtual hosting and write the domain names

The Virtual Hosting switch is turned on, and the domain names of this vService (e.g. b.example.com) are written.

7
Adım 7 Select the same IP:port

In the Frontend row, the same IP and port as the first vService are selected; the Protocol must be in the same encryption class as the first vService (both from the Encrypted (HTTPS) group, or both unencrypted HTTP / HTTP → HTTPS). In HTTPS, the certificate of this domain name is selected in the Certificate field.

8
Adım 8 Select the Backend Services

In the Default Backend Services table, the Backend Services of this site are selected.

9
Adım 9 Save

The Save button is clicked. In the vService list, a cloud icon appears in the Type cell of the vServices with Virtual hosting defined. In a cluster setup, the change is also transferred to the peer device with the default auto-sync; if Manual Sync Mode is on, it is sent manually with Synchronize.

Verification ​

1Request by domain nameClient side
Commandcurl -I --resolve a.example.com:443:203.0.113.10 https://a.example.com/
ExpectedThe request goes to the vService of a.example.com and to its Backend Services
The same command is repeated with b.example.com. In unencrypted traffic, curl -I -H "Host: a.example.com" http://203.0.113.10/ is used. In the vService list, when the pointer is over the cloud icon in the Type cell, the domain names of the vService are listed.

Common Mistakes ​

  • Leaving the list empty in one of the vServices. For sharing, the Virtual hosting list must be filled in all the vServices; otherwise the form shows the "Port collision" error.
  • Mixing the encryption classes. An HTTPS (HTTP/1.1, HTTP/2) row and an unencrypted (HTTP, HTTP → HTTPS) row cannot share the same IP:port.
  • Writing the domain name without the port for unencrypted Virtual hosting on a port other than 80. On non-standard ports, the browser also adds the port to the Host header (alan.adi:8080); since matching is done with the exact value of the Host header, a domain name written without the port does not match and the request receives 503. On these ports, the domain name is written to the list together with the port (alan.adi:8080). In HTTPS, since matching is done with SNI, the port is not written.
  • Writing domain names in uppercase. Matching is case-sensitive; since browsers send the domain name in lowercase, it is written to the list in lowercase.
  • Assuming that non-matching requests will go somewhere. An unencrypted request that matches no domain name receives 503; in HTTPS, if the SNI does not match or the client does not send SNI, the connection is closed.
  • Expecting HTTP/3. In a vService whose Virtual hosting list is filled, protocols with the HTTP/3 badge are not offered.

How it is done in the documentation

Related questions