Can I publish more than one website behind a single public IP?
Short answer
Yes, in two ways. With Virtual Hosting, each site becomes a separate HTTP vService and these vServices share the same IP:port; TR7 sends the request to the related vService according to the domain name (SNI in HTTPS, the Host Header in unencrypted traffic). In this method, each site has its own certificate, WAF and profiles. Or a single vService is used, and with Conditional Backend Services (Content Switching), each site is directed to different Backend Services according to the Host Header; in this method, the certificate, WAF and profiles are shared by all the sites. In both methods, the shared IP must first have been added to an interface under Network → Interfaces.
Problem: How Are Sites Told Apart on a Single IP?
Public IP addresses are limited, and most organizations publish their sites from port 443 of a single IP. Requests arriving at the same IP:port can be told apart only by the domain name: in unencrypted traffic it is written in the Host header, and in HTTPS in the SNI of the TLS handshake. TR7 needs to send the request to the right site according to this information.
Solution: Two Methods
| Your situation | Suitable method |
|---|---|
| The sites have different certificates, WAF settings, profiles or responsible teams | Method 1: Virtual Hosting |
| The sites will be managed with the same policy and will only go to different servers | Method 2: Single vService + Conditional Backend Services (Content Switching) |
Method 1: Virtual Hosting Recommended
- How it works A request arriving at the shared IP:port is forwarded to the related vService according to the Host Header or SNI; that vService terminates TLS with its own certificate.
- Where it is opened vService → Virtual Hosting → domain name list
- Requirement The shared IP must have been added to an interface (Add IP); the list must be filled in all the vServices that share the IP:port; all of them must be in the same encryption class (all HTTPS or all unencrypted)
- vService type HTTP only
Step-by-Step Configuration
The Load Balancer → Load Balancer vService List steps are followed, and the HTTP vService of the first site is opened (or created with Add).
The Virtual Hosting switch is turned on; the site's domain name is written in lowercase in the first row that appears (e.g. a.example.com).
In the Frontend row, the shared IP (if it is not in the list, it is first added to the interface with + Add IP), port 443 and a protocol from the Encrypted (HTTPS) group are selected; this site's certificate is selected in the Certificate field. If the vService is being newly created, the site's Backend Services are added to the Default Backend Services list.
The Save button is clicked.
A new HTTP vService is created with Add. In the Frontend row, the same IP and port as the first vService and a protocol in the same encryption class are selected.
Virtual Hosting is turned on and b.example.com is written; in HTTPS, the certificate of this domain name is selected in the Certificate field; the site's Backend Services are added to the Default Backend Services list. If the certificate is not in TR7, it is first uploaded with Certificates & PKI → SSL/TLS Certificates → Add (How do I upload my certificate to TR7; which formats are supported?). If the Backend Service does not exist yet, it is created without leaving the form with the Backend Service button in the selector, or with Load Balancer → Backend Services → Add; Backend Service Name and Address (address and port) are entered (How is a Backend Service added; which information is required?).
The Save button is clicked. In the vService list, a cloud icon appears in the Type cell of these vServices.
Verification
curl -v --resolve a.example.com:443:203.0.113.10 https://a.example.com/The certificate and page of a.example.com are returnedb.example.com; the two sites are seen to return different certificates and content.Method 2: Single vService + Conditional Backend Services (Content Switching)
- How it works A single vService receives all the sites; conditions that look at the Host Header send the request to the Backend Services of the related site (Content Switching by its industry name). The rules are evaluated from top to bottom, and the first match is applied.
- Where it is openedLoad Balancer → Conditions → HTTP Header (Host); vService → Conditional Backend Services (Content Switching)
- Requirement The shared IP must have been added to an interface; in HTTPS, certificate(s) that cover all the domain names
- vService type HTTP
Step-by-Step Configuration
The Load Balancer → Conditions → Add steps are followed.
HTTP Header is selected as the Criteria. The Header Name field comes filled with Host; Exact Match (default) is selected as the matching method, and the site's domain name is written as the value (e.g. a.example.com).
The Add button is clicked. Steps 1–3 are repeated for each site.
The Load Balancer → Load Balancer vService List steps are followed and the HTTP vService is opened (or created with Add). In the Frontend row, the shared IP, port and protocol are selected, and in HTTPS, the certificate(s) that cover all the domain names are selected in the Certificate field.
The + Conditional backend services button in the Default Backend Services table is clicked; for each rule, the condition saved in step 3 and the Backend Services of the related site are selected. If the Backend Service does not exist yet, it is created without leaving the form with the Backend Service button in the selector, or with Load Balancer → Backend Services → Add; Backend Service Name and Address (address and port) are entered (How is a Backend Service added; which information is required?).
Requests that match no condition go to the Default Backend Services list; if the list is empty, TR7 returns 503.
The Save button is clicked.
Verification
curl -v --resolve b.example.com:443:203.0.113.10 https://b.example.com/A response from the Backend Services of b.example.comCommon Mistakes
- Leaving the list of one of the vServices empty in Virtual Hosting. For sharing, the list must be filled in all the vServices; otherwise the Port collision warning appears.
- Making an encrypted and an unencrypted vService share the same IP:port. HTTPS and unencrypted rows cannot share the same IP:port.
- Using Exact Match on a port other than 80 and 443. The browser adds a non-standard port to the Host Header (
a.example.com:8080); in Method 2, Start or Regex matching is used. In Method 1, if unencrypted traffic is published on a non-standard port, the domain name is written to the Virtual Hosting list together with the port (a.example.com:8080); in HTTPS, matching is done with the SNI, which does not contain the port, and only the domain name is written to the list. - Writing domain names in uppercase. Virtual Hosting matching is case-sensitive; domain names are written in lowercase.
- Trying to open a vService without adding the shared IP to an interface. The Frontend IP list contains only the IPs added to interfaces; the IP is first added with Network → Interfaces → Add IP.
How it is done in the documentation
