With bandwidth demand growing faster than budgets, and with cyberattacks constantly on the rise, it can be challenging to securely, and efficiently, deliver applications at the speed users expect. Fortinet Application Delivery Controller (FortiADC) optimizes the availability, user experience, and application security of enterprise applications. FortiADC provides application availability using Layer 4/Layer 7 load balancing, data center resiliency, application optimization, and a web application firewall (WAF) to protect web applications from the OWASP Top 10 and many other threats.
FortiADC provides unmatched load balancing and web security, regardless of whether it is used for applications across a single data center or to serve multiple applications to millions of users around the globe. It includes application performance, WAF, global server load balancing, link load balancing, and user authentication all in one solution to deliver availability, performance, and security in a single all-inclusive license.
In this workshop, you explore and experience some of the key features and benefits that FortiADC can provide, including load balancing within the data center, global load balancing and redundancy, and basic elements of providing enhanced network security.
How the Labs look like:
Network Topology
The basic design includes an internet-facing FortiGate, with a FortiADC device with interfaces in a DMZ (port2), and a data center (port3). The data center contains three application servers.
The Jumpbox server provides management access using the out-of-band management network, while the Kali Linux device serves as an external user/attacker
Introduction
This set of activities introduces FortiADC's administrative GUI. Additionally, the activities guide you through how to correctly configure the initial interfaces and subnet settings to provide access between the Primary FortiADC device and back-end application servers, as well as internet-facing infrastructure.
Objectives
- Access the FortiADC GUI
- Explore the FortiADC system configuration
- Configure the initial network settings
- Configure the FortiADC time zone
- Test network connectivity
FortiADC GUI Interface:
To configure the network interfaces
- Click on Networking > Interfaces.
- Select port2 and click the Edit icon on the right.
- Under Allow Access, enable the HTTPS, Ping, SSH, HTTP.
- Scroll down to the Mode Specifics section.
- For IPv4/Netmask enter
172.16.99.144/24
.
- Click Save.
- Select port3 and click Edit icon
- Under Allow Access, enable the HTTPS, Ping, SSH, HTTP.
- Scroll down to the Mode Specifics section.
- For IPv4/Netmask enter
172.16.100.144/24
.
- Click Save.
172.16.99.144/24
.172.16.100.144/24
.To test network connectivity
- From the upper right side of the FortiADC menu bar, open the CLI interface using the >_ icon.
- Type the following commands to test network connectivity:
# execute ping 172.16.99.254
# execute ping 172.16.100.41
# execute ping 172.16.100.42
# execute ping 172.16.100.43
The outputs should be successful: 5 packets transmitted, 5 packets received, 0% packet loss. This verifies connectivity to FortiGate-EDGE, as well as all application servers.
3. Click the CLI icon on the menu bar again to close the CLI window.
# execute ping 172.16.99.254
# execute ping 172.16.100.41
# execute ping 172.16.100.42
# execute ping 172.16.100.43
The outputs should be successful: 5 packets transmitted, 5 packets received, 0% packet loss. This verifies connectivity to FortiGate-EDGE, as well as all application servers.
3. Click the CLI icon on the menu bar again to close the CLI window.
To configure the network routes
- Navigate to Networking > Routing > Static.
- Click Create New.
- Leave the Destination at defaults (0.0.0.0/0).
- Enter the Gateway address of
172.16.99.254
.
- Click Save.
- Navigate to Networking > Routing > Static.
- Click Create New.
- Leave the Destination at defaults (0.0.0.0/0).
- Enter the Gateway address of
172.16.99.254
. - Click Save.
Server Load Balancing
Introduction
In part one of this series of activities you configure a Layer 4 virtual server to balance traffic among the three application servers. You will also configure a backup server, enable and test source-IP persistence, and use full NAT for packet forwarding.
In part two of this series of activities, you create a Layer 7 virtual server for HTTP traffic balancing and inspection. You will learn to configure and test cookie persistence and content routes.
In part three, you configure SSL Offloading, allowing the FortiADC to manage all HTTPS connections from clients while retaining HTTP connections with the back-end application servers.
Note: While you do the following exercises, you must work on only the FortiADC-1 device.
Objectives
- Create a Layer 4 virtual server to balance TCP traffic
- Configure one of the application servers as a backup server so it will be used only when no other real server is available to the virtual server
- Enable and test source-IP persistence to route all the traffic coming from the same source IP address to the same real server
- Use full NAT as the packet forwarding mode, so the FortiADC device will translate not only the destination IP address but also the source IP address
- Configure content routes to properly route users connecting to a specific web folder located on one of the servers
- Enable and test cookie persistence to route all the traffic coming from the same user to the same server
- Enable HTTPS access by offloading the encryption and decryption of SSL traffic to the FortiADC
- Create a Layer 7 virtual server for balancing and inspecting HTTP traffic
Configure Layer 4 Server Load Balancing
In this series of exercises, you explore the principles of configuring the basic elements required for load balancing at Layer 4. These elements include:
- Real server pools
- Virtual server
- health checks
- Backup servers
- IP-based persistence
- Full NAT
After configuring each element, you test the configuration to see the capability in action.
Configure Real Server Pool
Tasks
To define the health check rules
- From the Lab Activity: FortiADC sidebar menu, access FortiADC-1 using the HTTPS option.
- Log in using the username:
admin
and the password:
Fortinet1!
.
- Click Shared Resources > Health Check.
- Click Create New and configure the following settings:
- Name:
TCP_Check
- Type:
TCP
- Port:
80
- Interval (sec):
20
- Timeout (sec):
10
- Click Save.
Note: FortiADC uses server health checks to determine whether a real server is available for use in a load-balancing configuration.
admin
and the password:
Fortinet1!
.- Name:
TCP_Check
- Type:
TCP
- Port:
80
- Interval (sec):
20
- Timeout (sec):
10
Note: FortiADC uses server health checks to determine whether a real server is available for use in a load-balancing configuration.
To create a real server pool
- On the FortiADC-1 GUI, click Server Load Balance > Real Server Pool > Real Server Pool.
- Click Create New, and configure the following settings:
- Name:
Ap_Servers
- Address Type:
IPv4
- Health Check:
On
- In the Available Items box, double-click TCP_Check to add it to the Selected Items box.
- Leave the Real Server SSL Profile value at NONE.
- Click Save.
- Name:
Ap_Servers
- Address Type:
IPv4
- Health Check:
On
To add members to the real server pool
- Click the edit icon ( ) to edit the Ap_Servers real server pool.
- Scroll down to the Member pane, and then click Create New to add the first member.
- Enter the following settings:
- Status:
Enable
- Real Server:
Create New
- In the newly opened window, configure the following information to create the Real Server:
- Name:
AppSrv1
- Status:
Enable
- Address:
172.16.100.41
- Click Save to return to the Real Server Pool > Edit Member window.
- Keep the default values for the remaining settings, and then click Save.
- Click Create New to create the second member.
- Enter the following settings:
- Status:
Enable
- Real Server:
Create
New
- In the newly opened window, configure the following information to create the Real Server:
- Name:
AppSrv2
- Status:
Enable
- Address:
172.16.100.42
- Click Save to return to the Real Server Pool > Edit Member window.
- Keep the default values for the remaining settings, and then click Save.
- Click Create New to create the third member.
- Enter the following settings:
- Status:
Enable
- Real Server:
Create New
- In the newly opened window, configure the following information to create the Real Server:
- Name:
AppSrv3
- Status:
Enable
- Address:
172.16.100.43
- Click Save to return to the Real Server Pool > Edit Member window.
- Keep the default values for the remaining settings, and then click Save.
- Click Save to close the Real Server Pool window.
- Status:
Enable
- Real Server:
Create New
- Name:
AppSrv1
- Status:
Enable
- Address:
172.16.100.41
- Status:
Enable
- Real Server:
Create
New
- Name:
AppSrv2
- Status:
Enable
- Address:
172.16.100.42
- Status:
Enable
- Real Server:
Create New
- Name:
AppSrv3
- Status:
Enable
- Address:
172.16.100.43
Background
The virtual server is another mandatory setting that you must configure in FortiADC server load balancing. The virtual server provides the Internet facing IP address, and links to the real server pool, which faces the application servers in the datacenter.
Configure a Virtual Server
To create a virtual server
- On the FortiADC-1 GUI, click Server Load Balance > Virtual Server > Virtual Server.
- Click Create New, and then, in the drop-down list, select Advanced Mode to create the virtual server.
- On the Basic tab, configure the following settings:
- Name:
TCP_VS
- Status: Enable
- Type: Layer 4
- Address Type: IPv4
- On the General tab, configure the following settings:
- Address:
172.16.99.146
- Port:
80
- Interface: Port2
- Profile: LB_PROF_TCP
- Method: LB_METHOD_ROUND_ROBIN
- Real Server Pool: Ap_Servers
- Keep the default values for all other settings, and then click Save.
- Name:
TCP_VS
- Status: Enable
- Type: Layer 4
- Address Type: IPv4
- Address:
172.16.99.146
- Port:
80
- Interface: Port2
- Profile: LB_PROF_TCP
- Method: LB_METHOD_ROUND_ROBIN
- Real Server Pool: Ap_Servers
Test the Virtual Server
To test the virtual server
Next, you will test the virtual server by generating a significant amount of traffic against the virtual server.
- From the Lab Activity: FortiADC sidebar menu, access Kali using the RDP option.
- Click Start.
- On the Kali VM, open Terminal Emulator from the system bar (upper left corner).
- To generate traffic to the virtual server, type the following command:
slowhttptest -c 400 -r 6 -p 100 -u http://172.16.99.146
- -c number of connections (400)
- -r rate of connections per second (6)
- -p timeout in seconds to wait for HTTP response (100)
- -u absolute URL of target
- While the traffic generator runs, return to the GUI of the FortiADC-1, click Dashboard > Main > Virtual Server Summary > See Details.
- In the Summary section, select the TCP_VS and click Enable Analytics.
- Click OK on the below warning screen.
- Click Ap_Servers in the TCP_VS row to display the real server details.
- Notice that the traffic is distributed evenly among the three real application servers.
Testing the TCP-Based Health Check
Background
The health check is an optional object that you can set up to poll the server frequently. FortiADC assumes the server is up and responsive as soon as the server replies to a specific number of consecutive polls.
FortiADC supports different methods to perform the health check: ICMP or TCP echo request; HTTP or HTTPS; TCP, TCP-SSL or TCP-half open; DNS; Radius, SMTP, POP3 or IMAP4; FTP and SNMP.
The virtual server TCP_VS is currently configured with a TCP-based health check. This means that the FortiADC device periodically checks that TCP port 80 is open on each server by completing a TCP three-way handshake connection.
To test it, you will stop the web service on application server 3 (AppSrv3). Then, you will test the limitations of the TCP-based health check.
In this exercise, you test and compare the TCP and HTTP methods.
To stop AppSrv3
- From the Lab Activity: FortiADC sidebar menu, access AppSrv3 using the SSH option.
- Log in using the username:
root
and the password: Fortinet1!
- At the AppSrv3 command prompt, stop the web server using the following command:
[root@AppSrv3 ~]#service httpd stop
root
and the password: Fortinet1!
[root@AppSrv3 ~]#
service httpd stop
- From the Lab Activity: FortiADC sidebar menu, connect to Kali using the RDP option.
- From the Kali desktop open the Firefox web browser and connect to the virtual server at
http://172.16.99.146
.
- Press CTRL+SHIFT+R several times to reload the web page.
- You should see that the connections now go to either Application Server 1 (AppSrv1) or Application Server 2 (AppSrv2). The TCP-based health check detected a problem on AppSrv3, so the device is not routing any traffic there.
http://172.16.99.146
.
To test an HTTP limitation using the TCP-based health check
Now, you will simulate a different problem on AppSrv3. This time, the web service is up and running, but it can’t display the website home page correctly.
- Return to the AppSrv3 SSH session.
- Run the following command:
[root@AppSrv3 ~]#service httpd start
- Run the following command to change the AppSrv3 home page:
[root@AppSrv3 ~]#cp /var/www/html/wrongindex.html /var/www/html/index.html
- Type
Y
, and then press Enter to confirm the change in the index.html file. - Return to the Kali tab
- Select the browser tab that is running the connection to the virtual server and, press CTRL+SHIFT+R several times to refresh the browser.
- AppSrv1 and AppSrv2 are fine. When you attempt to connect to the AppSrv3, you will see the following message:
Create HTTP-Based Health Check
Background
In this exercise, you will query the server by sending a GET request to verify if the HTTP service is up. You can also do this by sending a HEAD request.
To set up an HTTP-based health check
- From the Lab Activity: FortiADC sidebar menu, access FortiADC-1 using the HTTPS option.
- Log in using the username:
admin
and the password: Fortinet1!
.
- Click Shared Resources > Health Check.
- Click Create New to create a new health check using the following settings:
- Name: HTTP_Check
- Type: HTTP
- Port:
80
- HTTP Connect: No Connect
- Method Type: HTTP Get
- Send String:
/index.html
- Receive String: FortiADC
- Status Code:
200
- Match Type: Match String
- Interval (sec):
20
- Timeout (sec):
10
- Click Save.
admin
and the password: Fortinet1!
.- Name: HTTP_Check
- Type: HTTP
- Port:
80
- HTTP Connect: No Connect
- Method Type: HTTP Get
- Send String:
/index.html
- Receive String: FortiADC
- Status Code:
200
- Match Type: Match String
- Interval (sec):
20
- Timeout (sec):
10
To apply the HTTP-based health check to the real server pool
Now that you have created the new health check, you must change the real server pool to use HTTP_Check instead of TCP_Check.
- Click Server Load Balance > Real Server Pool > Real Server Pool.
- Click the edit icon ( ) to edit Ap_Servers.
- In the Selected Items list, double-click TCP_Check to remove it.
- In the Available Items list, double-click HTTP_Check to add it.
- Click Save.
- Notice the change in the Availability of the server pool.
- From the Lab Activity: FortiADC sidebar menu, access Kali using the RDP option.
- Open the web browser and navigate to
http://172.16.99.146
. - Press CTRL+SHIFT+R several times to refresh the browser. Note: that the load is only being distributed between AppSrv1 and AppSrv2.
Change AppSrv3 Web Page
- From the Lab Activity: FortiADC sidebar, access AppSrv3 using the SSH option.
- Restore the home page using the following command:
[root@AppSrv3 ~]# cp /var/www/html/rightindex.html /var/www/html/index.html
- Type Y, and then press ENTER to confirm the change in the index.html file.
- Restart the HTTPD service by typing the following command:
service httpd restart
- Close the SSH tab.
[root@AppSrv3 ~]#
cp /var/www/html/rightindex.html /var/www/html/index.html
service httpd restart
Configure a Backup Server
Background
You can designate a server as a backup server, which will be used only if one of the other servers in the real server pool fails to respond. In this exercise, you configure and test a backup server in the real server pool. Once you have successfully observed and tested the backup server capability, you will disable it again.
To set up a backup server
- From the Lab Activity: FortiADC sidebar menu, access FortiADC-1 using the HTTPS option.
- Log in using the username
admin
and the password Fortinet1!
.
- Click Server Load Balance > Real Server Pool.
- Click the edit icon ( ) to edit Ap_Servers.
- Double-click AppSrv3 to edit it.
- Turn on Backup, and then click Save.
- Click Save to change the real server pool.
admin
and the password Fortinet1!
.- From the Lab Activity: FortiADC sidebar menu, access Kali using the RDP option.
- Open a web browser and connect to the virtual server at http://172.16.99.146.
- Press CTRL+SHIFT+R several times to refresh the web page. Connections now go to only the AppSrv1 and AppSrv2. The AppSrv3 is only a backup server.
- From the Lab Activity: FortiADC sidebar menu, access Web Servers using the SSH option.
- You will now stop the AppSrv1 Docker image to simulate a failure of this server. Stop the Docker image using the following commands
$ cd dockerdata/AppSrv1
$ docker-compose down
- From the Lab Activity: FortiADC sidebar menu, access Kali using the RDP option.
- On the browser connected to http://172.16.99.146, press CTRL+SHIFT+R several times to refresh the browser.
- You will observe that only AppSrv2 responds.
$ cd dockerdata/AppSrv1
$ docker-compose down
To test the backup server when all servers are down
- From the Lab Activity: FortiADC sidebar menu, access Web Servers using the SSH option.
- You will now stop the AppSrv2 Docker image to simulate a failure of this server. Stop the Docker image using the following commands
$ cd dockerdata/AppSrv2
$ docker-compose down
- From the Lab Activity: FortiADC sidebar menu, access Kali using the RDP option.
- On the browser connected to http://172.16.99.146, press CTRL+SHIFT+R several times to refresh the browser.
- After a few refreshes, traffic is now routed to AppSrv3.
$ cd dockerdata/AppSrv2
$ docker-compose down
Disable a Backup Server
In this exercise, you will disable the backup server configured in the real server pool.
To activate the application servers
- From the Lab Activity: FortiADC sidebar menu, access Web Servers using the SSH option.
- You will now start both the AppSrv1 and AppSrv2 Docker images Start the Docker images using the following commands
$ cd ../AppSrv1
$ docker-compose up –d
$ cd ../AppSrv2
$ docker-compose up –d
- Verify that both docker images have started
$ cd ../AppSrv1
$ docker-compose up –d
$ cd ../AppSrv2
$ docker-compose up –d
To disable the backup server
- From the Lab Activity: FortiADC sidebar menu, access FortiADC-1 using the HTTPS option.
- Click Server Load Balance > Real Server Pool.
- Click the edit icon ( ) to edit Ap_Servers.
- Double-click AppSrv3 to edit it.
- Turn off Backup, and then click Save.
- Click Save to change the real server pool.
To test the servers
- From the Lab Activity: FortiADC sidebar menu, access Kali using the RDP option.
- On the browser connected to http://172.16.99.146, press CTRL+SHIFT+R several times to refresh the browser. Traffic is routed to all the application servers.
Configure IP-Based Persistence
Background
Persistence methods are rules that identify traffic that should not be load-balanced but should be forwarded to the backend server that has processed requests from that source before. During this exercise, you will set up the IP-based persistence to route all the connections coming from the same source IP addresses to the same real servers. This is done to support server transactions that depend on an established client-server session.
To configure IP-based persistence
- From the Lab Activity: FortiADC sidebar menu, access FortiADC-1 using the HTTPS option.
- Log in using the username:
admin
and the password: Fortinet1!
.
- Click Server Load Balance > Application Resources > Persistence.
- Click Create New to create a new persistence method using the following settings:
Name: IP_Persistence
Type: Source Address
Timeout (sec): 600
- Keep the default values for the other settings, and then click Save.
- Click Server Load Balance > Virtual Server > Virtual Server.
- Click the edit icon ( ) to edit the new virtual server TCP_VS.
- On the General tab, change the Persistence setting to IP_Persistence, and then click Save.
admin
and the password: Fortinet1!
.Name: IP_Persistence
Type: Source Address
Timeout (sec):
600
To test the IP-based persistence
- From the Lab Activity: FortiADC sidebar menu, access Kali using the RDP option.
- Open a web browser and connect to the virtual server at http://172.16.99.146.
- Press CTRL+SHIFT+R several times to refresh the browser. Traffic is routed to the same application server.
Implement Full NAT
Background
When you apply full NAT, FortiADC changes both the source and destination IP addresses. You can use this when the real server’s gateway is not the load balancer and you want to prevent asymmetric traffic. In this exercise, you will use full NAT to translate both the source and destination IP addresses of the user traffic, to conceal the real server’s IP address.
To disable the health checks
You will disable all health checks to reduce the volume of traffic to the application servers.
- From the Lab Activity: FortiADC sidebar menu, access FortiADC-1 using the HTTPS option.
- Log in using the username:
admin
and the password:Fortinet1!
. - Click Server Load Balance > Real Server Pool > Real Server Pool.
- Click the edit icon ( ) to edit the real server pool Ap_Servers.
- Turn off Health Check and click Save.
Now only user-generated traffic arrives at the servers, and not health check traffic.
To capture the traffic without using NAT
- From the Lab Activity: FortiADC sidebar menu, access FortiADC-1 using the SSH option.
- Log in as
admin
with the password Fortinet1!
- Enter the following CLI command to enable the sniffer and capture of HTTP traffic:
# diagnose sniffer packet port3 “port 80” 4
- Leave the FortiADC-1 SSH browser tab open so that you can return to it.
- From the Lab Activity: FortiADC sidebar menu, access Kali using the RDP option.
- Open a web browser and connect to the virtual server at http://172.16.99.146.
- Leave the Kali RDP tab open so you can return to it.
- Return to the FortiADC-1 SSH tab, and observe the sniffer output:
Notice that the traffic is between the IP address 100.64.1.200 (which is the client IP address) and a real server IP (in the example above, 172.16.100.41). So, the FortiADC device is translating the destination IP address of the client traffic from the virtual server IP address to one of the real server IP addresses. The device, however, is not changing the source IP address because the Packet-Forwarding Method setting is currently configured as DNAT.
- Leave the FortiADC-1 SSH browser tab open so you can return to it.
admin
with the password Fortinet1!
# diagnose sniffer packet port3 “port 80” 4
Notice that the traffic is between the IP address 100.64.1.200 (which is the client IP address) and a real server IP (in the example above, 172.16.100.41). So, the FortiADC device is translating the destination IP address of the client traffic from the virtual server IP address to one of the real server IP addresses. The device, however, is not changing the source IP address because the Packet-Forwarding Method setting is currently configured as DNAT.
To create a source IP pool
The source pool will contain an IP address range to be used to translate the source IP of the user traffic.
- From the Lab Activity: FortiADC sidebar menu, access FortiADC-1 using the HTTPS option.
- Click Server Load Balance > Virtual Server > NAT Source Pool.
- Click Create New to create a new source pool using the following settings:
- Name:
SourcePool
- Interface: port2
- Address Type: IPv4
- Address Range:
172.16.99.151
- To:
172.16.99.158
- Name:
- Click Save.