Topology for this and further cases until said otherwise is:

First are health checks. These will be HTTP real servers listening on port 80, so it is logical to check periodically connection to port 80 and issue HTTP HEAD command to get status as a reply, 200 (Success) being the expected one.

We do so in Shared Resources → Health Checks → New…​

Next in Server Load Balance → Real Server Pool → Create New…​

In new Real Server pool, we set IPv4, Static and Enable and the custom Health Check created above. After that we can add real servers, specifying for each its IP address, listening port, and leaving Health Check “Inherited” to be set for all real servers just once on the Real Server Pool level by clicking on member → Create New:

Example of settings for RTR1 real server:

The final step is Virtual Server to tie together all the configs done so far.

Server Load Balance → Create New → Basic/Advanced…​ the choice of Basic or Advanced is for initial wizard only, after the Virtual Server (vserver) has been created, editing it will have the same options. Here I pick Basic → HTTP:

Next, I set IP address for vserver – this is the IP seen by the end clients, and for which, for this case I created a domain record of vpn.yurisk.com that points to 10.100.102.123.

After saving, we got a whole lots of options 99% of which can be left on defaults:

For this case, I will only pick the built-in Round-robin for the balancing method:

And will enable Traffic Logs for this vserver, be careful if doing this on production server as may overload the FAD with extensive logging:

Whole configuration on CLI

Verifying

On end client PC, trying vpn.yurisk.com in the browser gets me once to RTR1, once to RTR2 after few refreshes:

On the RTR2 server side, end client connection is seen with the source IP of 10.100.102.90 – IP set on port1 of the FAD and which FAD is using according to the route table when proxying incoming connection to the real server RTR2. The end client IP is 10.100.102.19 but real server does not see it:

On the real server RTR1, the sniffer shows health checks done by FAD – HEAD on port 80:

FAD is using strangely named User-Agent of KeepAliveClient.

When you hear time limitation – think Schedule, just as in Fortigate. So let’s create a schedule for 08:00-20:30.

Shared Resources → Schedule Group → New …​ After saving (basically just name) Schedule Group, you can add Member(s) – actual schedule(s).

I call the group DAY_HOURS, and inside it create a schedule named DAYS_HOURS_ONLY:

I go then to the vserver I created earlier, click on Edit and enable Schedule Pool, after which I double click on “Create New” and create new Schedule Pool named UP_TO_20-30 combining real servers pool with schedule group:

CLI configuration (only changes from above):

Verification. After the clock reaches 20:31 I try to enter the vpn.yurisk.com and instead of real server page, see the default error message:

Regarding the actual contents of a web page check – I created in each real server the page named monitor.html which is actually a text file that contains: on RTR1 the phrase “RTR1 All is good” and on RTR2 “RTR2 All is good”. Then I configure 2 health checks for each router, as each router will present a different string in the page to match (for demonstration purposes only – I could put the same string to match in both servers’ pages and then would only need 1 health check of both).

Health Check for RTR1:

Using the health checks in the Real Server Pool – we have 2 options here, either put both checks at the pool level and change their Relationship from AND to OR, i.e. it will be enough for any of 2 checks to be successful. Or, more orderly, remove health check at pool level, and set them individually at each server level. I will do the 2nd option.

The 1st option – setting health check on Real Server Pool level would look like that:

For the set up I want, I will edit each real server under real servers pool, here is RTR1:

As you can see, I added 2 health checks – one checks contents of the returned page, second one checks that status is 200 (OK), even though I could check status inside the 1st, page checking monitor.

I do the same for the RTR2:

And will remove the health check at the real server pool level:

CLI Configuration (only changes):

For verification I will shut down RTR1, the health checks changes to warning and RTR1 is removed from active servers:

When switching old subdomains to new locations, you usually set up a DNS redirect via a CNAME record to point to the new name/location. However, the client’s browser will still be using the old Host header. For example, if you had oldvpn.yurisk.com hosting your website and moved it to vpn.yurisk.com, browsers with oldvpn.yurisk.com configured will continue sending oldvpn.yurisk.com as the Host header value even to the new location. And if the new webserver does not recognize this domain, it will return an Error 404 “Not Found”.

To prevent this, we can create Content Rewriting (applicable to HTTP only) rule for all incoming HTTP requests for their Host header to be re-written to the correct vpn.yurisk.com in each client’s request.

You do so in the Server Load Balance → Virtual Server → Content Rewriting → New…​ by creating a new Rewrite rule(s), and then attaching it inside the Virtual Server config. The matching can be either string or regex, I will use regex here that will match any value of Host header:

Now attach it to the vserver:

CLI Configuration.

Verification Doing sniffer on FAD, I can see that HTTP request comes from end client for the Host of oldvpn.yurisk.com but then is replaced with vpn.yurisk.com when exits the FAD to the real server (RTR2 here). Client IP is 10.100.102.5:

The finished logical diagram will be seen in FortiView → Logical Topology:

I’ll start the same way as with HTTP – create Health Check for FTP.

Then I create a Real Server Pool with 2 FTP servers, and add the Health Check to it.
Here, RTR1 – 10.100.102.113, RTR2 – 10.100.102.115. I will use the same Health Check for both servers, as file name to check monitor.txt is the same on both servers. I will use the default FTP port 21.

And, finally, the Virtual Server. It will be different from the HTTP one in that I will create Layer 4 vserver, as FortiADC only supports Layer 7 for HTTP and HTTPS. I will use the default FTP port 21, and will set the load balancing method to Round Robin. Also, I will have to create and use Full NAT as forwarding method, as Layer 4 vserver does not act as full Layer 7 proxy, and does not change the source IP of the client to the FAD IP. This is important for FTP, as FTP uses 2 connections – control and data, and the data connection is opened by the server to the client, so if the client IP is not changed to FAD IP, the server will try to connect back to the client IP directly, bypassing the FAD, which will not work.

NAT Source Pool used in Vserver:

In General properties I set the Round-robin algo:

Verification The active connecitons can be seen in FortiView → All Sessions:

Here, the client to FTP connection is to port 21, and FTP server to client data transfer
connection is sourced from port 20 on the server.

When serving multiple domains on the same WAN IP (here 10.100.102.123) but using different real servers for each domain, FortiADC’s Content Routing will be the one to use. It routes requests to real servers based on Layer 4 or Layer 7 info. For subdomains, Layer 7 is used to route based on the Host header. Thus, oldvpn.yurisk.com is routed to RTR3 (10.100.102.117), while vpn.yurisk.com is routed to RTR1 and RTR2.

The finished Logical Topology can be seen in FortiView → Logical Topology:

The final table or Real Servers will look:

RTR1 & RTR2 Pool:

RTR3 Pool:

RTR1, RTR2, and RTR3 Pool (will be assigned at Vserver level, will be used if the first 2 pools fail):

Final look of all Real Servers Pools:

Rule for vpn.yurisk.com matching the Host header via regex:

Rule for oldvpn.yurisk.com:

Final look of Content Routing rules:

Finally, I will combine all the above into the Virtual Server. Not seen here, but when creating the vserver, I have to specify the default/fallback pool (the one with all 3 servers) in the Real Servers Pool field. I cannot leave it empty. But the Content Routing rules, which I enable and specify, will be used to route the traffic to the correct pool based on the Host header as they have precedence over the default Server Pool.

Verification

I will try to enter from the same client PC 10.100.102.19 to both web pages – oldvpn.yurisk.com and vpn.yurisk.com. The first one will be routed to RTR3, the second one to RTR1 or RTR2.