Fortinet Lab: Notes for FortiADC Labs– Application Delivery Part 1

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

1. Click on Networking > Interfaces.
   
   
2. Select port2 and click the Edit icon   on the right.
   
   
3. Under Allow Access, enable the HTTPS, Ping, SSH, HTTP.
   
   
4. Scroll down to the Mode Specifics section.
   
   
5. For IPv4/Netmask enter 172.16.99.144/24.
   
   
   
   
6. Click Save.
   
   
7. Select port3 and click Edit icon 
   
   
8. Under Allow Access, enable the HTTPS, Ping, SSH, HTTP.
   
   
9. Scroll down to the Mode Specifics section.
   
   
10. For IPv4/Netmask enter 172.16.100.144/24.
    
    
    
    
11. Click Save.
    
    

To test network connectivity

1. From the upper right side of the FortiADC menu bar, open the CLI interface using the >_ icon.
   
   
2. 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.
   
   

To configure the network routes

1. Navigate to Networking > Routing > Static.
   
   
2. Click Create New.
   
   
3. Leave the Destination at defaults (0.0.0.0/0).
   
   
4. Enter the Gateway address of 172.16.99.254.
   
   
   
   
5. 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

1. From the Lab Activity: FortiADC sidebar menu, access FortiADC-1 using the HTTPS option.
   
   
2. Log in using the username: admin and the password: Fortinet1!.
   
   
3. Click Shared Resources > Health Check.
   
   
4. Click Create New and configure the following settings:
   • Name: TCP_Check
   • Type: TCP
   • Port:  80
   • Interval (sec): 20
   • Timeout (sec): 10
     
     
5. Click Save.
   
   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

1. On the FortiADC-1 GUI, click Server Load Balance > Real Server Pool > Real Server Pool.
   
   
2. Click Create New, and configure the following settings:
   • Name: Ap_Servers
   • Address Type: IPv4
   • Health Check: On
     
     
3. In the Available Items box, double-click TCP_Check to add it to the Selected Items box.
   
   
4. Leave the Real Server SSL Profile value at NONE.
   
   
5. Click Save.

To add members to the real server pool

1. Click the edit icon ( ) to edit the Ap_Servers real server pool.
   
   
2. Scroll down to the Member pane, and then click Create New to add the first member.
   
   
3. Enter the following settings:
   • Status: Enable
   • Real Server: Create New
     
     
4.  In the newly opened window, configure the following information to create the Real Server:
   • Name: AppSrv1
   • Status: Enable
   • Address: 172.16.100.41
     
     
5. Click Save to return to the Real Server Pool > Edit Member window.
   
   
6. Keep the default values for the remaining settings, and then click Save.
   
   
7. Click Create New to create the second member.
   
   
8. Enter the following settings:
   • Status: Enable
   • Real Server: Create New
     
     
9. In the newly opened window, configure the following information to create the Real Server:
   • Name: AppSrv2
   • Status: Enable
   • Address: 172.16.100.42
     
     
10. Click Save to return to the Real Server Pool > Edit Member window.
    
    
11. Keep the default values for the remaining settings, and then click Save.
    
    
12. Click Create New to create the third member.
    
    
13. Enter the following settings:
    • Status: Enable
    • Real Server: Create New
      
      
14. In the newly opened window, configure the following information to create the Real Server:
    • Name: AppSrv3
    • Status: Enable
    • Address: 172.16.100.43
      
      
15. Click Save to return to the Real Server Pool > Edit Member window.
    
    
16. Keep the default values for the remaining settings, and then click Save.
    
    
17. Click Save to close the Real Server Pool window.

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

1. On the FortiADC-1 GUI, click Server Load Balance > Virtual Server > Virtual Server.
   
   
2. Click Create New, and then, in the drop-down list, select Advanced Mode to create the virtual server.
   
   
3. On the Basic tab, configure the following settings:
   • Name: TCP_VS
   • Status: Enable
   • Type: Layer 4
   • Address Type: IPv4
     
     
4. 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
     
     
5. Keep the default values for all other settings, and then click Save.

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.

1. From the Lab Activity: FortiADC sidebar menu, access Kali using the RDP option.
   
   
2. Click Start.
   
   
   
3. On the Kali VM, open Terminal Emulator from the system bar (upper left corner).
   
   
4. 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

1. While the traffic generator runs, return to the GUI of the FortiADC-1, click Dashboard > Main > Virtual Server Summary > See Details.
   
   
   
   
2. In the Summary section, select the TCP_VS and click Enable Analytics.
   
   
   
   
3. Click OK on the below warning screen.
   
   
   
   
4. Click Ap_Servers in the TCP_VS row to display the real server details.
   
   
   
   
5. 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

1. From the Lab Activity: FortiADC sidebar menu, access AppSrv3 using the SSH option.
   
   
2. Log in using the username: root and the password: Fortinet1!
   
   
3. At the AppSrv3 command prompt, stop the web server using the following command:
   [root@AppSrv3 ~]#service httpd stop

To test the TCP-based health check

1. From the Lab Activity: FortiADC sidebar menu, connect to Kali using the RDP option.
   
   
2. From the Kali desktop open the Firefox web browser and connect to the virtual server at http://172.16.99.146.
   
   
3. Press CTRL+SHIFT+R several times to reload the web page.
   
   
4. 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.

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.

1. Return to the AppSrv3 SSH session.
   
   
2. Run the following command:
   [root@AppSrv3 ~]# service httpd start
   
   
3. Run the following command to change the AppSrv3 home page:
   [root@AppSrv3 ~]# cp /var/www/html/wrongindex.html /var/www/html/index.html
   
   
4. Type Y, and then press Enter to confirm the change in the index.html file.
   
   
5. Return to the Kali tab
   
   
6. Select the browser tab that is running the connection to the virtual server and, press CTRL+SHIFT+R several times to refresh the browser.
   
   
7. 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

1. From the Lab Activity: FortiADC sidebar menu, access FortiADC-1 using the HTTPS option.
   
   
2. Log in using the username: admin and the password: Fortinet1!.
   
   
3. Click Shared Resources > Health Check.
   
   
4. 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
     
     
5. Click Save.
   
   

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.

1. Click Server Load Balance > Real Server Pool > Real Server Pool.
   
   
2. Click the edit icon ( ) to edit Ap_Servers.
   
   
3. In the Selected Items list, double-click TCP_Check to remove it.
   
   
4. In the Available Items list, double-click HTTP_Check to add it.
   
   
   
   
5. Click Save.
   
   
6. Notice the change in the Availability of the server pool.
   
   
   
   
7. From the Lab Activity: FortiADC sidebar menu, access Kali using the RDP option.
   
   
8. Open the web browser and navigate to http://172.16.99.146.
   
   
9. 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

1. From the Lab Activity: FortiADC sidebar, access AppSrv3 using the SSH option.
   
   
2. Restore the home page using the following command:
   
   [root@AppSrv3 ~]# cp /var/www/html/rightindex.html /var/www/html/index.html
   
   
3. Type Y, and then press ENTER to confirm the change in the index.html file.
   
   
4. Restart the HTTPD service by typing the following command:
   
   service httpd restart
   
   
5. Close the SSH tab.

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

1. From the Lab Activity: FortiADC sidebar menu, access FortiADC-1 using the HTTPS option.
   
   
2. Log in using the username admin and the password Fortinet1!.
   
   
3. Click Server Load Balance > Real Server Pool.
   
   
4. Click the edit icon ( ) to edit Ap_Servers.
   
   
5. Double-click AppSrv3 to edit it.
   
   
6. Turn on Backup, and then click Save.
   
   
7. Click Save to change the real server pool.

To test the backup server when all the servers are running

1. From the Lab Activity: FortiADC sidebar menu, access Kali using the RDP option.
   
   
2. Open a web browser and connect to the virtual server at http://172.16.99.146.
   
   
3. 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.

To test the backup server when one server is running

1. From the Lab Activity: FortiADC sidebar menu, access Web Servers using the SSH option.
   
   
2. 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
   
   
3. From the  Lab Activity: FortiADC sidebar menu, access Kali using the RDP option.
   
   
4. On the browser connected to http://172.16.99.146, press CTRL+SHIFT+R several times to refresh the browser.
   
   
5. You will observe that only AppSrv2 responds.
   
   

To test the backup server when all servers are down

1. From the Lab Activity: FortiADC sidebar menu, access Web Servers using the SSH option.
   
   
2. 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
   
   
3. From the Lab Activity: FortiADC sidebar menu, access Kali using the RDP option.
   
   
4. On the browser connected to http://172.16.99.146, press CTRL+SHIFT+R several times to refresh the browser.
   
   
5. After a few refreshes, traffic is now routed to AppSrv3.

Disable a Backup Server

In this exercise, you will disable the backup server configured in the real server pool.

To activate the application servers

1. From the Lab Activity: FortiADC sidebar menu, access Web Servers using the SSH option.
   
   
2. 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
   
   
3. Verify that both docker images have started

To disable the backup server

1. From the Lab Activity: FortiADC sidebar menu, access FortiADC-1 using the HTTPS option.
   
   
2. Click Server Load Balance > Real Server Pool.
   
   
3. Click the edit icon ( ) to edit Ap_Servers.
   
   
4. Double-click AppSrv3 to edit it.
   
   
5. Turn off Backup, and then click Save.
   
   
6. Click Save to change the real server pool.

To test the servers

1. From the Lab Activity: FortiADC sidebar menu, access Kali using the RDP option.
   
   
2. 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

1. From the Lab Activity: FortiADC sidebar menu, access FortiADC-1 using the HTTPS option.
   
   
2. Log in using the username: admin and the password: Fortinet1!.
   
   
3. Click Server Load Balance > Application Resources > Persistence.
   
   
4. Click Create New to create a new persistence method using the following settings:
   
   Name: IP_Persistence
   Type: Source Address
   Timeout (sec): 600
   
   
5. Keep the default values for the other settings, and then click Save.
   
   
6. Click Server Load Balance > Virtual Server > Virtual Server.
   
   
7. Click the edit icon ( ) to edit the new virtual server TCP_VS.
   
   
8. On the General tab, change the Persistence setting to IP_Persistence, and then click Save.
   
   

To test the IP-based persistence

1. From the Lab Activity: FortiADC sidebar menu, access Kali using the RDP option.
   
   
2. Open a web browser and connect to the virtual server at http://172.16.99.146.
   
   
3. 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.

1. From the Lab Activity: FortiADC sidebar menu, access FortiADC-1 using the HTTPS option.
   
   
2. Log in using the username: admin and the password: Fortinet1!.
   
   
3. Click Server Load Balance > Real Server Pool > Real Server Pool.
   
   
4. Click the edit icon ( ) to edit the real server pool Ap_Servers.
   
   
5. 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

1. From the Lab Activity: FortiADC sidebar menu, access FortiADC-1 using the SSH option.
   
   
2. Log in as admin with the password Fortinet1!
   
   
3. Enter the following CLI command to enable the sniffer and capture of HTTP traffic:
   
   # diagnose sniffer packet port3 “port 80” 4
   
   
4. Leave the FortiADC-1 SSH browser tab open so that you can return to it.
   
   
5. From the Lab Activity: FortiADC sidebar menu, access Kali using the RDP option.
   
   
6. Open a web browser and connect to the virtual server at http://172.16.99.146.
   
   
7. Leave the Kali RDP tab open so you can return to it.
   
   
8. 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.
   
   
9. Leave the FortiADC-1 SSH browser tab open so you can return to it.

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.

1. From the Lab Activity: FortiADC sidebar menu, access FortiADC-1 using the HTTPS option.
   
   
2. Click Server Load Balance > Virtual Server > NAT Source Pool.
   
   
3. 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


     
     
4. Click Save.
   
   

To apply the source IP pool to the virtual server

1. Click Server Load Balance > Virtual Server > Virtual Server.
   
   
2. Click the edit icon ( ) to edit the virtual server TCP_VS.
   
   
3. On the Basic tab, scroll down to the Specifics section.
   
   
4. Change the Packet-Forwarding Method setting to Full NAT.
   
   
5. In the Available Items list, double-click SourcePool.
   
   
   
   
6. Click Save.
   
   

To capture the traffic using full NAT

1. Return to the Kali RDP tab, and then press CTRL+SHIFT+R to refresh the browser.
   
   
2. Return to the FortiADC-1 SSH tab, and observe the sniffer output:
   
   
     
   The source IP address of the user traffic was translated. The FortiADC device uses an IP address from the source pool for that purpose.