Fortinet FortiADC Lab Guide for FortiADC 6.2

Citation preview

DO NOT REPRINT © FORTINET

FortiADC Lab Guide for FortiADC 6.2

DO NOT REPRINT © FORTINET Fortinet Training https://training.fortinet.com Fortinet Document Library https://docs.fortinet.com Fortinet Knowledge Base https://kb.fortinet.com Fortinet Fuse User Community https://fusecommunity.fortinet.com/home Fortinet Forums https://forum.fortinet.com Fortinet Support https://support.fortinet.com FortiGuard Labs https://www.fortiguard.com Fortinet Network Security Expert Program (NSE) https://training.fortinet.com/local/staticpage/view.php?page=certifications Fortinet | Pearson VUE https://home.pearsonvue.com/fortinet Feedback Email: [email protected]

12/22/2021

DO NOT REPRINT © FORTINET

TABLE OF CONTENTS Network Topology Lab 1: FortiADC Introduction Exercise 1: Configuring the Primary FortiADC

6 7 8

Configure the Primary FortiADC Using the CLI Access the Primary FortiADC GUI Test the Primary FortiADC Connectivity

8 9 10

Exercise 2: Configuring the Secondary FortiADC

12

Configure the Secondary FortiADC Using the CLI Access the Secondary FortiADC GUI Test the Secondary FortiADC Connectivity

12 12 14

Lab 2: Basic Server Load Balancing Exercise 1: Configuring the Layer 4 Virtual Server and Public IP Address Configure Health Check Rules and a Real Server Pool Configure a Virtual Server Test the Virtual Server Configure Virtual Server Public Access Test the Virtual Server Public IP Address

Exercise 2: Examining Health Check Methods Stop Web Services and Test the TCP-Based Health Check Test a Limitation of the TCP-Based Health Check Create an HTTP-Based Health Check Apply the HTTP-Based Heath Check

Exercise 3: Designating a Backup Server Configure a Backup Server Restore the Application Servers and Disable the Backup Server

Lab 3: Advanced Server Load Balancing Exercise 1: Configuring IP-Based Persistence

15 16 16 19 21 22 23

24 24 25 25 26

28 28 29

30 31

Configure IP-Based Persistence

31

Exercise 2: Configuring Full NAT

32

Configure Full NAT Create a Source IP Pool

Exercise 3: Configuring a Layer 7 Virtual Server Configure a Layer 7 Virtual Server

32 33

35 35

DO NOT REPRINT © FORTINET Exercise 4: Configuring Layer 7 Content Routing on a Virtual Server Configure Layer 7 Content Routing on a Virtual Server

Exercise 5: Configuring Cookie Insertion Persistence Configure Cookie Insertion on the Virtual Server

Exercise 6: Configuring SSL Offload Import a Signed Digital Certificate Create a New HTTPS Profile Configure the Virtual Server to Use an SSL Certificate

Lab 4: Link Load Balancing Exercise 1: Configuring Outbound Link Load Balancing Configure the Gateway Health Check and Link Group Configure a Link Policy Configure NAT Rules Test Outbound Link Load Balancing

Lab 5: Global Load Balancing Exercise 1: Configuring FortiADC-Secondary Configure a Health Check and Layer 7 Virtual Server Create a Real Server Pool With One Member Create Data Centers and Configure Global Load Balancing Reroute AppSrv3 Configure a FortiGate VIP and a Policy Test the New Route

Exercise 2: Reconfiguring FortiADC-Primary Reconfigure FortiADC-Primary Configure Global Load Balancing

Exercise 3: Testing the Global Load Balancing Configuration Test the Global Load Balancing Configuration Test Server Redundancy

Exercise 4: Configuring a DNS Zone and Policy on FortiADC-Secondary Configure a DNS Zone and Policy on FortiADC-Secondary

Exercise 5: Testing the DNS Redundancy Test Server Redundancy Test DNS Redundancy

37 37

43 43

45 45 46 47

50 51 51 54 54 55

58 59 60 60 62 64 65 67

68 68 69

73 73 73

75 75

78 78 79

Exercise 6: Configuring Gateway Monitoring for the GLB

81

Review the Link Load Balance Configuration Change the FortiADC-Secondary Virtual Server IP Address Configure Gateway Monitoring on GLB and Test Site_A

81 81 82

Exercise 7: Configuring Inbound Link Load Balancing for the GLB Create Layer 7 Virtual Servers Configure Gateway Monitoring on ILLB Virtual Servers Configure a Virtual Server Pool and DNS Zone Policy

84 84 86 87

DO NOT REPRINT © FORTINET Test ILLB GLB Lab 6: FortiADC Security Exercise 1: Configuring FortiADC Firewall Policies Configure a FortiADC Address Object Create the Firewall Policy Test the Firewall Policy

Exercise 2: Configuring WAF URL Protection Configure WAF URL Protection Test URL Protection

Exercise 3: Configuring a WAF HTTP Protocol Constraint Configure a WAF HTTP Protocol Constraint Test an HTTP Protocol Constraint

Lab 7: Scripts and the REST API Exercise 1: Configuring FortiADC Scripts Configure a Web Redirect Script Apply the Script to the Virtual Server Test the Web Redirect Script Configure a Content Routing Script Create Content Routes Test the Content Routing Script

Exercise 2: Configuring the FortiADC REST API Request a Bearer Token for API Authentication Making API Calls Using Postman Configure Server Load Balancing Validate the Virtual Server Settings

Lab 8: Troubleshooting Exercise 1: Troubleshooting Web Server Access Observe the Web Server Access Issue Inspect the External Traffic Flow Inspect the Internal Traffic Flow Resolve the Configuration Error Validate the Resolution

89

91 92 92 92 93

95 95 96

98 98 99

101 102 102 103 103 104 105 107

109 109 110 112 117

119 120 120 121 121 122 122

DO Network NOTTopology REPRINT © FORTINET Network Topology

FortiADC 6.2 Lab Guide Fortinet Technologies Inc.

6

DO NOT REPRINT © FORTINET Lab 1: FortiADC Introduction In this lab, you will examine the FortiADC GUI. Then, you will complete and validate the necessary configurations for both the primary and secondary FortiADC devices in the lab environment.

Objectives l

Access the FortiADC CLI and GUI

l

Explore the FortiADC system configuration

l

Examine the initial network settings

l

Configure the FortiADC time zone

l

Enable logs and reports

l

Test network connectivity

Time to Complete Estimated: 20 minutes

7

FortiADC 6.2 Lab Guide Fortinet Technologies Inc.

DO NOT REPRINT © FORTINET Exercise 1: Configuring the Primary FortiADC In this exercise, you will connect to the FortiADC-Primary CLI and GUI to review the network configuration and perform some additional initial configurations.

All the lab exercises were tested with Mozilla Firefox. As a result, to get consistent results, we recommend using Firefox to access the internet, FortiADC management interfaces, and the Linux-Client VM in this lab environment.

Configure the Primary FortiADC Using the CLI You will connect to FortiADC-Primary to view the system status, configure the host name, and validate the network interfaces. Then, you will validate network connectivity.

To configure the host name and view the system status using the CLI 1. Log in to FortiADC-Primary using SSH with the username admin and password password. 2. Enter the following command: get system status

This command displays basic status information about FortiADC. The output includes the FortiADC serial number, firmware version, license status, registered services, and so on. If the --More-- prompt appears on the CLI, press the space bar to continue scrolling, press Enter to scroll one line at a time, or press Q to exit. 3. Enter the following commands to change the system host name: config system global set hostname Primary end

Note that FortiADC-VM # has automatically changed to Primary #.

To view the network interface settings using the CLI 1. Continuing on the FortiADC-Primary CLI, enter the following command to view the port1 interface configuration: show system interface port1

The IP address is 10.0.1.15/24, which is correct for the lab topology.

You can use the Tab key to automatically complete a command or existing object name, after you have typed enough characters to identify it.

2. Enter the following command to review the settings for all interfaces: show system interface

3. Enter the following command to see the full interface configurations: show full-configuration system interface

FortiADC 6.2 Lab Guide Fortinet Technologies Inc.

8

DO Access NOT REPRINT the Primary FortiADC GUI © FORTINET

Exercise 1: Configuring the Primary FortiADC

If the --More-- prompt appears on the CLI, press the space bar to continue scrolling, press Enter to scroll one line at a time, or press Q to exit. Stop and think! Compare both outputs. Why are they different? The show full-configuration command displays all the configuration settings for each interface. The show system interfaces command displays only those configuration settings that are using values that are different from the default values.

Access the Primary FortiADC GUI You will access the FortiADC-Primary GUI, verify the license status, configure the device NTP settings, and enable logging and reports.

To access the primary FortiADC GUI 1. Log in to the FortiADC-Primary GUI with the username admin and password password. 2. Click Dashboard > Main. (It should be the first screen that appears when you log in.) 3. In the License widget, click the three vertical dots in the upper-right, and then select See Detail. The FortiGuard Distribution Network page is displayed. 4. Review the details for each item covered by the license.

9

FortiADC 6.2 Lab Guide Fortinet Technologies Inc.

DO Exercise NOT1: Configuring REPRINT the Primary FortiADC © FORTINET

Test the Primary FortiADC Connectivity

To configure the time zone 1. Continuing on the FortiADC-Primary GUI, click System > Settings, and then click the Maintenance tab. 2. In the Time Zone drop-down list, select your time zone. 3. Enable NTP. 4. Keep the default values for the remaining settings, and then click Save. You can use Network Time Protocol (NTP) to synchronize computer clocks to a time reference (for example, pool.ntp.org).

To enable logs and reports 1. Continuing on the FortiADC-Primary GUI, click Log & Report > Log Setting. 2. Enable all logging categories for Status, Event, Traffic, Security, and Script. 3. Click Save.

Test the Primary FortiADC Connectivity You will test network connectivity and verify the FortiADC-Primary routing table entries.

To test network connectivity 1. Return to the FortiADC-Primary SSH session, and then enter the following commands to test network connectivity: execute execute execute execute

ping ping ping ping

10.0.1.10 10.200.1.10 10.200.1.20 10.200.1.210

The outputs should be successful: 5 packets transmitted, 5 packets received, 0% packet loss. 2. Close the SSH session browser tab.

To verify the network routes on the primary FortiADC 1. Return to the FortiADC-Primary GUI, and then click Network > Routing > Static. 2. Verify the following entries:

FortiADC 6.2 Lab Guide Fortinet Technologies Inc.

10

DO Test NOT REPRINT the Primary FortiADC Connectivity © FORTINET

Exercise 1: Configuring the Primary FortiADC

There are two default static routes. The first static route is the primary route. The second static route is a backup route with a larger distance value. The FortiADC VM uses the backup route when the primary route is down. In this lab topology, the FortiGate VM acts as the network gateway to the internet and Linux-External client. 3. Log out of the FortiADC-Primary GUI.

To verify the FortiGate routing table 1. Log in to the FortiGate using SSH with the username admin and password password. 2. Enter the following command: get router info routing-table all

There are various network routes for the FortiADC lab exercises. The output must include the following routes:

The FortiGate has a static route to the subnet 10.200.1.0/24 pointing to the primary FortiADC IP address 10.0.1.15. Additionally, all the application servers have their default gateway pointing to the primary FortiADC IP address 10.200.1.100. 3. Close the FortiGate SSH session browser tab.

11

FortiADC 6.2 Lab Guide Fortinet Technologies Inc.

DO NOT REPRINT © FORTINET Exercise 2: Configuring the Secondary FortiADC In this exercise, you will connect to the FortiADC-Secondary CLI and GUI to review the network configuration and perform some additional initial configurations.

Configure the Secondary FortiADC Using the CLI You will connect to FortiADC-Secondary to configure the host name and validate the network interfaces. Then, you will validate network connectivity.

To configure the host name on FortiADC using the CLI 1. Log in to FortiADC-Secondary using SSH with the username admin and password password. 2. Enter the following commands to change the system host name: config system global set hostname Secondary end

Note that FortiADC-VM # has automatically changed to Secondary #.

To view the network interface settings using the CLI 1. Enter the following command to check the port1 interface configuration: show system interface port1

The IP address is 10.0.1.16/24, which is correct according to the lab topology. 2. Enter the following command to check the port2 interface configuration: show system interface port2

The IP address is 10.200.1.200/24, which is correct according to the lab topology. 3. Enter the following command to check the port3 interface configuration: show system interface port3

The IP address is 10.0.2.16/24, which is correct according to the topology. 4. Enter the following command to review all the interface settings: show system interface

Access the Secondary FortiADC GUI You will access the secondary FortiADC GUI, verify the license status, configure the device NTP settings, and enable logs and reports.

FortiADC 6.2 Lab Guide Fortinet Technologies Inc.

12

DO Access NOT REPRINT the Secondary FortiADC GUI © FORTINET

Exercise 2: Configuring the Secondary FortiADC

To access the secondary FortiADC GUI 1. Log in to the FortiADC-Secondary GUI with the username admin and password password. 2. Click Dashboard > Main. (It should be the first screen that opens when you log in.) 3. In the License widget, click the three vertical dots in the upper-right, and then select See Detail. The FortiGuard Distribution Network page is displayed. 4. Review the details for each item covered by the license.

To configure the time zone 1. Continuing on the FortiADC-Secondary GUI, click System > Settings, and then click the Maintenance tab. 2. In the Time Zone drop-down list, select your time zone. 3. Enable NTP. 4. Keep the default values for the other settings, and then click Save.

To enable logs and reports 1. Continuing on the FortiADC-Secondary GUI, click Log & Report > Log Setting. 2. Enable all logging options for Status, Event, Traffic, Security, and Script. 3. Click Save.

13

FortiADC 6.2 Lab Guide Fortinet Technologies Inc.

DO Exercise NOT2: Configuring REPRINT the Secondary FortiADC © FORTINET

Test the Secondary FortiADC Connectivity

Test the Secondary FortiADC Connectivity You will test network connectivity and verify the FortiADC-Secondary routing table entries.

To test network connectivity 1. Return to the FortiADC-Secondary SSH session, and then enter the following commands to test network connectivity: execute execute execute execute

ping ping ping ping

10.0.1.10 10.200.1.10 10.200.1.20 10.200.1.210

The outputs should be successful: 5 packets transmitted, 5 packets received, 0% packet loss. 2. Close the FortiADC-Secondary SSH session browser tab.

To verify the network routes on the secondary FortiADC 1. Return to the FortiADC-Secondary GUI, and then click Network > Routing > Static. 2. In the routing table, verify the following entries:

In this lab topology, FortiGate acts as the network gateway to the internet. 3. Log out of the FortiADC-Secondary GUI.

FortiADC 6.2 Lab Guide Fortinet Technologies Inc.

14

DO NOT REPRINT © FORTINET Lab 2: Basic Server Load Balancing In this lab, you will configure a Layer 4 virtual server to balance traffic among three application servers. You will learn how to make the FortiADC service available to external users. Finally, you will configure and test a backup server.

You must perform the following exercises on the primary FortiADC only.

Objectives l

Create a Layer 4 virtual server to balance TCP traffic

l

Configure a FortiGate virtual IP and IPv4 policy for external access to the FortiADC

l

Configure a backup server

Time to Complete Estimated: 25 minutes

15

FortiADC 6.2 Lab Guide Fortinet Technologies Inc.

DO NOT REPRINT © FORTINET Exercise 1: Configuring the Layer 4 Virtual Server and

Public IP Address In this exercise, you will configure a server pool containing three real servers. Then, you will create a virtual server, which will be the face of the real server pool. You will then configure a virtual IP and an IPv4 policy on FortiGate to allow the external client to access the virtual server. Finally, you will observe how the virtual server balances the load across the server pool members. Refer to the lab topology for the traffic flow and IP addresses.

Configure Health Check Rules and a Real Server Pool You will define the health check rules and a real server pool. The real server pool is one of the mandatory objects that must be configured on FortiADC devices, and contains the application servers shown in the lab topology.

FortiADC 6.2 Lab Guide Fortinet Technologies Inc.

16

Check Rules and a Real Server DO Configure NOTHealth REPRINT Pool © FORTINET

Exercise 1: Configuring the Layer 4 Virtual Server and Public IP Address

To configure a TCP health check rule 1. Log in to the FortiADC-Primary GUI with the username admin and password password. 2. Click Shared Resources > Health Check. 3. Click Create New, and then configure the following settings:

Field

Value

Name

TCPCheck

Type

TCP

Port

80

Interval (sec)

5

Timeout (sec)

3

4. Click Save.

FortiADC uses server health checks to determine whether a real server is available for use in a load balancing configuration. The Interval and Timeout values affect the server status detection. Carefully choose a value that works best for your servers.

To configure a real server pool 1. Continuing on the FortiADC-Primary GUI, click Server Load Balance > Real Server Pool. 2. Click Create New, and then configure the following settings:

Field

Value

Name

Ap_Servers

Address Type

IPv4

Health Check

Enabled

3. In the Available Items box, double-click TCPCheck 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. Continuing on the Real Server Pool page, click the edit icon (

) to edit the Ap_Servers server pool.

2. In the Member pane, click Create New, and then configure the following settings:

17

FortiADC 6.2 Lab Guide Fortinet Technologies Inc.

the Layer 4 Virtual Server and Public IP DO Exercise NOT1: Configuring REPRINT Address © FORTINET

Field

Value

Status

Enable

Real Server

Create New

Configure Health Check Rules and a Real Server Pool

3. In the Real Server window, configure the following settings:

Field

Value

Name

AppSrv1

Status

Enable

Address

10.200.1.10

4. Click Save to return to the Member window. 5. Keep the default values for the remaining settings, and then click Save. The Real Server Pool contains a single member.

6. Click Create New to create the second member, and then configure the following settings:

Field

Value

Status

Enable

Real Server

Create New

7. In the Real Server window, configure the following settings:

FortiADC 6.2 Lab Guide Fortinet Technologies Inc.

18

DO Configure NOTaREPRINT Virtual Server © FORTINET

Exercise 1: Configuring the Layer 4 Virtual Server and Public IP Address

Field

Value

Name

AppSrv2

Status

Enable

Address

10.200.1.20

8. Click Save to return to the Member window. 9. Keep the default values for the remaining settings, and then click Save. 10. Click Create New to create the third member, and then configure the following settings:

Field

Value

Status

Enable

Real Server

Create New

11. In the Real Server window, configure the following settings:

Field

Value

Name

AppSrv3

Status

Enable

Address

10.200.1.210

12. Click Save to return to the Member window. 13. Keep the default values for the remaining settings, and then click Save. There will now be three members in the Ap_Servers real server pool. 14. Click Save.

Configure a Virtual Server FortiADC uses virtual servers for load balancing. Clients connect to the virtual server and the FortiADC load balances between servers in the server pool.

To create a virtual server 1. Continuing on the FortiADC-Primary GUI, click Server Load Balance > Virtual Server. 2. Click Create New, and then select Advanced Mode in the drop-down list. 3. In the Basic tab, configure the following settings:

19

Field

Value

Name

TCP_VS

FortiADC 6.2 Lab Guide Fortinet Technologies Inc.

DO Exercise NOT1: Configuring REPRINT the Layer 4 Virtual Server and Public IP Address © FORTINET Field

Value

Type

Layer 4

Status

Enable

Address Type

IPv4

Configure a Virtual Server

Do not click Save or you will receive an error and lose the settings!

4. In the General tab, configure the following settings:

Field

Value

Address

10.0.1.50

Port

80

Interface

port1

Profile

LB_PROF_TCP

Method

LB_METHOD_ROUND_ROBIN

Real Server Pool

Ap_Servers

5. In the Monitoring tab, enable FortiView, and then click Save.

To reach the virtual server from the Linux-Internal client 1. Review the Availability column of your new virtual server.

If the question mark icon is grayed-out, refresh the browser page. The availability status should change to a green check mark. This status indicates that all the application servers that the virtual server uses are up and reachable. 2. Click FortiView > Logical Topology, and then observe the virtual server, real server pool, and real server topology map shown on the Server Load Balance tab. 3. On the Linux-Internal GUI, open the Firefox browser, and then connect to the virtual server at http://10.0.1.50. You should be routed to one of the application servers. 4. Press Ctrl+Shift+R to refresh the browser page several times. Notice that refreshing the main page changes the back-end server.

FortiADC 6.2 Lab Guide Fortinet Technologies Inc.

20

DO Test NOT REPRINT the Virtual Server © FORTINET

Exercise 1: Configuring the Layer 4 Virtual Server and Public IP Address

Test the Virtual Server You will test the virtual server by generating a significant amount of traffic against the virtual server. The test script resides in the /root directory.

To test the virtual server 1. Continuing on the Linux-Internal client, open a terminal window, and then enter the following command to see the test script definition: cat httpattack

2. Enter the following command to start generating traffic to the virtual server: ./httpattack http://10.0.1.50

3. Return to the FortiADC-Primary GUI, and then click Dashboard > Main. 4. In the Virtual Server Summary widget, click the three vertical dots, and then select See Detail. 5. Click Ap_Servers in the Pool column to display the real server details.

Notice that the traffic is evenly distributed among the three real application servers.

To finish the attack 1. Return to the terminal window on the Linux-Internal client, and then wait for the script to finish or press Ctrl+C to cancel the attack. 2. Close the terminal window.

The httpattack script runs an application called slowhttptest which generates 420 connections to the virtual IP address 10.0.1.50 at 6 connections per second. The test duration is 120 seconds.

3. Close the Linux-Internal client VM browser tab.

21

FortiADC 6.2 Lab Guide Fortinet Technologies Inc.

DO Exercise NOT1: Configuring REPRINT the Layer 4 Virtual Server and Public IP Address © FORTINET

Configure Virtual Server Public Access

Configure Virtual Server Public Access You will configure a FortiGate virtual IP and an IPv4 policy to allow access to external clients. It is very common to find FortiADC deployed behind a firewall. This configuration requires the front-end firewall to perform the translation from the FortiADC public IP address to the internal virtual server IP address.

To test virtual server access from the Linux-External Client 1. On the Linux-External GUI, open the Firefox browser, and then connect to the virtual server at http://10.0.1.50. You cannot access any of the application servers. This is because there is no route from the external network to the 10.0.1.0 internal network.

To configure FortiGate virtual IPs 1. Log in to the FortiGate GUI with the username admin and password password. If a Password Change alert box appears, click Later to skip the password change. 2. Click Policy & Objects > Virtual IPs. 3. Click Create New, and then select Virtual IP in the drop-down list. 4. In the New Virtual IP page, configure the following settings:

Field

Value

Name

VS_10.0.1.50

Interface

port5

External IP Address/Range

192.168.201.50

Mapped IP Address/Range

10.0.1.50

5. Click OK to save the settings.

To configure a FortiGate IPv4 policy There are preconfigured policies that you will use in the subsequent lab exercises. Do not change or delete the preconfigured policies.

1. Continuing on the FortiGate GUI, click Policy & Objects > Firewall Policy. 2. Click Create New, and then configure the following settings:

Field

Value

Name

VS_10.0.1.50

Incoming Interface

port5

FortiADC 6.2 Lab Guide Fortinet Technologies Inc.

22

DO Test NOT REPRINT the Virtual Server Public IP Address © FORTINET

Exercise 1: Configuring the Layer 4 Virtual Server and Public IP Address

Field

Value

Outgoing Interface

port2

Source

100.64.110.0

Destination

VS_10.0.1.50

Schedule

always

Service

HTTP, HTTPS

Action

ACCEPT

NAT

Disable

Enable this policy

Enable

3. Click OK to save the settings. 4. In the port5 → port2 section, drag the VS_10.0.1.50 policy, and then place it before the Block-External policy.

5. Log out of the FortiGate GUI.

Test the Virtual Server Public IP Address In the previous attempt, the Linux-External client was not able to connect to the virtual server. You will test it again using the public IP address to compare the results.

To reach the virtual server from the Linux-External client 1. Return to the Linux-External client, open a new Firefox browser tab, and then connect to the virtual server at http://192.168.201.50. 2. Press Ctrl+Shift+R to refresh the browser page several times. Observe that the responses are from each server in the server pool. 3. Close the GUI browser tab for the Linux-External client.

23

FortiADC 6.2 Lab Guide Fortinet Technologies Inc.

DO NOT REPRINT © FORTINET Exercise 2: Examining Health Check Methods In this exercise, you will test and compare the TCP and HTTP methods.

Stop Web Services and Test the TCP-Based Health Check The real server pool associated with 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.

To stop web services 1. Open an SSH connection to the AppSrv3 VM. 2. Log in with the username admin and password password. 3. Enter the following command to stop the web server: service apache2 stop

4. Enter the password password. 5. Log in to the FortiADC-Primary GUI with the username admin and password password. 6. Click FortiView > Logical Topology. The topology map should show the AppSrv3 status is unhealthy.

To test the TCP-based health check 1. On the Linux-Internal client, open a browser, and then connect to the virtual server at http://10.0.1.50. 2. Press Ctrl+Shift+R to refresh the browser page several times. 3. On the Linux-External client VM, open a browser, and then connect to the virtual server at http://192.168.201.50. 4. Press Ctrl+Shift+R to refresh the browser page several times. 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. Stop and think! In this exercise, what would happen if you were using an ICMP-based health check instead of one based on TCP? Would FortiADC be able to detect the failure on AppSrv3? Although the web service is down, AppSrv3 can still reply to any ICMP probe packets. So, if the FortiADC device was performing an ICMP-based health check, it would not have detected the problem.

FortiADC 6.2 Lab Guide Fortinet Technologies Inc.

24

DO Test NOT REPRINT a Limitation of the TCP-Based Health Check © FORTINET

Exercise 2: Examining Health Check Methods

Test a Limitation of the TCP-Based Health Check You will simulate a different problem on AppSrv3. This time, the web service is up and running, but it cannot display the website home page correctly.

To test a limitation of the TCP-based health check 1. Return to the AppSrv3 SSH session, and then enter the following command: service apache2 start

2. Enter the password password. 3. Enter the following command to change the AppSrv3 home page: sudo cp /var/www/html/wrongindex.html /var/www/html/index.html

4. Enter the password password. 5. Return to the Linux-Internal VM, and then refresh the browser tab that is connected to the virtual server at http://10.0.1.50 several times, waiting 5–7 seconds between refreshes. When you attempt to connect to the AppSrv3, you see the following message:

6. Close the Linux-Internal client VM browser tab. 7. Return to the FortiADC-Primary GUI, and then click FortiView > Logical Topology. All three real servers should appear healthy. If they do not, refresh the view using the refresh button. Stop and think! Why does FortiADC not detect the problem on AppSvr3? The HTTP service on port 80 is up and accepting user connections. This is why the TCP-based health check does not detect the failure. You must enable a smarter health check at Layer 7 to identify the problem.

Create an HTTP-Based Health Check You will configure FortiADC to query the server by sending a GET request to verify the HTTP service is up. You can also do this by sending a HEAD request.

To create an HTTP-based health check 1. Continuing on the FortiADC-Primary GUI, click Shared Resources > Health Check. 2. Click Create New, and then configure the following settings to create a new health check:

25

Field

Value

Name

HTTPCheck

FortiADC 6.2 Lab Guide Fortinet Technologies Inc.

DO Exercise NOT2: Examining REPRINT Health Check Methods © FORTINET Field

Value

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)

10

Timeout (sec)

5

Apply the HTTP-Based Heath Check

3. Click Save.

Apply the HTTP-Based Heath Check Now that you created the new health check, you must change the real server pool to use HTTPCheck instead of TCPCheck.

To apply the HTTP-based health check to the real server pool 1. Continuing on the FortiADC-Primary GUI, click Server Load Balance > Real Server Pool. 2. Click the edit icon (

) to edit Ap_Servers.

3. In the Selected Items list, double-click TCPCheck to remove it. 4. In the Available Items list, double-click HTTPCheck to add it. 5. Click Save. 6. Wait for the icon in the Availability column to change to a white check mark in a green circle.

To test the HTTP-based health check 1. Return to the Linux-External client, and then select the browser tab that is connecting to the virtual server at http://192.168.201.50. 2. Press Ctrl+Shift+R to refresh the browser page several times. Stop and think! Why are you now connecting only to AppSrv1 or AppSrv2? FortiADC detects that AppSrv3 is not returning a home page containing the string FortiADC. 3. Return to the AppSrv3 SSH session, and then enter following command to restore the home page:

FortiADC 6.2 Lab Guide Fortinet Technologies Inc.

26

DO Apply NOT REPRINT the HTTP-Based Heath Check © FORTINET

Exercise 2: Examining Health Check Methods

sudo cp /var/www/html/rightindex.html /var/www/html/index.html

4. Enter the password password. 5. Close the AppSrv3 SSH session browser tab. 6. Return to the Linux-External client VM, and then on the browser tab that is connecting to the virtual server at http://192.168.201.50, press Ctrl+Shift+R to refresh the browser page several times. You will see that all of the application servers are up. 7. Close the browser tab for the Linux-External client VM.

27

FortiADC 6.2 Lab Guide Fortinet Technologies Inc.

DO NOT REPRINT © FORTINET Exercise 3: Designating a Backup Server You can designate a server as a backup server, which will be used only if all the other servers in the real server pool fail to respond.

Configure a Backup Server You will configure and test a backup server in the real server pool.

To configure a backup server 1. Log in to the FortiADC-Primary GUI with the username admin and password password. 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. Enable Backup, and then click Save. 6. Click Save to change the real server pool.

To test the backup server when all the servers are running 1. On the Linux-External client, open the Firefox browser, and then connect to the virtual server at http://192.168.201.50. 2. Press Ctrl+Shift+R to refresh the browser page several times. Connections now go to only the AppSrv1 and AppSrv2 VMs. The AppSrv3 VM is a backup server, and is used only when all the other servers fail the health check.

To test the backup server when one server is running 1. Open an SSH connection to the AppSrv1 VM. 2. Enter the following command: sudo service apache2 stop

3. Enter the password password. 4. Return to the Linux-External client, select the browser tab that is connecting to the virtual server at http://192.168.201.50, and then press F5 several times, waiting 5–7 seconds between each refresh. Stop and think! Why doesn’t FortiADC route to the backup server (AppSrv3) if only one server in the pool is down? Using the backup setting indicates to the FortiADC that the server should be used only when no other server is available in the real server pool. As long as there is at least one other server available, no new connections are routed to the backup server.

FortiADC 6.2 Lab Guide Fortinet Technologies Inc.

28

DO Restore NOTtheREPRINT Application Servers and Disable the Backup Server © FORTINET

Exercise 3: Designating a Backup Server

To test the backup server when all servers are down 1. Open an SSH session to the AppSrv2 VM. 2. Enter the following command: sudo service apache2 stop

3. Enter the password password. 4. Return to the Linux-External client, select the browser tab that is connecting to the virtual server at http://192.168.201.50, and then press F5 several times to refresh the browser. Traffic is now routed to AppSrv3.

Restore the Application Servers and Disable the Backup Server You will disable the backup server configured in the real server pool.

To restore the application servers 1. Return to the application server (both AppSrv1 and AppSrv2) SSH sessions, and then enter the following command to start the httpd service on each server: sudo service apache2 start

2. Close the application server SSH session browser tabs.

To disable the backup server 1. Return to the FortiADC-Primary GUI, and then click Server Load Balance > Real Server Pool. 2. Click the edit icon (

) to edit Ap_Servers.

3. Double-click AppSrv3 to edit it. 4. Disable Backup, and then click Save. 5. Click Save. 6. Log out of the FortiADC-Primary GUI.

To test the servers 1. Return to the Linux-External client, select the browser tab that is connecting to the virtual server at http://192.168.201.50, and then press press Ctrl+Shift+R to refresh the browser page several times. Traffic is routed to all the application servers. 2. Close the Linux-External client browser tab.

29

FortiADC 6.2 Lab Guide Fortinet Technologies Inc.

DO NOT REPRINT © FORTINET Lab 3: Advanced Server Load Balancing In this lab, you will enable and test IP-based persistence, and use full NAT for packet forwarding. To complete the exercises for this lab, you must work on the primary FortiADC device only. You will create a Layer 7 virtual server for HTTP traffic balancing and inspection. You will learn to configure and test cookie persistence and content routes. Finally, you will create an HTTPS virtual server for SSL offloading.

You must perform the following exercises on the primary FortiADC only.

Objectives l

Enable and test IP-based persistence

l

Use full NAT as the packet forwarding mode

l

Configure content routes

l

Enable and test cookie persistence

l

Configure SSL offloading

l

Create a Layer 7 virtual server

Time to Complete Estimated: 45 minutes

FortiADC 6.2 Lab Guide Fortinet Technologies Inc.

30

DO NOT REPRINT © FORTINET Exercise 1: Configuring IP-Based Persistence In this exercise, you will configure IP-based persistence to route all the connections coming from the same source IP addresses to the same real servers. This is often done to support server transactions that depend on an established client-server session.

Configure IP-Based Persistence Persistence methods are rules that identify traffic that should not be load balanced, but should be forwarded to the back-end server that has processed requests from that source before.

To configure IP-based persistence 1. Log in to the FortiADC-Primary GUI with the username admin and password password. 2. Click Server Load Balance > Application Resources, and then select the Persistence tab. 3. Click Create New, and then configure the following settings to create a new persistence method:

Field

Value

Name

IPPersistence

Type

Source Address

Timeout (sec)

600

4. Click Save. 5. Click Server Load Balance > Virtual Server. 6. Click the edit icon (

) to edit the TCP_VS virtual server.

7. On the General tab, change the Persistence setting to IPPersistence, and then click Save.

To test IP-based persistence 1. On the Linux-External VM, open Firefox, and then connect to the virtual server at http://192.168.201.50. 2. Click the browser refresh button to refresh the web page every 5–7 seconds. Traffic is routed to the same application server. Stop and think! You increased the persistence timeout to 600 seconds. What will happen if you try to connect to the virtual server IP address after 10 minutes of inactivity? After 10 minutes of inactivity, you may be routed to a different application server. The persistence is maintained as long as there is traffic coming from your IP address within the timeout period.

31

FortiADC 6.2 Lab Guide Fortinet Technologies Inc.

DO NOT REPRINT © FORTINET Exercise 2: Configuring Full NAT In this exercise, you will configure full NAT to translate both the source and destination IP addresses of the user traffic. This feature is useful when you have a security requirement that prohibits the real server from tracking or logging the real IP address of the client. You can also use full NAT to prevent asymmetric traffic when the real server gateway is not FortiADC.

Configure Full NAT In this exercise, you will configure full NAT using the FortiADC GUI, and then verify the source and destination IP address translation using the CLI.

To disable health checks You will disable all health checks to reduce the volume of traffic to the application servers. 1. Log in to the FortiADC-Primary GUI with the username admin and password password. 2. Click Server Load Balance > Real Server Pool. 3. Click the edit icon (

) to edit the Ap_Servers real server pool.

4. Disable the Health Check option. 5. Click Save. Now, only user-generated traffic arrives at the servers, and not health check traffic.

To capture the traffic using DNAT 1. Open an SSH connection to the FortiADC-Primary VM. 2. Enter the following CLI command to enable the sniffer and capture of HTTP traffic: diagnose sniffer packet any “port 80” 4

3. On the Linux-External VM, open a browser, and then connect to the virtual server at http://192.168.201.50. 4. Return to the FortiADC-Primary SSH session, and then observe the sniffer output.

FortiADC 6.2 Lab Guide Fortinet Technologies Inc.

32

DO Create NOT REPRINT a Source IP Pool © FORTINET

Exercise 2: Configuring Full NAT

Notice that the traffic is between the IP address 100.64.110.100 (which is the IP address of the LinuxExternal VM) and a real server IP address (10.200.1.20). The FortiADC-Primary VM is translating the destination IP address of the client traffic from the virtual server IP address (10.0.1.50) to one of the real server IP addresses. However, the FortiADC-Primary VM is not changing the source IP address because DNAT is the default setting for the Packet-Forwarding Method in a Layer 4 virtual server.

Create a Source IP Pool The source pool contains an IP address range that is used to translate the source IP of the user traffic.

To create a source IP pool 1. Return to the FortiADC-Primary GUI, click Server Load Balance > Virtual Server, and then select the NAT Source Pool tab. 2. Click Create New, and then configure the following settings to create a new source pool:

Field

Value

Name

SourcePool

Interface

port2

Address Type

IPv4

Address Range

10.200.1.110

To

10.200.1.120

3. Click Save.

To apply the source IP pool to the virtual server 1. Continuing on the FortiADC-Primary GUI, click Server Load Balance > Virtual Server, and then select the Virtual Server tab. 2. Click the edit icon (

) to edit the TCP_VS virtual server.

3. Change the Packet Forwarding Method setting to Full NAT. 4. In the Available Items list, double-click SourcePool to move it to the Selected Items field. 5. Click Save. 6. Log out of the FortiADC-Primary GUI.

To capture the traffic using full NAT 1. Return to the Linux-External VM, select the browser tab that is connected to the virtual server at http://192.168.201.50, and then press F5 to refresh the browser. 2. Return to the FortiADC-Primary SSH session, and then observe the sniffer output.

33

FortiADC 6.2 Lab Guide Fortinet Technologies Inc.

DO Exercise NOT2: Configuring REPRINT Full NAT © FORTINET

Create a Source IP Pool

The source IP address of the user traffic was translated from the Linux-External VM (100.64.110.100) to one of the IP addresses in the source pool (10.200.1.111), and the traffic was load balanced to a different real server (10.200.1.210). Stop and think! Can you think of a reason why using full NAT can prevent asymmetric traffic if your real server gateway is not the load balancer? Using full NAT, the client source IP address is translated to an IP address in the source IP pool. You can configure the static route in the gateway to use the same egress interface to route the real server response packets to the client. Without full NAT, the return path may be different for clients from different networks. 3. Press Ctrl+C to stop the sniffer. 4. Close the FortiADC-Primary SSH browser tab. 5. Close the Linux-External VM browser tab.

FortiADC 6.2 Lab Guide Fortinet Technologies Inc.

34

DO NOT REPRINT © FORTINET Exercise 3: Configuring a Layer 7 Virtual Server In this exercise, you will delete the Layer 4 virtual server and configure a Layer 7 virtual server.

Configure a Layer 7 Virtual Server In this exercise, you will connect to the FortiADC-Primary GUI to display the system status, and verify and set the network configuration.

To create a server profile 1. Log in to the FortiADC-Primary GUI with the username admin and password password. 2. Click Server Load Balance > Application Resources > Application Profile. 3. Click Create New, and then configure the following settings to create a new profile:

Field

Value

Name

HTTPProfile

Type

HTTP

4. Keep the default values for the remaining settings, and then click Save.

To delete the Layer 4 virtual server 1. Continuing on the FortiADC-Primary GUI, click Server Load Balance > Virtual Server > Virtual Server. 2. Select the TCP_VS virtual server. 3. Click Delete. 4. Click OK to confirm.

To configure a new Layer 7 virtual server 1. Continuing on the FortiADC-Primary GUI, click Server Load Balance > Virtual Server > Virtual Server. 2. Click Create New, select Advanced Mode, and then configure the following settings to create a new virtual server:

Field

Value

Name

HTTP_VS

Type

Layer 7

Status

Enable

Address Type

IPv4

3. On the General tab, configure the following settings:

35

FortiADC 6.2 Lab Guide Fortinet Technologies Inc.

DO Exercise NOT3: Configuring REPRINT a Layer 7 Virtual Server © FORTINET

Configure a Layer 7 Virtual Server

Field

Value

Address

10.0.1.50

Port

80

Interface

port1

Profile

HTTPProfile

Method

LB_METHOD_ROUND_ROBIN

Real Server Pool

Ap_Servers

4. On the Monitoring tab, enable FortiView. 5. Click Save. 6. Log out of the FortiADC-Primary GUI.

To test the new virtual server 1. On the Linux-External VM, open a browser, and then connect to the virtual server at http://192.168.201.50. 2. Press Ctrl+Shift+R to refresh the browser page several times. The device evenly distributes the connections among the three application servers. 3. Close the browser tab on the Linux-External VM.

FortiADC 6.2 Lab Guide Fortinet Technologies Inc.

36

DO NOT REPRINT © FORTINET Exercise 4: Configuring Layer 7 Content Routing on a

Virtual Server In this exercise, you will configure the primary FortiADC to route all traffic destined for the resources page to AppSrv3, while keeping the traffic to the home page balanced among the three application servers.

Configure Layer 7 Content Routing on a Virtual Server You will validate the need to direct resource page requests to ApSrv3, and then configure content routing.

To configure Layer 7 content routing on a virtual server 1. On the Linux-External VM, open a browser, and then connect to the following URL: http://192.168.201.50/resources/

2. Press Ctrl+Shift+R to refresh the browser page several times. Approximately two out of three connection attempts will fail. They fail each time the device routes traffic to AppSrv1 and AppSrv2 because the resources folder is located on AppSrv3 only. Stop and think! Can you think of a real-life scenario where a similar problem would happen—where a client might be forced to have different or additional content on only one server in a virtual server pool? One example is for video streaming, where one server in a virtual server pool may handle a specific type of traffic better and faster than the other servers in the virtual server pool. Another example is when one server has more available hard disk space than the other servers in the virtual server pool, so you want to use that server for file storage. You would configure FortiADC to route all HTTP file requests to that server, and then balance the rest of the traffic among all servers in the virtual server pool. To fix this problem, you will configure content routing. First, you must create a new real server pool using AppSrv3 as the only member.

To create a new real server pool 1. Log in to the FortiADC-Primary GUI with the username admin and password password. 2. Click Server Load Balance > Real Server Pool > Real Server Pool. 3. Click Create New, and then configure the following settings to create a new real server pool:

37

Field

Value

Name

Ap_3

FortiADC 6.2 Lab Guide Fortinet Technologies Inc.

Layer 7 Content Routing on a Virtual DO Exercise NOT4: Configuring REPRINT Server © FORTINET

Configure Layer 7 Content Routing on a Virtual Server

Field

Value

Address Type

IPv4

Health Check

Enabled

4. In the Health Check List Available Items list, double-click HTTPCheck to add it to the Selected Items list. 5. Keep the default values for the remaining settings, and then click Save.

To add members to the real server pool 1. Continuing on the Real Server Pool page, click the edit icon (

) to edit the Ap_3 real server pool.

2. Scroll down to the Member pane, click Create New, and then configure the following settings to create a new member:

Field

Value

Status

Enable

Real Server

AppSrv3

Port

80

Weight

1

3. Keep the default values for the remaining settings, click Save, and then click Save again.

To create content routes 1. Continuing on the FortiADC-Primary GUI, click Server Load Balance > Virtual Server, and then select the Content Routing tab. 2. Click Create New, and then configure the following settings to create a new route:

Field

Value

Name

ResourcesRoute

Type

Layer 7

Real Server Pool

Ap_3

Persistence

Inherit

Method

Inherit

3. Click Save. 4. Click Create New, and then configure the following settings to create a second content route:

FortiADC 6.2 Lab Guide Fortinet Technologies Inc.

38

7 Content Routing on a Virtual DO Configure NOTLayer REPRINT Server © FORTINET

Exercise 4: Configuring Layer 7 Content Routing on a Virtual Server

Field

Value

Name

All

Type

Layer 7

Real Server Pool

Ap_Servers

Persistence

Inherit

Method

Inherit

5. Click Save.

To add match conditions to the content routes 1. Continuing on the Content Routing page, click the edit icon (

) to edit the ResourcesRoute.

2. Scroll down to the Match Condition pane, click Create New, and then configure the following settings to create a new rule:

Field

Value

Object

HTTP Request URL

Type

String

Content

resources

3. Click Save, and then click Save again. 4. Click the edit icon (

) to edit the All content route.

5. Scroll down to the Match Condition pane, click Create New, and then configure the following settings to create a new rule:

Field

Value

Object

HTTP Host Header

Type

String

Content

10.0.1.50

6. Click Save, and then click Save again.

To select and enable content routes 1. Continuing on the FortiADC-Primary GUI, click Server Load Balance > Virtual Server, and then select the Virtual Server tab. 2. Click the edit icon (

) to edit HTTP_VS.

3. In the Specifics pane, enable Content Routing. 4. In the Content Routing List Available Items list, double-click ResourcesRoute to add it to the Selected Items

39

FortiADC 6.2 Lab Guide Fortinet Technologies Inc.

Layer 7 Content Routing on a Virtual DO Exercise NOT4: Configuring REPRINT Server © FORTINET

Configure Layer 7 Content Routing on a Virtual Server

list. 5. Double-click All to add it to the Selected Items list. The route All must be the second entry in the Selected Items list.

If necessary, you can drag and drop the content routes to reorder them. 6. Click the General tab. 7. Scroll down to the Error Page pane, and then type the following message in the Error Message field to customize it: The server is not currently available. Please try again later.

8. Click Save.

To test the content routes 1. Return to the Linux-External VM, and then select the browser tab that is connected to the resources folder at http://192.168.201.50/resources/. 2. Press Ctrl+Shift+R to refresh the browser page several times. Now, it works. Traffic is redirected by the content route to AppSrv3. 3. Open a new browser tab, and then connect to the virtual server at http://192.168.201.50. 4. Press Ctrl+Shift+R to refresh the browser page several times. Now, it does not work. The browser displays a site error message. Stop and think! Remember, you configured a VIP and an IPv4 policy for public-IP-to-virtual-server-IP address mapping on the FortiGate. Can you explain why content routing using the HTTP host header matching 10.0.1.50, the virtual server IP address, does not work? The match condition failed because the external client browser sends a request to 192.168.201.50, the virtual server public IP address, and uses that IP address as the HTTP host header value. It remains unchanged when the packet travels across FortiGate and FortiADC.

To examine the header value and correct the error 1. Continuing on the Linux-External VM, select the browser tab that is connected to the virtual server at http://192.168.201.50. 2. In the Firefox browser, in the upper-right corner, click the Open Menu icon ( Developer Tools > Network.

), and then click More tools > Web

3. Press F5 to reload the browser. The site error message appears.

FortiADC 6.2 Lab Guide Fortinet Technologies Inc.

40

7 Content Routing on a Virtual DO Configure NOTLayer REPRINT Server © FORTINET

Exercise 4: Configuring Layer 7 Content Routing on a Virtual Server

4. On the Firefox Network pane, click the first GET request to view the 192.168.201.50 / request header.

5. Examine the Host value in the request headers. The value set by the browser is 192.168.201.50.

6. Return to the FortiADC-Primary GUI, click Server Load Balance > Virtual Server, and then select the Content Routing tab. 7. Click the edit icon (

) to edit All.

8. Click the edit icon (

) to edit the HTTP Host Header match condition.

9. Change Content from 10.0.1.50 to 192.168.201.50. 10. Click Save, and then click Save again. 11. Log out of the FortiADC-Primary GUI. 12. Return to the Linux-External VM, and then select the browser tab that is connecting to the virtual server at http://192.168.201.50. 13. Press Ctrl+Shift+R to refresh the browser page several times.

The URL is now working again. The FortiADC-Primary VM is balancing the connections among the three application servers.

To test the error page 1. Open an SSH connection to the AppSrv3 VM. 2. Enter the following command: sudo service apache2 stop

41

FortiADC 6.2 Lab Guide Fortinet Technologies Inc.

Layer 7 Content Routing on a Virtual DO Exercise NOT4: Configuring REPRINT Server © FORTINET

Configure Layer 7 Content Routing on a Virtual Server

3. Enter the password password. 4. Return to the Linux-External VM, and then select the browser tab that is running the connection to the resources folder at http://192.168.201.50/resources. 5. Refresh the browser. The customized error message appears.

6. Return to the AppSrv3 SSH session, and then enter the following command to start the web server: sudo service apache2 start

7. Enter the password password. 8. Close the AppSrv3 VM SSH browser tab. 9. Return to the Linux-External VM, and then refresh the browser tab with the error page. The resource page displays correctly. 10. Close the browser tab for the Linux-External VM.

FortiADC 6.2 Lab Guide Fortinet Technologies Inc.

42

DO NOT REPRINT © FORTINET Exercise 5: Configuring Cookie Insertion Persistence Cookie insertion persistence takes advantage of browser cookie caching behavior. FortiADC inserts a cookie in the content that is forwarded to the user, so each time the client issues a GET request, FortiADC uses that cookie to identify the server that the HTTP GET request should go to. Cookies are commonly used by websites today to track user access history. E-commerce websites use cookies to keep customer shopping cart persistence and purchase behavior analysis.

Configure Cookie Insertion on the Virtual Server You will use cookie insertion persistence to route traffic coming from the same user to the same server.

To configure cookie insertion persistence 1. Log in to the FortiADC-Primary GUI with the username admin and password password. 2. Click Server Load Balance > Application Resources, and then select the Persistence tab. 3. Click Create New, and then configure the following settings to create a new persistence method:

Field

Value

Name

CookieInsert

Type

Insert Cookie

Keyword

FortinetLab

Timeout (sec)

300

4. Click Save. 5. Click Server Load Balance > Virtual Server > Virtual Server. 6. Click the edit icon (

) to edit the new virtual server HTTP_VS.

7. Click the General tab, and then scroll down to the Resources section. 8. In the drop-down list for the Persistence setting, select CookieInsert. 9. Click Save. 10. Log out of the FortiADC-Primary GUI.

To test the cookie insertion persistence 1. On the Linux-External VM, open a browser, and then connect to the virtual server at http://192.168.201.50. 2. Press Ctrl+Shift+R to refresh the browser page several times. Traffic is now routed to the same application server. The FortiADC-Primary VM inserts a cookie named FortinetLab that identifies requests made by FortiADC. Your browser appends the cookie to all requests made to the virtual server IP address.

43

FortiADC 6.2 Lab Guide Fortinet Technologies Inc.

DO Exercise NOT5: Configuring REPRINT Cookie Insertion Persistence © FORTINET

Configure Cookie Insertion on the Virtual Server

To observe the cookie and its value 1. Continuing on the Linux-External VM, in the upper-right corner of the Firefox browser, click the Open Menu icon ( ), and then click More tools > Web Developer Tools > Network. 2. Click the browser refresh button to refresh the web page. 3. On the Firefox network pane, click the first GET request to view the 192.168.201.50 / header information. 4. Inspect the cookie values in the Request Headers and Response Headers sections. The cookie value FortinetLab is set in both headers.

5. Close the Network pane. 6. Close the Linux-External VM browser tab.

FortiADC 6.2 Lab Guide Fortinet Technologies Inc.

44

DO NOT REPRINT © FORTINET Exercise 6: Configuring SSL Offload None of the three application servers are currently configured to support HTTPS. The system can inspect and make decisions based on SSL content, because the SSL encryption is terminated on FortiADC. In this exercise, you will offload the encryption and decryption of SSL traffic to the primary FortiADC. This feature greatly improves server performance by eliminating the packet encryption and decryption burden from the server, and offloading cryptographic functions from firewalls and IPS for high-performance encrypted threat detection and mitigation.

Import a Signed Digital Certificate To inspect and make decisions based on the SSL content, you will import the server’s signed digital certificate and private key, which is presented to HTTPS customers, to the FortiADC. The certificate files are located in the Resources folder on the Linux-Internal VM desktop.

To import a signed digital certificate 1. On the Linux-Internal VM, open a browser, and then log in to the FortiADC-Primary GUI at https://10.0.1.15 with the username admin and password password. 2. Click System > Manage Certificates, and then select the Local Certificate tab. 3. Click Import, and then configure the following settings:

Field

Value

Type

Certificate

Certificate Name

FortiADC-Labs

Certificate File

1. Click Choose File, and then click /root/Desktop/Resources/Lab 3/. 2. Select FortiADC_Labs.crt. 3. Click Open.

Key File

1. Click Choose File, and then click /root/Desktop/Resources/Lab 3/. 2. Select FortiADC_Labs.pem. 3. Click Open.

Password

fortinet

4. Click Save.

To define a local certificate group 1. Return to the FortiADC-Primary GUI, click System > Manage Certificates, and then select the Local Certificate Group tab.

45

FortiADC 6.2 Lab Guide Fortinet Technologies Inc.

DO Exercise NOT6: Configuring REPRINT SSL Offload © FORTINET

Create a New HTTPS Profile

2. Click Create New, and then configure the following setting:

Field

Value

Group Name

FortiADC-Trg

3. Click Save. 4. Click the edit icon (

) to edit the FortiADC-Trg group.

5. In the Group Member pane, click Create New, and then configure the following settings:

Field

Value

Default

Enabled

Local Certificate

FortiADC-Labs

6. Click Save, and then click Save again.

Create a New HTTPS Profile You will specify the digital certificate that is presented to clients that want to connect to the server.

To create a new HTTPS profile 1. Continuing on the FortiADC-Primary GUI, click Server Load Balance > Application Resources > Application Profile. 2. Click Create New, and then configure the following settings to create a new profile:

Field

Value

Name

HTTPSProfile

Type

HTTPS

3. Keep the default values for the other settings, and then click Save.

To create a new client SSL profile 1. Continuing on the FortiADC-Primary GUI, click Server Load Balance > Application Resources, and then select the Client SSL tab. 2. Click Create New, and then configure the following settings to create a new profile:

Field

Value

Name

FortiADC-Labs

Local Certificate Group

FortiADC-Trg

3. Click Save.

FortiADC 6.2 Lab Guide Fortinet Technologies Inc.

46

DO Configure NOTtheREPRINT Virtual Server to Use an SSL Certificate © FORTINET

Exercise 6: Configuring SSL Offload

Configure the Virtual Server to Use an SSL Certificate You will create and configure a virtual server for the HTTPS service using the SSL certificate.

To create a virtual server 1. Continuing on the FortiADC-Primary GUI, click Server Load Balance > Virtual Server > Virtual Server. 2. Click Create New, and then select Advanced Mode. 3. On the Basic tab, configure the following settings:

Field

Value

Name

HTTPS_VS

Type

Layer 7

Status

Enable

Address Type

IPv4

4. On the General tab, configure the following settings:

Field

Value

Address

10.0.1.50

Port

443

Interface

port1

Profile

HTTPSProfile

Client SSL Profile

FortiADC-Labs

Method

LB_METHOD_ROUND_ROBIN

Real Server Pool

Ap_Servers

5. On the Monitoring tab, enable Traffic Log and FortiView. 6. Click Save. 7. Click FortiView > Logical Topology, and then observe the virtual server, real server pool, and real server topology map.

To test the HTTPS connection 1. On the Linux-External VM, open a new browser tab, and then connect to the virtual server at https://192.168.201.50. 2. Accept the security certificate warning if it appears, click Advanced, and then select Accept the Risk and Continue.

47

FortiADC 6.2 Lab Guide Fortinet Technologies Inc.

DO Exercise NOT6: Configuring REPRINT SSL Offload © FORTINET

Configure the Virtual Server to Use an SSL Certificate

3. Press Ctrl+Shift+R to refresh the browser page several times. 4. Observe that the responses are from each server in the server pool. The communication between your browser and the FortiADC is now encrypted—the communication between FortiADC and the application servers is not encrypted.

To capture HTTPS traffic 1. Open an SSH connection to the FortiADC-Primary VM. 2. Enter the following CLI command to sniff and capture all TCP SYN packets on any interface: diagnose sniffer packet any “tcp and host 100.64.110.100 and port 443 or port 80” 4

3. On the Linux-External VM, select the browser tab that is running the HTTPS connection to the virtual server at https://192.168.201.50. 4. Press F5 to refresh the browser. 5. Return to the FortiADC-Primary SSH session, and then press Ctrl+C to stop the capture. 6. Observe the sniffer output.

You will observe the following: l

The first part of the sniffer trace is the HTTPS traffic passing from the client to the FortiADC-Primary port1.

l

The port2 traffic shows the decrypted HTTP traffic passing between the FortiADC-Primary VM and the application server.

FortiADC uses the port2 IP address 10.200.1.100 as the source address instead of the client IP address 100.64.110.100. This is a NAT effect. By default, the Layer 7 virtual server always uses full NAT mode.

7. Close the FortiADC-Primary SSH session browser tab. 8. Return to the FortiADC-Primary GUI, and then click Server Load Balance > Virtual Server > Virtual Server. 9. Delete the HTTPS_VS virtual server.

FortiADC 6.2 Lab Guide Fortinet Technologies Inc.

48

DO Configure NOTtheREPRINT Virtual Server to Use an SSL Certificate © FORTINET

Exercise 6: Configuring SSL Offload

Stop and think! The signed certificate presented by FortiADC has been correctly issued to the 10.0.1.50 site. However, the browser still displays a digital certificate warning. Why? Although the certificate has been issued to the 10.0.1.50 site, it has been signed by a certificate authority (CA) that the browser doesn’t trust. To fix it, you must import its CA root certificate into the browser, so it will become trusted. 10. Log out of the FortiADC-Primary GUI.

49

FortiADC 6.2 Lab Guide Fortinet Technologies Inc.

DO NOT REPRINT © FORTINET Lab 4: Link Load Balancing Link Load Balancing (LLB) functionality allows FortiADC devices to support multiple upstream and downstream infrastructure links to provide redundancy, such as a dual-homed ISP. If a primary link fails, LLB enables the seamless redirection of traffic through a backup link. In this lab, you will configure outbound LLB. Outbound LLB is used to load balance the outbound traffic, and provide redundancy across multiple routes for traffic leaving the FortiADC. The gateways configured into an outbound LLB group must be able to route traffic to the same set of destinations. Outbound LLB is a useful traffic engineering method for an organization to load balance the outbound traffic to multiple ISP links.

Objectives l

Create an outbound LLB solution for a dual-homed ISP network

l

Configure a gateway health check and link group for the local gateway and external router

l

Configure a link policy to route outbound traffic from the internal sources to the link group

l

Configure NAT rules for the internal IP addresses

l

Test outbound LLB

Time to Complete Estimated: 30 minutes

FortiADC 6.2 Lab Guide Fortinet Technologies Inc.

50

DO NOT REPRINT © FORTINET Exercise 1: Configuring Outbound Link Load Balancing In this exercise, you will configure an outbound LLB solution that uses FortiGate port2 and port3 to simulate a dual-homed ISP network. You will generate ping traffic from two application servers to the Linux-External VM, and then observe the outbound LLB behavior. You will also manually disable one of the FortiGate links to verify the outbound LLB link failover.

Configure the Gateway Health Check and Link Group To ensure outbound LLB is working correctly, the gateway status should be checked. The gateway health check should probe the local gateway links and remote gateway links. The remote gateway is typically the next hop router for the local gateway, or at a critical path point you want to monitor. In this part of the lab, you will define an ICMP health check for the remote gateway, configure FortiGate ports as LLB gateways, and add LLB gateways to a link group. You will verify the LLB status using the FortiView logical topology view.

51

FortiADC 6.2 Lab Guide Fortinet Technologies Inc.

DO Exercise NOT1: Configuring REPRINT Outbound Link Load Balancing © FORTINET

Configure the Gateway Health Check and Link Group

To configure a health check rule 1. Log in to the FortiADC-Primary GUI with the username admin and password password. 2. Click Shared Resources > Health Check. 3. Click Create New, and then configure the following settings:

Field

Value

Name

HC_100.64.110.100

Type

ICMP

Destination Address Type

IPv4

Destination Address

100.64.110.100

4. Leave all other settings at the default values. 5. Click Save. The ICMP probe is sent from FortiADC to the Linux-External host. For this lab exercise, the virtual IP and IPv4 policy for the external host have already been configured on the FortiGate.

To create a gateway for the FortiGate links 1. Continuing on the FortiADC-Primary GUI, click Link Load Balance > Link Group, and then select the Gateway tab. 2. Click Create New, and then configure the following settings:

Field

Value

Name

LocalFGT_10.0.1.10

Address

10.0.1.10

Health Check

Enabled

3. In the Health Check List Available Items box, double-click HC_100.64.110.100 to add it to the Selected Items box. 4. Click Save. 5. Click Create New, and then configure the following settings:

Field

Value

Name

LocalFGT_10.0.2.10

Address

10.0.2.10

Health Check

Enabled

FortiADC 6.2 Lab Guide Fortinet Technologies Inc.

52

DO Configure NOTtheREPRINT Gateway Health Check and Link Group © FORTINET

Exercise 1: Configuring Outbound Link Load Balancing

6. In the Health Check List Available Items box, double-click HC_100.64.110.100 to add it to the Selected Items box. 7. Click Save.

To create a link group 1. Continuing on the FortiADC-Primary GUI, click Link Load Balance > Link Group, and then select the Link Group tab. 2. Click Create New, and then configure the following settings:

Field

Value

Name

LocalFGT_Port2_Port3

Route Method

Weighted Round Robin

3. Click Save. 4. Click the edit icon (

) to edit the link group LocalFGT_Port2_Port3.

5. In the Link Member pane, click Create New, and then configure the following settings:

Field

Value

Name

LocalFGT_Port2

Gateway

LocalFGT_10.0.1.10

Status

Enabled

6. Click Save. 7. In the Link Member pane, click Create New, and then configure the following settings to add a second member:

Field

Value

Name

LocalFGT_Port3

Gateway

LocalFGT_10.0.2.10

Status

Enabled

8. Click Save, and then click Save again.

To verify the link load balance logical topology 1. Continuing on the FortiADC-Primary GUI, click FortiView > Logical Topology. 2. Click the Link Load Balance tab. 3. Verify the link group and that the link member status is up.

53

FortiADC 6.2 Lab Guide Fortinet Technologies Inc.

DO Exercise NOT1: Configuring REPRINT Outbound Link Load Balancing © FORTINET

Configure a Link Policy

Configure a Link Policy A link policy matches traffic to rules that select a link group. In this exercise, you will create a link policy to match the traffic generated from the application server, and then route the traffic to the link group.

To create a link policy 1. Continuing on the FortiADC-Primary GUI, click Link Load Balance > Link Policy. 2. In the Link Policy section, click Create New, and then configure the following settings:

Field

Value

Name

Primary_Port1_Port3

Ingress Interface

port2

Source Type

Address

Source

Any

Destination Type

Address

Destination

Any

Service

ALL

Link Group

LocalFGT_Port2_Port3

3. Click Save.

Configure NAT Rules The traffic that originated from the internal application server must reach the external network. You will configure two NAT rules, one for each FortiADC egress link, to translate the original source IP to an available IP address in

FortiADC 6.2 Lab Guide Fortinet Technologies Inc.

54

DO Test NOT REPRINT Outbound Link Load Balancing © FORTINET

Exercise 1: Configuring Outbound Link Load Balancing

the 10.0.1.0 (LAN 1) and 10.0.2.0 (LAN 3) subnets respectively.

To create NAT rules 1. Continuing on the FortiADC-Primary GUI, click Network > NAT. 2. Click Create New, and then configure the following settings:

Field

Value

Name

NAT_Port1

Egress Interface

port1

Translation Type

IP Address

Translation to IP Address

10.0.1.17

Status

Enabled

3. Click Save. 4. Click Create New, and then configure the following settings for the second NAT rule:

Field

Value

Name

NAT_Port3

Egress Interface

port3

Translation Type

IP Address

Translation to IP Address

10.0.2.17

Status

Enabled

5. Click Save.

Test Outbound Link Load Balancing You configured the required outbound LLB settings. Now, you will perform some traffic tests, and disable a FortiGate link to observe outbound LLB link behavior.

To generate outbound test traffic 1. Open an SSH session to the FortiGate VM. 2. Enter the following command to capture ICMP traffic: diagnose sniffer packet port5 "icmp and host 10.0.1.17 or 10.0.2.17" 4

3. Open SSH connections to the AppSrv1 and AppSrv2 VMs. 4. On AppSrv1, enter the following command to start generating the ping traffic: ping 100.64.110.100

5. On AppSrv2, enter the following command to start generating the ping traffic: ping 100.64.110.100

55

FortiADC 6.2 Lab Guide Fortinet Technologies Inc.

DO Exercise NOT1: Configuring REPRINT Outbound Link Load Balancing © FORTINET

Test Outbound Link Load Balancing

6. Return to the FortiGate SSH session, observe the packets coming from 10.0.1.17 and 10.0.2.17, and then press Ctrl+C to stop the capture. You will observe that the ping packets were evenly distributed between two gateway links.

To test outbound traffic during gateway link failure 1. Continuing on the FortiGate VM SSH session, press the up arrow key (↑) to repeat the diagnose sniffer packet port5 "icmp and host 10.0.1.17 or 10.0.2.17" 4 command, and then press Enter to start capturing the packets. Since AppSrv1 and AppSrv2 are still sending ping packets, the capture immediately displays the packet trace from 10.0.1.17 and 10.0.2.17. 2. Log in to the FortiGate GUI with the username admin and password password. 3. Click Network > Interfaces. 4. Right-click port2, and then select Disable. 5. Return to the FortiGate VM SSH session. You should see the ping packets coming from 10.0.2.17 only. 6. In the AppSrv1 and AppSrv2 SSH windows, press Ctrl+C to stop the ping test. 7. Close all SSH session browser tabs. 8. Return to the FortiADC-Primary GUI, and then click FortiView > Logical Topology > Link Load Balance. The LocalFGT_10.0.1.10 link should display an error status. 9. Click Log & Report > Traffic Log. 10. Click the first drop-down list, and then select LLB. 11. Click the second drop-down list, and then select all_times. 12. Click Refresh. Wait for the logs to display. Depending on the volume of the records, it might take up to 30 seconds for the logs to display. 13. Examine the logs. You will see FortiADC routed the ping packets from both application servers to the available 10.0.2.10 gateway link.

14. Log out of the FortiADC-Primary GUI. 15. Return to the FortiGate GUI, and then click Network > Interfaces. 16. Right-click port2, and then select Enable.

FortiADC 6.2 Lab Guide Fortinet Technologies Inc.

56

DO Test NOT REPRINT Outbound Link Load Balancing © FORTINET

Exercise 1: Configuring Outbound Link Load Balancing

Outbound LLB applies only to the traffic originating from the internal network, for example, if an internal user connects to an external website or downloads files from an external SFTP server.

17. Log out of the FortiGate GUI.

57

FortiADC 6.2 Lab Guide Fortinet Technologies Inc.

DO NOT REPRINT © FORTINET Lab 5: Global Load Balancing In this lab, you will configure several global load balancing solutions using two FortiADC devices. For the purposes of this lab, assume that the devices are located in two different geographic sites.

Objectives l

Configure global load balancing on FortiADC-Secondary

l

Configure and test global load balancing on both FortiADC devices

l

Configure DNS redundancy for two data centers, and then test site failover

l

Configure gateway monitoring to detect traffic path errors

l

Create single site DNS-based global load balancing using inbound link load balancing (ILLB)

Time to Complete Estimated: 80 minutes

FortiADC 6.2 Lab Guide Fortinet Technologies Inc.

58

DO NOT REPRINT © FORTINET Exercise 1: Configuring FortiADC-Secondary In this exercise, you will use both FortiADC devices to configure and test a global load balancing solution. In this scenario, the FortiADC devices are logically hosted at different data centers that match the following descriptions: l

Site A: FortiADC-Primary, AppSrv1, and AppSrv2

l

Site B: FortiADC-Secondary and AppSrv3

You will create a global load balancing solution for two data centers with FortiADC-Primary configured as the authoritative DNS server. In this exercise, FortiADC-Secondary participates in the global load balancing framework, but it is not configured as a DNS server. The following image summarizes the new network topology for this lab:

You will use the FQDN www.fortinet.lab. At any time, the DNS resolution for that name is one of the virtual server IP addresses located at one of the sites. FortiADC-Primary will act as the load balancer for AppSrv1 and AppSrv2, and also as the global load balancing solution, directing traffic to either Site A or Site B, depending on the availability of the servers.

59

FortiADC 6.2 Lab Guide Fortinet Technologies Inc.

DO Exercise NOT1: Configuring REPRINT FortiADC-Secondary © FORTINET

Configure a Health Check and Layer 7 Virtual Server

Configure a Health Check and Layer 7 Virtual Server You will configure a health check that will monitor the status of AppSrv3.

Take the Expert Challenge! Configure a health check on FortiADC-Secondary with the following settings: l

Name the health check TCPCheck.

l

The health check should use TCP to check port 80.

l

Use the default interval and timeout settings.

If you require assistance, or to verify your work, use the step-by-step instructions that follow. After you complete the challenge, see Create a Real Server Pool With One Member on page 60.

To configure a health check rule on FortiADC-Secondary 1. Log in to the FortiADC-Secondary GUI with the username admin and password password. 2. Click Shared Resources > Health Check. 3. Click Create New, and then configure the following settings to create a new health check:

Field

Value

Name

TCPCheck

Type

TCP

Port

80

Interval

5

Timeout

3

4. Click Save.

Create a Real Server Pool With One Member You will create one real server pool that has only one member, AppSrv3. Remember to enable the health check.

FortiADC 6.2 Lab Guide Fortinet Technologies Inc.

60

DO Create NOT REPRINT a Real Server Pool With One Member © FORTINET

Exercise 1: Configuring FortiADC-Secondary

Take the Expert Challenge! Create a real server pool with one member using the following settings: l

Name the real server pool Ap_3.

l

Add a real server named AppSrv3 with an IP address of 10.200.1.210 to the pool.

If you require assistance, or to verify your work, use the step-by-step instructions that follow. After you complete the challenge, see Create Data Centers and Configure Global Load Balancing on page 62.

To create a real server pool with one member 1. Continuing on the FortiADC-Secondary GUI, click Server Load Balance > Real Server Pool > Real Server Pool. 2. Click Create New, and then configure the following settings to create a new real server pool:

Field

Value

Name

Ap_3

Address Type

IPv4

Health Check

Enabled

3. In the Available Items list, double-click TCPCheck to add it to the Selected Items list. 4. Click Save. 5. Click the edit icon (

) to edit the new real server pool named Ap_3.

6. In the Member pane, click Create New, and then configure the following settings to create a new pool member:

Field

Value

Status

Enable

Real Server

Create New

Name

AppSrv3

Address

10.200.1.210

7. Click Save to close the Real Server configuration screen and return to the Member screen. 8. Verify the Port value is 80, and then click Save again. 9. In the Real Server Pool window, click Save.

To create a Layer 7 virtual server 1. Continuing on the FortiADC-Secondary GUI, click Server Load Balance > Virtual Server. 2. Click Create New > Advanced Mode to create the virtual server. 3. On the Basic tab, configure the following settings:

61

FortiADC 6.2 Lab Guide Fortinet Technologies Inc.

DO Exercise NOT1: Configuring REPRINT FortiADC-Secondary © FORTINET

Create Data Centers and Configure Global Load Balancing

Field

Value

Name

HTTP_VS

Type

Layer 7

Status

Enable

Address Type

IPv4

4. On the General tab, configure the following settings:

Field

Value

Address

10.0.1.150

Port

80

Interface

port1

Profile

LB_PROF_HTTP

Method

LB_METHOD_ROUND_ROBIN

Real Server Pool

Ap_3

Public IPv4

192.168.201.150

5. On the Monitoring tab, enable Traffic Log and FortiView, and then click Save.

Create Data Centers and Configure Global Load Balancing You will create the data centers and configure global load balancing.

To create the data centers 1. Continuing on the FortiADC-Secondary GUI, click Global Load Balance > Global Object > Data Center. 2. Click Create New, and then create a data center named Site_A. Leave the other settings at the default values. 3. Click Save. 4. Click Create New, and then create a data center named Site_B. Leave the other settings at the default values. 5. Click Save.

To define the servers 1. Continuing on the FortiADC-Secondary GUI, click Global Load Balance > Global Object > Server. 2. Click Create New, and then configure the following settings to create the server:

FortiADC 6.2 Lab Guide Fortinet Technologies Inc.

62

DO Create NOT DataREPRINT Centers and Configure Global Load Balancing © FORTINET

Exercise 1: Configuring FortiADC-Secondary

Field

Value

Name

Primary

Type

FortiADC SLB

Address Type

IPv4

IP Address

10.0.1.15

Data Center

Site_A

Auto Sync

On

3. Click Save. 4. Click Create New again, and then configure the following settings to create a second server:

Field

Value

Name

Secondary

Type

FortiADC SLB

Address Type

IPv4

IP Address

10.0.1.16

Data Center

Site_B

Auto Sync

On

5. Click Save.

To configure the members of each server 1. Continuing on the Server page, click the edit icon (

) to edit the Primary server.

2. In the Member pane, verify the HTTP_VS virtual server is in the table. The primary FortiADC virtual server automatically appears because Auto Sync is turned on. 3. Click Save. 4. Click the edit icon (

) to edit the Secondary server.

5. In the Member pane, verify the HTTP_VS virtual server is in the table. The HTTP_VS virtual server automatically appears. 6. Click Save.

To create a virtual server pool 1. Continuing on the FortiADC-Secondary GUI, click Global Load Balance > FQDN > Virtual Server Pool. 2. Click Create New, and then configure the following settings:

63

FortiADC 6.2 Lab Guide Fortinet Technologies Inc.

DO Exercise NOT1: Configuring REPRINT FortiADC-Secondary © FORTINET

Reroute AppSrv3

Field

Value

Name

FortinetLab

Check Server Status

Enabled

Check Virtual Server Existence

Enabled

3. Click Save. 4. Click the edit icon (

) to edit the virtual server pool.

5. In the Member pane, click Create New, and then configure the following settings:

Field

Value

Server

Primary

Server Member

HTTP_VS

6. Click Save. 7. Click Create New again, and then configure the following settings to add the second member of the pool:

Field

Value

Server

Secondary

Server Member

HTTP_VS

8. Click Save, and then click Save again to exit the virtual server pool.

FortiADC-Primary will act as the authoritative DNS for the global load balancing, so you do not need to create a host or zone policy on FortiADC-Secondary.

To disable the DNS settings 1. Continuing on the FortiADC-Secondary GUI, click Global Load Balance > Zone Tools > General Settings. 2. Ensure that the Global DNS Configuration option is off and the Use System DNS Server option is on. 3. Enable Traffic Log. 4. Click Save. 5. Log out of the FortiADC-Secondary GUI.

Reroute AppSrv3 The default gateway of AppSrv3 is currently pointing to FortiADC-Primary. You must change it to FortiADCSecondary.

FortiADC 6.2 Lab Guide Fortinet Technologies Inc.

64

DO Configure NOTaREPRINT FortiGate VIP and a Policy © FORTINET

Exercise 1: Configuring FortiADC-Secondary

To change the route settings of AppSrv3 1. Open an SSH connection to AppSrv3. 2. Enter the following command: ip route show

The default route points to 10.200.1.100, which is the IP address of port2 on FortiADC-Primary. 3. Enter the following command to point the route configuration to the IP address of port2 on FortiADC-Secondary: sudo route add default gw 10.200.1.200 eth0

4. Enter the password password. 5. Enter the following command to remove the old default route from the interface: sudo route del default gw 10.200.1.100 eth0

6. Enter the password password. 7. Enter the following command to check the routing table again: ip route show

8. Close the AppSrv3 SSH session browser tab.

Configure a FortiGate VIP and a Policy You will configure a VIP on FortiGate for the secondary virtual server. You will also configure a firewall policy to allow traffic to the VIP.

Take the Expert Challenge! Configure a virtual IP address on FortiGate with an associated policy to forward traffic to 10.0.1.150, using the following settings: l

Name the virtual IP VS_10.0.1.150.

l

Assign the external IP address 192.168.201.150 and map it to the Layer 7 virtual server you configured.

l

Make sure the VIP is assigned to the correct external interface.

l

Create a firewall policy named VS_10.0.1.150 to allow traffic to the VS_10.0.1.150 VIP. Disable NAT for this policy.

If you require assistance, or to verify your work, use the step-by-step instructions that follow. After you complete the challenge, see Test the New Route on page 67.

To configure a FortiGate VIP and a policy for the secondary HTTP_VS 1. Log in to the FortiGate GUI with the username admin and password password. 2. If a Password Change alert box appears, click Later to skip the password change. 3. Click Policy & Objects > Virtual IPs. 4. Click Create New, and then select Virtual IP in the drop-down list. 5. On the New Virtual IP page, configure the following settings:

65

FortiADC 6.2 Lab Guide Fortinet Technologies Inc.

DO Exercise NOT1: Configuring REPRINT FortiADC-Secondary © FORTINET

Configure a FortiGate VIP and a Policy

Field

Value

Name

VS_10.0.1.150

Interface

port5

External IP Address/Range

192.168.201.150

Mapped IP Address/Range

10.0.1.150

6. Click OK to save the settings.

To configure a FortiGate IPv4 policy 1. Click Policy & Objects > Firewall Policy. 2. Click Create New, and then configure the following settings:

Field

Value

Name

VS_10.0.1.150

Incoming Interface

port5

Outgoing Interface

port2

Source

100.64.110.0

Destination

VS_10.0.1.150

Schedule

always

Service

HTTP, HTTPS

Action

ACCEPT

NAT

Disable

Enable this policy

Enable

3. Click OK to save the settings. 4. In the IPv4 policy table, drag the VS_10.0.1.150 policy ID column and place it before the Block-External policy.

FortiADC 6.2 Lab Guide Fortinet Technologies Inc.

66

DO Test NOT REPRINT the New Route © FORTINET

Exercise 1: Configuring FortiADC-Secondary

5. Log out of the FortiGate GUI.

Test the New Route You will test your configuration by accessing the secondary virtual server from the Linux-External VM.

To test the new route 1. On the Linux-External VM, open a browser, and then connect to the secondary virtual server on FortiADCSecondary at http://192.168.201.150. 2. Press F5 to refresh the web page. The device routes to AppSrv3.

67

FortiADC 6.2 Lab Guide Fortinet Technologies Inc.

DO NOT REPRINT © FORTINET Exercise 2: Reconfiguring FortiADC-Primary You must remove AppSrv3 from the virtual server on FortiADC-Primary because AppSrv3 is now part of the Site_ B data center. Then, you will configure global load balancing on FortiADC-Primary and enable it as the authoritative DNS server for Site_A and Site_B.

Reconfigure FortiADC-Primary You must modify some virtual server and real server pool settings on FortiADC-Primary.

Take the Expert Challenge! On FortiADC-Primary, reconfigure the HTTP_VS virtual server and the Ap_Servers real server pool by updating the following settings: l

Disable content routing and persistence on the HTTP_VS virtual server.

l

Configure the public IPv4 to 192.168.201.50 for FortiGSLB.

l

Update the Ap_Servers real server pool to use the TCPCheck health check, and then remove AppSrv3 from the pool.

If you require assistance, or to verify your work, use the step-by-step instructions that follow. After you complete the challenge, see Configure Global Load Balancing on page 69.

To reconfigure the virtual servers 1. Log in to the FortiADC-Primary GUI with the username admin and password password. 2. Click Server Load Balance > Virtual Server. 3. Click the edit icon (

) to edit the HTTP_VS virtual server.

4. In the Basic settings page, turn off the Content Routing switch. 5. Click the General tab, and then disable Persistence by setting the option to Click to select. 6. In the FortiGSLB section, set Public IPv4 to 192.168.201.50. 7. Click Save.

To remove AppSrv3 from the real server pool 1. Continuing on the FortiADC-Primary GUI, click Server Load Balance > Real Server Pool. 2. Click the edit icon (

) to edit the Ap_Servers.

3. Turn on Health Check. 4. Double-click HTTPCheck to remove it from the Selected Items list. 5. In the Available Items list, double-click TCPCheck to add it to the Selected Items list.

FortiADC 6.2 Lab Guide Fortinet Technologies Inc.

68

DO Configure NOTGlobal REPRINT Load Balancing © FORTINET

Exercise 2: Reconfiguring FortiADC-Primary

6. Delete the AppSrv3 member. 7. Click Save.

Configure Global Load Balancing You will configure global load balancing on FortiADC-Primary.

To create data centers 1. Continuing on the FortiADC-Primary GUI, click Global Load Balance > Global Object > Data Center. 2. Click Create New, and then add two new data centers—Site_A and Site_B. Leave the other settings for each data center at the default values.

To define the servers 1. Continuing on the FortiADC-Primary GUI, click Global Load Balance > Global Object > Server. 2. Click Create New, and then configure the following settings to create the server:

Field

Value

Name

Primary

Type

FortiADC SLB

Address Type

IPv4

IP Address

10.0.1.15

Data Center

Site_A

Auto Sync

On

3. Click Save. 4. Click Create New again, and then configure the following settings to create a second server:

Field

Value

Name

Secondary

Type

FortiADC SLB

Address Type

IPv4

IP Address

10.0.1.16

Data Center

Site_B

Auto Sync

On

5. Click Save.

69

FortiADC 6.2 Lab Guide Fortinet Technologies Inc.

DO Exercise NOT2: Reconfiguring REPRINT FortiADC-Primary © FORTINET

Configure Global Load Balancing

To configure the members of each server 1. Click the edit icon (

) to edit the Primary server.

2. In the Member pane, verify the HTTP_VS virtual server is in the table. The FortiADC-Primary virtual server automatically appears because Auto Sync is turned on. 3. Click Save. 4. Click the edit icon (

) to edit the Secondary server.

5. In the Member pane, verify the HTTP_VS virtual server is in the table. The HTTP_VS virtual server automatically appears. 6. Click Save.

To create a virtual server pool 1. Continuing on the FortiADC-Primary GUI, click Global Load Balance > FQDN > Virtual Server Pool. 2. Click Create New, and then configure and confirm the following settings:

Field

Value

Name

FortinetLab

Check Server Status

Enabled

Check Virtual Server Existence

Enabled

3. Click Save. 4. Click the edit icon (

) to edit the virtual server pool.

5. In the Member pane, click Create New, and then configure the following settings:

Field

Value

Server

Primary

Server Member

HTTP_VS

6. Click Save. 7. In the Member pane, click Create New again, and then configure the following settings to add the second member of the pool:

Field

Value

Server

Secondary

Server Member

HTTP_VS

8. Click Save, and then click Save again to exit the virtual server pool.

FortiADC 6.2 Lab Guide Fortinet Technologies Inc.

70

DO Configure NOTGlobal REPRINT Load Balancing © FORTINET

Exercise 2: Reconfiguring FortiADC-Primary

To define the FQDN settings 1. Continuing on the FortiADC-Primary GUI, click Global Load Balance > FQDN > Host. 2. Click Create New, and then configure the following settings:

Field

Value

Name

FortinetLab

Host Name

www

Domain Name

fortinet.lab.

DNS Policy

DEFAULT_DNS_POLICY

Respond Single Record

Disabled

FortiView

Enabled

3. Click Save. 4. Click the edit icon (

) to edit the FortinetLab host.

5. In the Virtual Server Pool pane, click Create New, and then configure the following settings:

Field

Value

Name

FortinetTrg

Virtual Server Pool

FortinetLab

6. Click Save, and then click Save again to exit the Host configuration.

A new zone is automatically generated by the system. To view the auto-generated zone, click Global Load Balance > Zone Tools > Zone.

7. Click Global Load Balance > Zone Tools > General Settings. 8. Enable Global DNS Configuration, Recursion, and Traffic Log. 9. Click Save.

To create a DNS policy 1. Continuing on the FortiADC-Primary GUI, click Global Load Balance > Zone Tools > Global DNS Policy. 2. Click the edit icon (

71

) to edit DEFAULT_DNS_POLICY, and then configure the following settings:

Field

Value

Source

any

FortiADC 6.2 Lab Guide Fortinet Technologies Inc.

DO Exercise NOT2: Reconfiguring REPRINT FortiADC-Primary © FORTINET

Configure Global Load Balancing

Field

Value

Destination

any

Zone List

fqdn_generate_fortinet.lab.

Recursion

Enabled

3. Click Save. 4. Click Global Load Balance > Zone Tools > Zone, and then click the edit icon ( fortinet.lab. entry using the following settings:

Field

Value

TTL

1

Serial

1

) to edit the fqdn_generate_

For lab testing purposes, setting TTL to 1 forces the client DNS resolver to expire the DNS cache every second, and then send a new query to FortiADC for new connection requests. This is not recommended in a production environment. 5. Click Save. 6. Click FortiView > Logical Topology > Global Load Balance.

Observe the FQDN, virtual server pool, and virtual server connections in the logical topology. 7. Log out of the FortiADC-Primary GUI.

To test the changes in the virtual server 1. On the Linux-External VM, open a browser, and then connect to the virtual server configured on FortiADC-Primary at http://192.168.201.50. 2. Press Ctrl+Shift+R to refresh the browser page several times. You are routed to either AppSrv1 or AppSrv2. 3. Close the Linux-External VM browser tab.

FortiADC 6.2 Lab Guide Fortinet Technologies Inc.

72

DO NOT REPRINT © FORTINET Exercise 3: Testing the Global Load Balancing

Configuration In this exercise, you will test and verify the global load balancing configuration. The primary DNS for the LinuxExternal VM is 192.168.201.15.

Test the Global Load Balancing Configuration You will validate the DNS host configuration on the Linux-External VM, and then test the global load balancing configuration.

To verify the DNS server settings 1. On the Linux-External VM, open a terminal window, and then enter the following command: cat /etc/network/interfaces

Verify that the first two DNS servers are 192.168.201.15 and 192.168.201.16 for the eth0 interface. 2. Enter the following command to check the www.fortinet.lab DNS name: nslookup www.fortinet.lab

The FortiADC-Primary VM should reply with the DNS record that contains two virtual servers for the www.fortinet.lab FQDN—192.168.201.50 and 192.168.201.150.

To test the global load balancing configuration 1. On the Linux-External VM, open a browser, and then connect to the global load balancer URL at: http://www.fortinet.lab

2. Press F5 several times to reload the web page. The connection to the same site is maintained—either to Site_A (AppSrv1 or AppSrv2) or Site_B (AppSrv3). The global load balancing scenario for this lab is not designed to distribute the user connections between both sites evenly, but to show an example of a mechanism for geographic redundancy. FortiADC supports intelligent GLB features, including distributing the load base on geographic proximity, application response time, least connections, and server persistence. If both sites are up, most of the user traffic is routed to one of the sites. The other site is used when no server is available at the main site.

Test Server Redundancy You will turn off web services for the site you are currently connecting to.

73

FortiADC 6.2 Lab Guide Fortinet Technologies Inc.

DO Exercise NOT3: Testing REPRINT the Global Load Balancing Configuration © FORTINET l

If you are connecting to Site_B, turn off web services in AppSrv3.

l

If you are connecting to Site_A, turn off web services in AppSrv1 and AppSrv2.

Test Server Redundancy

To test server redundancy 1. Open an SSH connection to the application server(s) you are connecting to, and then enter the following command: sudo service apache2 stop

2. Enter the password password. 3. Return to the Linux-External VM, and then in the terminal window, enter the following command to check the www.fortinet.lab DNS name: nslookup www.fortinet.lab

The failed FortiADC virtual server IP address is not included in the DNS response. 4. Return to the browser tab connected to www.fortinet.lab, and then press Ctrl+Shift+R a few times. The traffic is routed to the other site. 5. Log in to the FortiADC-Primary GUI with the username admin and password password. 6. Click FortiView > Logical Topology > Global Load Balance. One of the servers shows an unavailable state. It may take a moment for the view to update. 7. Log out of the FortiADC-Primary GUI. 8. Return to the failed application server(s) SSH session, and then enter the following command to restart the web services: sudo service apache2 start

9. Enter the password password. Stop and think! What will happen if Site_A on FortiADC-Primary is down? Can you connect to www.fortinet.lab through FortiADC-Secondary at Site_B? The FortiADC-Primary VM in this lab is a single point of failure. If FortiADC-Primary is down, the www.fortinet.lab FQDN becomes unreachable, regardless of the status of FortiADC-Secondary. You will configure DNS redundancy for the www.fortinet.lab FQDN in the next lab exercise. 10. Close the SSH session browser tab. 11. Close the Linux-External VM browser tab.

FortiADC 6.2 Lab Guide Fortinet Technologies Inc.

74

DO NOT REPRINT © FORTINET Exercise 4: Configuring a DNS Zone and Policy on

FortiADC-Secondary In this exercise, you will configure FortiADC-Secondary to participate in the GLB authoritative DNS server chain. Site_A and Site_B are protected with DNS redundancy. If one of the sites is down, the www.fortinet.lab web service remains available through the other site.

Configure a DNS Zone and Policy on FortiADC-Secondary You will configure DNS settings on FortiADC-Secondary.

Take the Expert Challenge! On FortiADC-Secondary, create an FQDN host. l

Use the name FortinetLab.

l

Use the FQDN host www.fortinet.lab, with FortiView enabled.

l

Assign the DEFAULT_DNS_POLICY to the FQDN host.

l

Create a new virtual server pool assignment with the name FortinetTrg.

l

Assign the FortinetLab virtual server pool to the FQDN host.

On FortiADC-Secondary, edit the DEFAULT_DNS_POLICY as follows: l

The policy should allow traffic from any source to any destination.

l

The policy should use the fqdn_generate_fortinet.lab zone list, and allow recursion.

l

Update the fqdn_generate_fortinet.lab zone to have a TTL value of 1 and a Serial value of 1.

Finally, verify your configuration using the Global Load Balance view in the Logical Topology section of the FortiView page. If you require assistance, or to verify your work, use the step-by-step instructions that follow.

To define the FQDN host settings 1. Log in to the FortiADC-Secondary GUI with the username admin and password password. 2. Click Global Load Balance > FQDN > Host. 3. Click Create New, and then configure the following settings:

75

Field

Value

Name

FortinetLab

FortiADC 6.2 Lab Guide Fortinet Technologies Inc.

a DNS Zone and Policy on FortiADCDO Exercise NOT4: Configuring REPRINT Secondary © FORTINET

Configure a DNS Zone and Policy on FortiADCSecondary

Field

Value

Host Name

www

Domain Name

fortinet.lab.

DNS Policy

DEFAULT_DNS_POLICY

Respond Single Record

Disabled

FortiView

Enabled

4. Click Save. 5. Click the edit icon (

) to edit the FortinetLab host.

6. In the Virtual Server Pool pane, click Create New, and then configure the following settings:

Field

Value

Name

FortinetTrg

Virtual Server Pool

FortinetLab

7. Click Save, and then click Save again to exit the Host configuration.

A new zone is automatically generated by the system. To view the auto-generated zone, click Global Load Balance > Zone Tools > Zone.

8. Click Global Load Balance > Zone Tools > General Settings. 9. Enable Global DNS Configuration, Recursion, and Traffic Log. 10. Click Save.

To create a DNS policy 1. Continuing on the FortiADC-Secondary GUI, click Global Load Balance > Zone Tools > Global DNS Policy. 2. Click the edit icon (

) to edit DEFAULT_DNS_POLICY, and then configure the following settings:

Field

Value

Source

any

Destination

any

Zone List

fqdn_generate_fortinet.lab.

Recursion

Enabled

3. Click Save. 4. Click the Zone tab, and then click the edit icon (

FortiADC 6.2 Lab Guide Fortinet Technologies Inc.

) to edit the fqdn_generate_fortinet.lab. entry:

76

DNS Zone and Policy on FortiADCDO Configure NOTaREPRINT Secondary © FORTINET

Exercise 4: Configuring a DNS Zone and Policy on FortiADCSecondary

Field

Value

TTL

1

Serial

1

5. Click Save. 6. Click FortiView > Logical Topology, and then select the Global Load Balance tab. Observe the FQDN, data centers, and virtual servers connection in the logical topology. 7. Log out of the FortiADC-Secondary GUI.

77

FortiADC 6.2 Lab Guide Fortinet Technologies Inc.

DO NOT REPRINT © FORTINET Exercise 5: Testing the DNS Redundancy In this exercise, you will test and verify the DNS redundancy between Site_A and Site_B for the global load balancing configuration. The primary DNS server for the Linux-External VM is 192.168.201.15 and the secondary is 192.168.201.16.

To verify the DNS server settings 1. On the Linux-External VM, open a terminal window, and then enter the following command: cat /etc/network/interfaces

2. Verify that the first two DNS servers are 192.168.201.15 and 192.168.201.16 for the eth0 interface. 3. Enter the following command to check the www.fortinet.lab DNS name: nslookup www.fortinet.lab

The FortiADC-Primary VM should reply with the DNS record that contains two virtual servers for the www.fortinet.lab FQDN. 4. Enter the following command to check the www.fortinet.lab DNS name: nslookup www.fortinet.lab 192.168.201.16

The FortiADC-Secondary VM should reply with the DNS record that contains two virtual servers for the www.fortinet.lab FQDN.

To test the global load balance 1. On the Linux-External VM, open a browser, and then connect to the global load balance URL at: http://www.fortinet.lab

2. Press F5 several times to reload the web page. The connection to the same site is maintained, either to Site_A (AppSrv1 or AppSrv2) or Site_B (AppSrv3).

Test Server Redundancy You will turn off web services for the site you are currently connecting to. l

If you are connecting to Site_B, turn off web services in AppSrv3.

l

If you are connecting to Site_A, turn off web services in AppSrv1 and AppSrv2.

To test the redundancy using global load balance 1. Open an SSH connection to the application server(s) you are connecting to. 2. Enter the following command: sudo service apache2 stop

3. Enter the password password. 4. Return to the Linux-External VM terminal window, and then enter the following command to check the www.fortinet.lab DNS name: nslookup www.fortinet.lab

The failed FortiADC virtual server IP address is not included in the DNS response. 5. Return to the browser tab connected to www.fortinet.lab, and then press F5 a few times.

FortiADC 6.2 Lab Guide Fortinet Technologies Inc.

78

DO Test NOT REPRINT DNS Redundancy © FORTINET

Exercise 5: Testing the DNS Redundancy

The traffic is routed to the other site. 6. Log in to the FortiADC-Primary GUI with the username admin and password password. 7. Click FortiView > Logical Topology > Global Load Balance. 8. Log in to the FortiADC-Secondary GUI with the username admin and password password. 9. Click FortiView > Logical Topology > Global Load Balance. The two topology maps should display the same GLB operating status. 10. Return to the application server(s) SSH session, and then enter the following command to restart the web services: sudo service apache2 start

11. Enter the password password. 12. Close the application server(s) SSH session browser tab.

Test DNS Redundancy You will disable a FortiADC-Primary interface to test DNS redundancy, and then disable a FortiADC-Secondary interface to repeat the same test.

To test the DNS redundancy using FortiADC-Secondary 1. Return to the FortiADC-Primary GUI, and then click Network > Interface. 2. Click the edit icon (

) to edit port1, and then set Status to Disabled.

3. Click Save. 4. Return to the Linux-External VM terminal window, and then enter the following command to check the www.fortinet.lab DNS name: nslookup www.fortinet.lab

The response is from FortiADC-Secondary (192.168.201.16) and the reply contains the Site_B virtual server IP. 5. Return to the browser tab connected to www.fortinet.lab, and then press F5 a few times. The traffic is routed to Site_B. 6. Return to the FortiADC-Secondary GUI, and then click FortiView > Logical Topology > Global Load Balance. The topology map shows an error condition. 7. Return to the FortiADC-Primary GUI, and then click Network > Interface. 8. Click the edit icon (

) to edit port1, and then set Status to Enabled.

9. Click Save. 10. Log out of the FortiADC-Primary GUI.

To test the DNS redundancy using FortiADC-Primary 1. Return to the FortiADC-Secondary GUI, and then click Network > Interface. 2. Click the edit icon (

) to edit port1, and then set Status to Disabled.

3. Click Save. 4. Return to the Linux-External VM, in the terminal window, enter the following command, and then view the DNS reply: nslookup www.fortinet.lab

79

FortiADC 6.2 Lab Guide Fortinet Technologies Inc.

DO Exercise NOT5: Testing REPRINT the DNS Redundancy © FORTINET

Test DNS Redundancy

The response is from FortiADC-Primary (192.168.201.15) and the reply contains the Site_A virtual server IP. 5. Return to the browser tab connected to www.fortinet.lab, and then press F5 a few times. The traffic is routed to Site_A AppSrv1 and AppSrv2 servers. 6. Return to the FortiADC-Secondary GUI, and then click Network > Interface. 7. Click the edit icon (

) to edit port1, and then set Status to Enabled.

8. Click Save. The global load balancing scenario for this lab is also not designed to distribute the user connections between both sites evenly. FortiADC supports intelligent GLB features, including distributing the load base on geographic proximity, application response time, least connections, and server persistence. You can refer to the FortiADC documentation to explore these features for your design. 9. Log out of the FortiADC-Secondary GUI. 10. Close the Linux-External VM browser tab.

FortiADC 6.2 Lab Guide Fortinet Technologies Inc.

80

DO NOT REPRINT © FORTINET Exercise 6: Configuring Gateway Monitoring for the GLB Using gateway monitoring in a GLB network adds an extra layer of error detection. So far, you have learned how to use DNS redundancy to route traffic between sites when FortiADC is down. However, what if the upstream router or a remote router in the GLB traffic path is not working? This type of problem usually cannot be detected by FortiADC, and users may still try to connect to an inaccessible site before the DNS records time out. The solution is to apply the LLB gateway link groups and a remote router health check to discover the problem. In this exercise, you will apply the gateway links and remote router health check you configured in the LLB lab on the GLB configuration for Site_A.

Review the Link Load Balance Configuration You will review the configured remote router health check, link group, and link policy from the previous lab.

To review the health check and link load balancing configuration 1. Log in to the FortiADC-Primary GUI with the username admin and password password. 2. Click Shared Resources > Health Check. 3. Click the edit icon (

) to review HC_100.64.110.100.

This health check object uses ICMP to probe the external IP 100.64.110.100. 4. Click Cancel. 5. Click Link Load Balance > Link Group, and then select the Gateway tab. 6. Click the edit icon (

) to review each FortiGate link.

Both links use the health check. 7. Click Cancel. 8. Click the Link Group tab. 9. Click the edit icon (

) for the LocalFGT_Port2_Port3 link group to review the link group and link members.

10. Click Cancel.

Change the FortiADC-Secondary Virtual Server IP Address You will change the virtual server IP address on FortiADC-Secondary to use the 10.0.2.0 subnet to test gateway monitoring.

81

FortiADC 6.2 Lab Guide Fortinet Technologies Inc.

DO Exercise NOT6: Configuring REPRINT Gateway Monitoring for the GLB © FORTINET

Configure Gateway Monitoring on GLB and Test Site_A

Take the Expert Challenge! On FortiADC-Secondary, update the following settings on the HTTP_VS virtual server: l

Change the IP address to 10.0.2.150.

l

Change the interface to port3.

l

Change the public address to 192.168.202.150.

On FortiADC-Secondary, update the global object servers configured for global load balancing by making the following changes: l

Change the Primary IP address to 10.0.2.15.

l

Change the Secondary IP address to 10.0.2.16.

If you require assistance, or to verify your work, use the step-by-step instructions that follow. After you complete the challenge, see Configure Gateway Monitoring on GLB and Test Site_A on page 82.

To change the FortiADC-Secondary virtual server IP address 1. Log in to the FortiADC-Secondary GUI with the username admin and password password. 2. Click Server Load Balance > Virtual Server > Virtual Server. 3. Click the edit icon (

) to edit HTTP_VS.

4. On the General tab, revise the following settings:

Field

Value

Address

10.0.2.150

Interface

port3

Public IPv4

192.168.202.150

5. Click Save. 6. Click Global Load Balance > Global Object > Server. 7. Click the edit icon (

) to edit Primary.

8. Change IP Address from 10.0.1.15 to 10.0.2.15, and then click Save. 9. Return to the FortiADC-Primary GUI, and then click Global Load Balance > Global Object > Server. 10. Click the edit icon (

) to edit Secondary.

11. Change IP Address from 10.0.1.16 to 10.0.2.16. 12. Click Save.

Configure Gateway Monitoring on GLB and Test Site_A You will apply the gateway link on the virtual server.

FortiADC 6.2 Lab Guide Fortinet Technologies Inc.

82

DO Configure NOTGateway REPRINT Monitoring on GLB and Test Site_A © FORTINET

Exercise 6: Configuring Gateway Monitoring for the GLB

To configure gateway monitoring for Site_A 1. Return to the FortiADC-Primary GUI, and then click Global Load Balance > Global Object. 2. Click the edit icon (

) to edit Primary.

3. Click the edit icon (

) to edit HTTP_VS, and then click to select LocalFGT_10.0.1.10 for the Gateway.

4. Click Save, and then click Save again. 5. Return to the FortiADC-Secondary GUI, and then click Global Load Balance > Global Object. 6. Click the edit icon (

) to edit Primary.

7. Click the edit icon (

) to edit HTTP_VS, and then click to select LocalFGT_10.0.1.10 for the Gateway.

8. Click Save, and then click Save again.

To test Site_A availability 1. Continuing on the FortiADC-Secondary GUI, click FortiView > Logical Topology > Global Load Balance. 2. Click the topology refresh icon (

) to reload the logical topology.

There is no error condition in the GLB network. 3. On the Linux-External VM, open a terminal window, and then enter the following command to check the www.fortinet.lab DNS name: nslookup www.fortinet.lab

FortiADC-Primary replies with the DNS record that contains two virtual servers for the www.fortinet.lab FQDN. 4. Log in to the FortiGate GUI with the username admin and password password. 5. Click Network > Interfaces. 6. Right click port2, and then select Disable. 7. Return to the FortiADC-Secondary GUI, and then click FortiView > Logical Topology > Global Load Balance. 8. Click the topology refresh icon ( ) to reload the logical topology. The topology map displays the FortiADC-Primary (Site_A) virtual server as unavailable. 9. Return to the Linux-External VM, and then in the terminal window, enter the following command again: nslookup www.fortinet.lab

FortiADC-Primary responds with the DNS record that contains the Site_B virtual servers for the www.fortinet.lab FQDN. 10. On the Linux-External VM, open a browser, and then connect to http://www.fortinet.lab. 11. Press F5 several times to reload the web page. The connection is routed to the Site_B AppSrv3. 12. Close the Linux-External VM browser tab. 13. Log out of the FortiADC-Secondary GUI. 14. Log out of the FortiADC-Primary GUI.

To enable FortiGate port2 1. Return to the FortiGate GUI, and then click Network > Interfaces. 2. Right-click port2, and then select Enable. 3. Log out of the FortiGate GUI.

83

FortiADC 6.2 Lab Guide Fortinet Technologies Inc.

DO NOT REPRINT © FORTINET Exercise 7: Configuring Inbound Link Load Balancing for

the GLB Inbound link load balancing (ILLB) is another DNS-based solution for global load balancing. A client queries DNS to resolve the IP address of an FQDN. However, unlike multisite GLB, the IP address returned in the ILLB DNS reply does not represent a geographic location, but rather one of several links available on a single FortiADC. Therefore, ILLB is a useful solution for a single FortiADC site in a small or medium sized organization that has multi-homed ISP connections. In this exercise, you will configure ILLB on FortiADC-Primary to achieve a single site global load balance. You will create two new virtual servers and publish a new FQDN for the web service.

Create Layer 7 Virtual Servers You will configure two Layer 7 virtual servers.

FortiADC 6.2 Lab Guide Fortinet Technologies Inc.

84

DO Create NOT REPRINT Layer 7 Virtual Servers © FORTINET

Exercise 7: Configuring Inbound Link Load Balancing for the GLB

Take the Expert Challenge! Configure two virtual servers for ILLB. Both servers must be Layer 7, listen on port 80, and use the HTTPProfile profile, the LB_METHOD_ROUND_ROBIN method for load balancing, and the Ap_servers real server pool. l

Name the first virtual server ILLB_VS1, and assign the IP address 192.168.201.60 and the appropriate interface.

l

Name the second virtual server ILLB_VS2, and assign the IP address of 192.168.202.60 and the appropriate interface.

If you require assistance, or to verify your work, use the step-by-step instructions that follow. After you complete the challenge, see Configure Gateway Monitoring on ILLB Virtual Servers on page 86.

To create Layer 7 virtual servers 1. Log in to the FortiADC-Primary GUI with the username admin and password password. 2. Click Server Load Balance > Virtual Server. 3. Click Create New, and then select Advanced Mode. 4. Configure the following settings to create a new virtual server:

Field

Value

Name

ILLB_VS1

Type

Layer 7

Status

Enable

Address Type

IPv4

5. On the General tab, configure the following settings:

85

Field

Value

Address

192.168.201.60

Port

80

Interface

port1

Profile

HTTPProfile

Method

LB_METHOD_ROUND_ROBIN

Real Server Pool

Ap_Servers

FortiADC 6.2 Lab Guide Fortinet Technologies Inc.

Inbound Link Load Balancing for the DO Exercise NOT7: Configuring REPRINT GLB © FORTINET

Configure Gateway Monitoring on ILLB Virtual Servers

Note that the ILLB virtual server uses the public IP address directly. It requires the FortiGate to have routes to 192.168.201.60 and 192.168.202.60, and an IPv4 policy to allow the incoming traffic. These settings are preconfigured for this exercise. Verify the static routes and policy configuration on the FortiGate GUI. 6. On the Monitoring tab, enable Traffic Log and FortiView. 7. Click Save. 8. Click Create New, and then select Advanced Mode. 9. Configure the following settings to create another virtual server:

Field

Value

Name

ILLB_VS2

Type

Layer 7

Status

Enable

Address Type

IPv4

10. On the General tab, configure the following settings:

Field

Value

Address

192.168.202.60

Port

80

Interface

port3

Profile

HTTPProfile

Method

LB_METHOD_ROUND_ROBIN

Real Server Pool

Ap_Servers

11. On the Monitoring tab, enable Traffic Log and FortiView. 12. Click Save.

Configure Gateway Monitoring on ILLB Virtual Servers You will define the gateway links for the virtual servers.

FortiADC 6.2 Lab Guide Fortinet Technologies Inc.

86

Virtual Server Pool and DNS Zone DO Configure NOTaREPRINT Policy © FORTINET

Exercise 7: Configuring Inbound Link Load Balancing for the GLB

Take the Expert Challenge! On FortiADC-Primary, configure gateway monitoring for Site_A virtual servers defined in the Primary global object server. Configure ILLB_VS1 to use the LocalFGT_10.0.1.10 gateway and IILB_VS2 to use the LocalFGT_10.0.2.10 gateway. If you require assistance, or to verify your work, use the step-by-step instructions that follow. After you complete the challenge, see Configure a Virtual Server Pool and DNS Zone Policy on page 87.

To configure gateway monitoring on ILLB virtual servers for Site_A 1. Log in to FortiADC-Primary with the username admin and password password. 2. Click Global Load Balance > Global Object. 3. Click the edit icon (

) to edit the Primary server.

The auto sync feature automatically adds new virtual servers in the member list. 4. Click the edit icon (

) to edit ILLB_VS1, and then click to select LocalFGT_10.0.1.10 for the gateway.

5. Click Save. 6. Click the edit icon (

) to edit ILLB_VS2, and then click to select LocalFGT_10.0.2.10 for the gateway.

7. Click Save, and then click Save again.

Configure a Virtual Server Pool and DNS Zone Policy You will configure a virtual server pool and DNS zone and policy.

Take the Expert Challenge! On FortiADC-Primary, create a virtual server pool. l

Name the pool ILLBLab.

l

Configure the pool to check for server status and server existence. The virtual server pool must contain two members. The first member is ILLB_VS1 as a server member of the Primary server and the second member is ILLB_VS2, which is also a server member of the Primary server.

l

Create an FQDN host for the www.fortiadc.lab domain. This domain should use the default DNS policy and have FortiView enabled. The virtual server pool for this domain is ILLBLab.

l

Update the TTL and Serial settings to 1 for the foriadc.lab zone.

If you require assistance, or to verify your work, use the step-by-step instructions that follow. After you complete the challenge, see Test ILLB GLB on page 89.

To configure a virtual server pool 1. Continuing on the FortiADC-Primary GUI, click Global Load Balance > FQDN > Virtual Server Pool. 2. Click Create New, and then configure and confirm the following settings:

87

FortiADC 6.2 Lab Guide Fortinet Technologies Inc.

Inbound Link Load Balancing for the DO Exercise NOT7: Configuring REPRINT GLB © FORTINET

Configure a Virtual Server Pool and DNS Zone Policy

Field

Value

Name

ILLBLab

Check Server Status

Enabled

Check Virtual Server Existence

Enabled

3. Click Save. 4. Click the edit icon (

) to edit the ILLBLab virtual server pool.

5. In the Member pane, click Create New, and then configure the following settings:

Field

Value

Server

Primary

Server Member

ILLB_VS1

6. Click Save. 7. In the Member pane, click Create New again, and then configure the following settings to add the second member of the pool:

Field

Value

Server

Primary

Server Member

ILLB_VS2

8. Click Save, and then click Save again to exit the virtual server pool.

To define the FQDN settings 1. Continuing on the FortiADC-Primary GUI, click Global Load Balance > FQDN > Host. 2. Click Create New, and then configure the following settings:

Field

Value

Name

ILLBLab

Host Name

www

Domain Name

fortiadc.lab.

DNS Policy

DEFAULT_DNS_POLICY

Respond Single Record

Disabled

FortiView

Enabled

3. Click Save. 4. Click the edit icon (

FortiADC 6.2 Lab Guide Fortinet Technologies Inc.

) to edit the ILLBLab host.

88

DO Test NOT REPRINT ILLB GLB © FORTINET

Exercise 7: Configuring Inbound Link Load Balancing for the GLB

5. In the Virtual Server Pool pane, click Create New, and then configure the following settings:

Field

Value

Name

FortinetTrg

Virtual Server Pool

ILLBLab

6. Click Save, and then click Save again to exit the Host configuration.

A new zone is automatically generated by the system. To view the auto-generated zone, click Global Load Balance > Zone Tools > Zone.

7. Click Global Load Balance > Zone Tools > General Settings. 8. Validate Global DNS Configuration, Recursion, and Traffic Log are enabled. 9. Click Save.

To modify the default DNS policy 1. Continuing on the FortiADC-Primary GUI, click Global Load Balance > Zone Tools > Global DNS Policy. 2. Click the edit icon (

) to edit DEFAULT_DNS_POLICY.

3. Verify fqdn_generate_fortiadc.lab. is in the Zone List Selected Items. 4. Click Save. 5. Click Zone, and then click the edit icon ( settings:

) to edit the fqdn_generate_fortiadc.lab. entry using the following

Field

Value

TTL

1

Serial

1

For lab testing purposes, the TTL value of 1 forces the client DNS resolver to expire its DNS cache every second and send a new query to FortiADC for new connection requests. This is not recommended in a production environment. 6. Click Save. 7. Click FortiView > Logical Topology > Global Load Balance. Observe the FQDN, data centers, and virtual servers connection in the logical topology. 8. Log out of the FortiADC-Primary GUI.

Test ILLB GLB You will test ILLB functionality and observe the behavior.

89

FortiADC 6.2 Lab Guide Fortinet Technologies Inc.

DO Exercise NOT7: Configuring REPRINT Inbound Link Load Balancing for the GLB © FORTINET

Test ILLB GLB

To test Site_A ILLB 1. On the Linux-External VM, open a terminal window, and then enter the following command: nslookup www.fortiadc.lab

FortiADC-Primary should reply with the DNS record that contains two virtual servers for the www.fortiadc.lab FQDN. 2. On the Linux-External VM, open a browser, and then connect to http://www.fortiadc.lab. 3. Press F5 several times to reload the web page. The connection is routed to the AppSrv1 and AppSrv2. 4. Return to the FortiADC-Primary GUI, and then click Log & Report > Traffic Log. 5. In the first drop-down box, select GLB, and then in the second drop-down box, select all_times. 6. Click the Refresh button, and then wait for the traffic log report to appear. The traffic is load balanced between two virtual servers. 7. Log in to the FortiGate GUI with the username admin and password password. 8. Click Network > Interfaces. 9. Right-click port3, and then select Disable. 10. Return to the FortiADC-Primary GUI, and then click FortiView > Logical Topology > Global Load Balance. 11. Click the refresh icon ( ) to reload the logical topology. The topology map displays the ILLB_VS2 virtual server as unavailable. 12. Log out of the FortiADC-Primary GUI. 13. Return to the Linux-External VM, and then in the terminal window, enter the following command: nslookup www.fortiadc.lab

FortiADC-Primary responds with the DNS record, which contains only one virtual server for the www.fortiadc.lab FQDN. 14. On the Linux-External VM, return to the browser tab connected to http://www.fortiadc.lab, and then press F5 several times to reload the web page. The service to AppSrv1 and AppSrv2 is still working but via FortiADC-Primary port1. 15. Close the Linux-External VM browser tab.

To enable FortiGate port3 1. Return to the FortiGate GUI, and then click Network > Interfaces. 2. Right-click port3, and then select Enable. 3. Log out of the FortiGate GUI.

FortiADC 6.2 Lab Guide Fortinet Technologies Inc.

90

DO NOT REPRINT © FORTINET Lab 6: FortiADC Security In this lab, you will configure a firewall policy and two web application firewall (WAF) policies to improve the security in your network.

Objectives l

Create a firewall policy

l

Block any client attempts to connect directly to the application servers

l

Configure WAF URL protection

l

Block clients from specific IP addresses, but allow trusted users

l

Configure a WAF HTTP protocol constraint

l

Block HTTP GET requests from a specific IP address, but allow trusted users

Time to Complete Estimated: 40 minutes

91

FortiADC 6.2 Lab Guide Fortinet Technologies Inc.

DO NOT REPRINT © FORTINET Exercise 1: Configuring FortiADC Firewall Policies In this exercise, you will create a firewall policy on FortiADC-Primary to block a known malicious network from accessing the AppSrv1 and AppSrv2 web servers. You will use the Linux-External VM (100.64.110.100/25) as the bad IP address for the testing.

Configure a FortiADC Address Object You will configure an address object that will identify IP addresses from a specified address range. For the purposes of this exercise, the address range is considered untrusted.

To configure a FortiADC address object 1. Log in to the FortiADC-Primary GUI with the username admin and password password. 2. Click Shared Resources > Address, and then click the Address tab. 3. Click Create New, and then configure the following settings to create a new address:

Field

Value

Name

Bad_100.64.110.128

Type

Address Range

Address Range

100.64.110.128

To

100.64.110.255

4. Click Save.

To test the client access before applying a firewall policy 1. On the Linux-External VM, open a terminal window. 2. Enter the following command to add a secondary IP address to eth0: sudo ifconfig eth0:0 100.64.110.200 netmask 255.255.255.128 up

3. Enter the password password. 4. Verify the eth0:0 interface with the following command, and then press q to quit the output: ifconfig -a | more

5. Enter the following commands to access http://192.158.201.50—repeat the commands a few times: curl --interface 100.64.110.100 http://192.168.201.50 curl --interface 100.64.110.200 http://192.168.201.50

The AppSrv1and AppSrv2 home page HTML code should display successfully for both IP addresses.

Create the Firewall Policy You will create a firewall policy that blocks traffic from a defined IP address range.

FortiADC 6.2 Lab Guide Fortinet Technologies Inc.

92

DO Test NOT REPRINT the Firewall Policy © FORTINET

Exercise 1: Configuring FortiADC Firewall Policies

Take the Expert Challenge! l

Create an IPv4 firewall policy on FortiADC-Primary with the name VS_LAN1.

l

The policy should deny traffic from the Bad_100.64.110.128 IP address on port1 to any destination using all services.

l

Enable status and deny logging on the policy.

If you require assistance, or to verify your work, use the step-by-step instructions that follow. After you complete the challenge, see Test the Firewall Policy on page 93.

To create the firewall policy 1. Return to the FortiADC-Primary GUI, and then click Network Security > Firewall > IPv4 Firewall Policy. 2. Click Create New, and then configure the following settings to create a new firewall policy:

Field

Value

Name

VS_LAN1

Ingress Interface

port1

Source

Bad_100.64.110.128

Destination

Any

Service

ALL

Action

Deny

Status

Enabled

Deny Log

Enabled

3. Click Save.

Test the Firewall Policy You will validate that FortiADC blocks traffic from the designated IP address range.

To test the firewall policy 1. Return to the Linux-External VM terminal window, and then enter the following command to access http://192.158.201.50—repeat the command a few times: curl --interface 100.64.110.100 http://192.168.201.50

The AppSrv1 home page HTML code should display successfully for the trusted client. 2. Enter the following command to access http://192.158.201.50: curl --interface 100.64.110.200 http://192.168.201.50

93

FortiADC 6.2 Lab Guide Fortinet Technologies Inc.

DO Exercise NOT1: Configuring REPRINT FortiADC Firewall Policies © FORTINET

Test the Firewall Policy

There is no response from the AppSrv1 and AppSrv2 servers because the connection is blocked. 3. Press Ctrl+C to exit the command. 4. Close the Linux-External VM browser tab. 5. Return to the FortiADC-Primary GUI, and then click Log & Report > Security Log. 6. In the first drop-down box, select Firewall, and then in the last drop-down box, select all_times. 7. Click the Refresh button. You can see that the traffic from 100.64.110.200 is denied.

To disable the firewall policy 1. Continuing on the FortiADC-Primary GUI, click Network Security > Firewall > IPv4 Firewall Policy. 2. Click the edit icon (

) to edit the VS_LAN1 policy, and then set Status to Disabled.

3. Click Save.

By default, FortiADC allows traffic that doesn’t match any firewall policy because there is an implicit accept policy at the end. You can change this behavior by selecting Deny at the top of the Firewall Policy tab as the Default Action. 4. Log out of the FortiADC-Primary GUI.

FortiADC 6.2 Lab Guide Fortinet Technologies Inc.

94

DO NOT REPRINT © FORTINET Exercise 2: Configuring WAF URL Protection In this exercise, you will configure WAF URL protection to block access to a web server resource.

Configure WAF URL Protection URL protection provides web application protection by detecting specific character string patterns in the URI or the file extension that are considered harmful to the web service. You will create the URL protection policy on FortiADC-Secondary to protect the AppSrv3 resources folder from being accessed by an unauthorized user.

To configure WAF URL protection 1. Log in to the FortiADC-Secondary GUI with the username admin and password password. 2. Click Web Application Firewall > WAF Profile > Exceptions. 3. Click Create New, and then configure the following setting to create a new exception profile:

Field

Value

Name

Allow_100.64.110.0

4. Click Save. 5. Click the edit icon (

) to edit the exception.

6. In the Exception Rule section, click Create New, and then configure the following settings:

Field

Value

Type

Source IP

IPv4/Netmask

100.64.110.0/25

7. Click Save, and then click Save again. 8. Click Web Application Firewall > Access Protection > URL Protection. 9. Click Create New, and then configure the following setting:

Field

Value

Name

Ap3_Resources

10. Click Save. 11. Click the edit icon (

) to edit the URL protection object.

12. In the URL Access Rule section, click Create New, and then configure the following settings:

95

FortiADC 6.2 Lab Guide Fortinet Technologies Inc.

DO Exercise NOT2: Configuring REPRINT WAF URL Protection © FORTINET

Test URL Protection

Field

Value

Full URL Pattern

/resources/

Action

deny

Severity

High

Exception Name

Allow_100.64.110.0

13. Click Save, and then click Save again. 14. Click Web Application Firewall > WAF Profile > WAF Profile. 15. Click Create New, and then configure the following settings to create a profile:

Field

Value

Name

Resources-WAF

URL Protection

Ap3_Resources

16. Click Save.

Test URL Protection You will use a cURL command to issue an HTTP GET request to the AppSrv3 /resource URL using the LinuxExternal VM eth0 primary and secondary IP addresses to observe the URL protection result.

To test the resources home page before applying the URL protection profile 1. On the Linux-External VM, open a terminal window. 2. Enter the following commands to access http://192.168.202.150/resources/: curl --interface 100.64.110.100 http://192.168.202.150/resources/ curl --interface 100.64.110.200 http://192.168.202.150/resources/

The resources home page HTML code is displayed for both IP addresses.

To apply the URL protection profile 1. Return to the FortiADC-Secondary GUI, and then click Server Load Balance > Virtual Server. 2. Click the edit icon (

) to edit HTTP_VS.

3. Click the Security tab, and then in the WAF Profile drop-down box, select Resources-WAF. 4. Click Save.

To test the resources home page after applying the URL protection profile 1. Return to the Linux-External VM, and then in the terminal window, enter the following command to access http://192.158.202.150/resources/: curl --interface 100.64.110.100 http://192.168.202.150/resources/

The resources home page HTML code is displayed. 2. Enter the following commands to test the access—repeat the commands a few times:

FortiADC 6.2 Lab Guide Fortinet Technologies Inc.

96

DO Test NOT REPRINT URL Protection © FORTINET

Exercise 2: Configuring WAF URL Protection

curl --interface 100.64.110.200 http://192.168.202.150 curl --interface 100.64.110.200 http://192.168.202.150/resources/

The access for the first command is successful, but the second command is blocked by the administrative rules. The client from the IP address can access only the main site, but is prohibited from the protected area in the web server. 3. Close the Linux-External VM browser tab.

To check the security log 1. Return to the FortiADC-Secondary GUI, and then click Log & Report > Security Log. 2. In the first drop-down list, select WAF, and then in the second drop-down list, select all_times. 3. Click the Refresh button. Log entries show that the access attempts from 100.64.110.200 to the /resources folder have been denied.

4. Log out of the FortiADC-Secondary GUI.

97

FortiADC 6.2 Lab Guide Fortinet Technologies Inc.

DO NOT REPRINT © FORTINET Exercise 3: Configuring a WAF HTTP Protocol Constraint In this exercise, you will configure a WAF HTTP protocol constraint to prevent web page access from a specified address range.

Configure a WAF HTTP Protocol Constraint You will create a policy on FortiADC-Secondary to protect the AppSrv3 website from being accessed by HTTP GET requests.

To configure a WAF HTTP protocol constraint profile 1. Log in to the FortiADC-Secondary GUI with the username admin and password password. 2. Click Web Application Firewall > Common Attacks Detection > HTTP Protocol Constraint. 3. Click Create New, and then configure the following setting:

Field

Value

Name

Ap3_GET_Protection

4. Review the other configuration options, but keep the default values. 5. Click Save. 6. Click the edit icon (

) to edit Ap3_GET_Protection.

7. In the Request Method Rule pane, click Create New. 8. Configure the following settings:

Field

Value

Method

GET

Action

Deny

Severity

High

Exception Name

Allow_100.64.110.0

9. Click Save, and then click Save again. 10. Click Web Application Firewall > WAF Profile > WAF Profile. 11. Click Create New. 12. Configure the following settings:

Field

Value

Name

Ap3_GET_Constraint

HTTP Protocol Constraint

Ap3_GET_Protection

FortiADC 6.2 Lab Guide Fortinet Technologies Inc.

98

DO Test NOT REPRINT an HTTP Protocol Constraint © FORTINET

Exercise 3: Configuring a WAF HTTP Protocol Constraint

13. Click Save.

Test an HTTP Protocol Constraint You will use cURL commands to access the AppSrv3 main page using the Linux-External VM primary IP address, and then observe the results using the Linux-External VM secondary IP address.

To test an HTTP protocol constraint 1. On the Linux-External VM, open a terminal window. 2. Enter the following commands to access http://192.158.202.150: curl --interface 100.64.110.100 http://192.168.202.150 curl --interface 100.64.110.200 http://192.168.202.150

The resources home page HTML code should be displayed successfully for both IP addresses.

To apply the HTTP protocol constraint profile on the virtual server 1. Return to the FortiADC-Secondary GUI, and then click Server Load Balance > Virtual Server > Virtual Server. 2. Click the edit icon (

) to edit the HTTP_VS virtual server.

3. Click the Security tab. 4. In the WAF Profile drop-down list, select Ap3_GET_Constraint. 5. Click Save.

To test AppSrv3 home page access 1. Return to the Linux-External VM, and then enter the following command to access http://192.158.202.150: curl --interface 100.64.110.100 http://192.168.202.150

The home page HTML code is displayed successfully. 2. Enter the following command using the secondary IP address—repeat the command a few times: curl --interface 100.64.110.200 http://192.168.202.150

The access is now blocked by the administrative rules. 3. Enter the following command using the secondary IP address—repeat the command a few times: curl --interface 100.64.110.200 http://192.168.202.150/resources/

The access is blocked by the administrative rules. The rule disallows GET requests on http://192.168.202.150. It blocks the entire site from HTTP GET requests. 4. Close the Linux-External VM browser tab.

To check security logs 1. Return to the FortiADC-Secondary GUI, and then click Log & Report > Security Log. 2. In the first drop-down list, select WAF, and then in the second drop-down box, select all_times. 3. Click the Refresh button. You can see the log shows that the access from 100.64.110.200 has been denied.

99

FortiADC 6.2 Lab Guide Fortinet Technologies Inc.

DO Exercise NOT3: Configuring REPRINT a WAF HTTP Protocol Constraint © FORTINET

Test an HTTP Protocol Constraint

This exercise blocks only HTTP GET requests. Other HTTP methods, including POST, PUT, and DELETE, are not blocked.

4. Log out of the FortiADC-Secondary GUI.

FortiADC 6.2 Lab Guide Fortinet Technologies Inc.

100

DO NOT REPRINT © FORTINET Lab 7: Scripts and the REST API In this lab, you will configure two FortiADC scripts to perform web page redirection and content routing. You will use Postman, an API freeware program, to practice FortiADC REST API calls to create virtual servers.

Objectives l

Configure a script to redirect user connections based on client IP address

l

Configure a script to perform content routing based on URI

l

Examine the FortiADC REST API, cURL, and the Postman programming tool

l

Examine the GET POST, PUT, and DELETE methods that the REST API uses

l

Configure server load balancing using API calls

Time to Complete Estimated: 40 minutes

101

FortiADC 6.2 Lab Guide Fortinet Technologies Inc.

DO NOT REPRINT © FORTINET Exercise 1: Configuring FortiADC Scripts In this exercise, you will configure a virtual server to leverage scripting. One script redirects a user connection based on the client IP address, and a second script performs content routing. This script example is a good example of how to filter trusted and untrusted connections.

Configure a Web Redirect Script You will create a script that redirects clients with IP addresses from a defined range to AppSrv3. You will use the FortiADC diagnose command to enable and examine debug messages.

To configure a web redirect script 1. On the Linux-Internal VM, open a browser, and then log in to the FortiADC-Primary GUI with the username admin and password password. 2. Click Server Load Balance > Scripting. The page shows various predefined script templates that are tailored for different tasks. 3. Click Create New. 4. In the Name field, type 01_WEB_REDIRECT. 5. In the text box, add the following code snippet: -- This simple script checks the incoming client IP address -- If the client is from the 100.64.110.0 network, the script will redirect the client to sinkhole folder -- Otherwise it will grant the client connection to the virtual server when HTTP_REQUEST{ client_ip=HTTP:client_addr() debug("Client IP is %s\n", client_ip) if client_ip:find("100.64.110") then debug("Client has been redirected to the sinkhole page on the AppSrv3 because of IP address") HTTP:redirect("http://192.168.202.150/sinkhole/") end }

You can copy and paste the code snippet from the Lab7-Ex1-CodeSnippets.txt file, which is located in the Resources/Lab 7/ folder on the Linux-Internal desktop.

Your configuration should match the following example:

FortiADC 6.2 Lab Guide Fortinet Technologies Inc.

102

DO Apply NOT REPRINT the Script to the Virtual Server © FORTINET

Exercise 1: Configuring FortiADC Scripts

6. Click Save.

Apply the Script to the Virtual Server You will configure a virtual server to use the script.

Take the Expert Challenge! On the FortiADC-Primary VM, configure the HTTP_VS virtual server to use the 01_WEB_REDIRECT script. If you require assistance, or to verify your work, use the step-by-step instructions that follow. After you complete the challenge, see Configure a Content Routing Script on page 104.

To apply the script on the virtual server 1. Continuing on the FortiADC-Primary GUI, click Server Load Balance > Virtual Server. 2. Click the edit icon (

) to edit the HTTP_VS virtual server.

3. In the General tab, enable Scripting. 4. In Scripting List Available Items, double-click 01_WEB_REDIRECT to add the script to the Selected Items panel. 5. Click Save.

Test the Web Redirect Script You will validate the script functions as expected, and then remove the script from the virtual server.

To test the script 1. Open an SSH session to the FortiADC-Primary GUI. 2. Enter the following commands to enable script debugging: diagnose debug enable diagnose debug module httproxy scripting set

3. On the Linux-External VM, open a browser, and then connect to the virtual server URL at http://192.168.201.50.

103

FortiADC 6.2 Lab Guide Fortinet Technologies Inc.

DO Exercise NOT1: Configuring REPRINT FortiADC Scripts © FORTINET

Configure a Content Routing Script

The server redirects the connection to the http://192.168.202.150/sinkhole/ home page. 4. Return to the FortiADC-Primary SSH session, and then observe the debug messages. Adding debug messages in the code facilitates troubleshooting and prints out the real-time information. 5. Enter the following command to disable debugging: diagnose debug disable

To remove the script from the virtual server 1. Return to the FortiADC-Primary GUI, and then click Server Load Balance > Virtual Server. 2. Click the edit icon (

) to edit the HTTP_VS virtual server.

3. In the General tab, disable Scripting. 4. Click Save.

Configure a Content Routing Script You will create a script that performs content routing based on the user entered URI and forwards the user to a specific web page. This example is useful for managing multiple web resources that the virtual server services.

To create a content routing script 1. Continuing on the FortiADC-Primary GUI, click Server Load Balance > Scripting. 2. Click Create New. 3. In the Name field, type 02_CONTENT_ROUTING. 4. In the text box, add the following code snippet: -- This simple script checks user request URI and forwards user to different web pages -- when condition matches "finance" or "marketing" then use system LB content routing function for the content routing object to a team's web page. -- If URI is "accounting" or "sales", redirect user to the corresponding department. -- if only virtual server IP address is entered, displays AppSrv default home page. -- if user enters invalid URI then forward user to an site error. -- Administrator can easily manage multiple URIs with one virtual server. when HTTP_REQUEST { uri = HTTP:uri_get() debug ("uri is %s\n", uri) if uri:find("finance") then LB:routing("Finance") debug("uri %s matches Finance \n", uri) elseif uri:find("accounting") then HTTP:redirect("http://192.168.201.50/finance/") elseif uri:find("marketing") then LB:routing("Marketing") debug("uri %s matches Marketing\n", uri) elseif uri:find("sales") then HTTP:redirect("http://192.168.201.50/marketing/") elseif (uri == "/") then debug("goto default home page"); else HTTP:redirect("http://192.168.202.150/sinkhole") debug("invalid uri: %s \n", uri);

FortiADC 6.2 Lab Guide Fortinet Technologies Inc.

104

DO Create NOT REPRINT Content Routes © FORTINET

Exercise 1: Configuring FortiADC Scripts

end }

You can copy and paste the code snippet from the Lab7-Ex1-CodeSnippets.txt file, which is located in the Resources/Lab 7/ folder on the Linux-Internal desktop.

Your configuration should look similar to the following example:

5. Click Save.

Create Content Routes You will create content routes to the Ap_3 real server pool.

Take the Expert Challenge! On the FortiADC-Primary VM, create two content routing configurations with the following settings: l

Name one Finance and the other Marketing

l

Both will be Layer 7

l

Both will direct traffic to the Ap_3 real server pool

l

Both will inherit Persistence and Method from the virtual server

Finally, configure the HTTP_VS virtual server to use the 02_Content_Routing script to direct traffic to the two content routes. If you require assistance, or to verify your work, use the step-by-step instructions that follow. After you complete the challenge, see Test the Content Routing Script on page 107.

105

FortiADC 6.2 Lab Guide Fortinet Technologies Inc.

DO Exercise NOT1: Configuring REPRINT FortiADC Scripts © FORTINET

Create Content Routes

To create content routes 1. Continuing on the FortiADC-Primary GUI, click Server Load Balance > Virtual Server > Content Routing. 2. Click Create New, and then configure the following settings:

Field

Value

Name

Finance

Type

Layer 7

Real Server Pool

Ap_3

Persistence

Inherit

Method

Inherit

3. Click Save. 4. Click Create New, and then configure the following settings:

Field

Value

Name

Marketing

Type

Layer 7

Real Server Pool

Ap_3

Persistence

Inherit

Method

Inherit

5. Click Save.

You don't need to add a match condition for each rule when using a script for content routing, because the match condition is defined in the script.

To select and enable content routes on the virtual server 1. Continuing on the FortiADC-Primary GUI, click Server Load Balance > Virtual Server > Virtual Server. 2. Click the edit icon (

) to edit the HTTP_VS virtual server.

3. In the Specifics pane, enable Content Routing. 4. In the Content Routing List section, remove any content routes from the Selected Items pane, and then add Finance and Marketing to the Selected Items pane.

FortiADC 6.2 Lab Guide Fortinet Technologies Inc.

106

DO Test NOT REPRINT the Content Routing Script © FORTINET

Exercise 1: Configuring FortiADC Scripts

5. In the General tab, enable Scripting. 6. Remove the 01_WEB_REDIRECT script from the Selected Items pane. 7. In the Scripting List section, in the Available Items pane, double-click 02_CONTENT_ROUTING to add the script to the Selected Items list. 8. Click Save.

Test the Content Routing Script You will validate that the script routes content as expected.

To test the content routing script 1. Open an SSH session to the FortiADC-Primary VM. 2. Enter the following commands to enable script debugging: diagnose debug enable diagnose debug module httproxy scripting set

3. Return to the Linux-External VM, open a browser, test the following URLs, and then check the returned web page for each URL: l

http://192.168.201.50/finance

l

http://192.168.201.50/accounting

l

http://192.168.201.50/marketing

l

http://192.168.201.50/sales

l

http://192.168.201.50/invalid

l

http://192.168.201.50

The virtual server displays the web page correctly for each URL. 4. Close the Linux-External VM browser tab. 5. Return to the FortiADC-Primary SSH session, and then observe the debug messages. 6. Enter the following command to disable debugging: diagnose debug disable

7. Close the FortiADC-Primary SSH session browser tab.

To disable scripting on the virtual server 1. Return to the FortiADC-Primary GUI, and then click Server Load Balance > Virtual Server. 2. Click the edit icon (

) to edit the HTTP_VS virtual server.

3. In the Basic tab, disable Content Routing.

107

FortiADC 6.2 Lab Guide Fortinet Technologies Inc.

DO Exercise NOT1: Configuring REPRINT FortiADC Scripts © FORTINET

Test the Content Routing Script

4. On the General tab, disable Scripting. 5. Click Save. A script is triggered when the associated virtual server receives an HTTP request or response. You can customize many control features using FortiADC scripting. For more advanced topics and script features, see the FortiADC Handbook.

6. Log out of the FortiAC-Primary GUI.

FortiADC 6.2 Lab Guide Fortinet Technologies Inc.

108

DO NOT REPRINT © FORTINET Exercise 2: Configuring the FortiADC REST API In this exercise, you will perform FortiADC administrative configurations using the FortiADC REST API. You will use a cURL command and Postman (a freeware API tool) to complete this exercise. Refer to the FortiADC REST API Reference for detailed information about API syntax.

Request a Bearer Token for API Authentication When you use the API to run a task on FortiADC, you must pass the bearer token that FortiADC issues as authentication. In this part of the exercise, you will use the API to request a token, retrieve system information, and then familiarize yourself with the cURL and Postman tools.

To request a bearer token using cURL 1. On the Linux-Internal VM, open a terminal window. 2. Enter the following cURL command: curl -H "Content-type:application/json" -H "Accept:application/json" -X POST -d ' {"username":"admin","password":"password"}' -k -i https://10.0.1.15/api/user/login

The cURL command calls the FortiADC /api/user/login API using the POST method. You can copy and paste the cURL command from the Lab7-Ex2curlCommands.txt file, which is located in the Resources/Lab 7/ folder on the Linux-Internal desktop.

FortiADC returns an HTTP/1.1 200 OK message. Note that the bearer token is included in the reply. You can use the token for subsequent API calls. The bearer token is issued with an expiration time. You can use the command at any time to get a new token, and then use it for the API calls, even before the current token expires.

Using cURL is not a convenient way to work with the API. cURL commands can be long, and therefore prone to errors. Postman is a GUI-based API programming tool that simplifies working with the API.

109

FortiADC 6.2 Lab Guide Fortinet Technologies Inc.

DO Exercise NOT2: Configuring REPRINT the FortiADC REST API © FORTINET

Making API Calls Using Postman

Making API Calls Using Postman You will use Postman, which is a third-party application with a GUI interface, to test various API calls to FortiADC.

To request a bearer token using Postman 1. Continuing on the Linux-Internal VM, open the Postman application located on the desktop. By default, the Collections tab is selected, and the screen displays the Scratch Pad.

2. Review the preconfigured API calls that you will use in this exercise. 3. In the Collections pane, expand /root/Desktop/Resources/restapi. 4. Click Request_Token. 5. Verify that your configuration matches the following example:

Postman will use a POST method for the https://10.0.1.15/api/user/login API call. 6. Click Headers. 7. Review the KEY and VALUE parameters for the Content-Type and Accept HTTP header parameters.

FortiADC 6.2 Lab Guide Fortinet Technologies Inc.

110

DO Making NOT API REPRINT Calls Using Postman © FORTINET

Exercise 2: Configuring the FortiADC REST API

Depending on the size of the Postman window, access to the API components is either a drop-down list or a horizontal list.

8. Click Body to review the raw data format of the FortiADC admin username and password.

The data is a JSON object. 9. Click Send. The header and body are sent to FortiADC.

The response from FortiADC appears in the text area on the right.

111

FortiADC 6.2 Lab Guide Fortinet Technologies Inc.

DO Exercise NOT2: Configuring REPRINT the FortiADC REST API © FORTINET

Configure Server Load Balancing

To retrieve FortiADC system information using GET 1. Continuing on the Postman Collections pane, click Get_FortiADC_Info to load that API call. 2. Return to the Request_Token API tab. 3. Highlight the token text string inside the double quotation marks, and then copy the token (Ctrl+C)—do not copy the double quotation marks. 4. Return to the Get_FortiADC_Info tab, click Auth, and then validate that Type is set to Bearer Token. 5. Replace the existing Token string with the token you copied.

6. Click Send. The response shows FortiADC information, including the host name, time, serial number, and firmware version.

Configure Server Load Balancing You will use four APIs to create a server load balancing solution.

To create a real server using POST 1. Continuing on the Postman Collections pane, click Create_Real_Server to load the API call. 2. Click Body, and then between the double quotation marks for the real server settings in the JSON object, add the following values:

Field

Value

status

enable

address

10.200.1.10

mkey

AppSrv4

Your configuration should match the following example:

FortiADC 6.2 Lab Guide Fortinet Technologies Inc.

112

DO Configure NOTServer REPRINT Load Balancing © FORTINET

Exercise 2: Configuring the FortiADC REST API

3. Return to the Request_Token API tab. 4. Highlight the token text string inside the double quotation marks, and then copy the token (Ctrl+C)—do not copy the double quotation marks. 5. Return to the Create_Real_Server tab, select Auth, and then verify Type is set to Bearer Token. 6. Replace the existing Token string with the token you copied. 7. Click Send. FortiADC replies with a 200 OK status and "payload" : 0 as shown in the following example:

If FortiADC returns a payload value that is not 0, an error occurred during API execution. Try to use a new token, and check to ensure the required parameters are entered in the header and JSON body correctly. 8. Click Body, and then update the following values for the real server in the JSON object to create the second real server:

Field

Value

status

enable

address

10.200.1.20

mkey

AppSrv5

9. Click Send.

To verify the real server creation 1. Log in to the FortiADC-Primary GUI with the username admin and password password. 2. Click Server Load Balance > Real Server Pool > Real Server.

113

FortiADC 6.2 Lab Guide Fortinet Technologies Inc.

DO Exercise NOT2: Configuring REPRINT the FortiADC REST API © FORTINET

Configure Server Load Balancing

3. Verify AppSrv4 and AppSrv5 are created. 4. Click Log & Report > Event Log. 5. In the first drop-down list, select Configuration, and then select all_times. 6. Click the Refresh button. The logs for the configuration change appear. 7. Click the icon in the last column to see the details.

For a large deployment, you can write a script, such as a Python script, to loop through the API call with different variable values.

To create a real server pool using POST 1. Return to the Linux-Internal VM, and then on the Postman Collections pane, click Create_Real_Server_Pool to load the API call. 2. Click Body, and then add the following values for the real server pool in the JSON object:

Field

Value

pool_type

ipv4

health_check

enable

health_check_relationship

AND

mkey

APIRSPool

health_check_list

LB_HLTHCK_HTTP

rs_profile

NONE

3. Return to the Request_Token API tab. 4. Highlight the token text string inside the double quotation marks, and then copy the token (Ctrl+C)—do not copy the double quotation marks. 5. Return to the Create_Real_Server_Pool tab, and then select Auth. 6. Replace the existing Token with the one you copied. 7. Click Send. FortiADC returns a 200 OK status.

FortiADC 6.2 Lab Guide Fortinet Technologies Inc.

114

DO Configure NOTServer REPRINT Load Balancing © FORTINET

Exercise 2: Configuring the FortiADC REST API

8. Return to the FortiADC-Primary GUI, and then click Server Load Balance > Real Server Pool. 9. Verify that the APIRSPool is created successfully.

To add real servers to the real server pool using POST 1. Return to the Linux-Internal VM, and then on the Postman Collections pane, click Add_Real_Server_To_Pool to load the API call.

Note that the API requires a command line parameter, pkey, to specify a parent object for the members. 2. Click Body, and then add the following values for the real server pool member in the JSON object:

Field

Value

health_check_inherit

enable

m_health_check

disable

port

80

status

enable

ssl

disable

real_server_id

AppSrv4

Do not change any other entries. 3. Return to the Request_Token API tab. 4. Highlight the token text string inside the double quotation marks, and then copy the token (Ctrl+C)—do not copy the double quotation marks. 5. Return to the Add_Real_Server_To_Pool tab. 6. Click Auth, and then verify Type is set to Bearer Token. 7. Replace the existing Token with the one you copied. 8. Click Send. 9. Return to the Add_Real_Server_To_Pool tab, and then click Body. 10. Change real_server_id from AppSrv4 to AppSrv5. 11. Click Send. 12. Return to the FortiADC-Primary GUI, and then click Server Load Balance > Real Server Pool > Real Server Pool. 13. Select APIRSPool, and then click the edit icon (

).

14. Verify that the AppSrv4 and AppSrv5 entries are in the Member table.

To create a virtual server using POST 1. Return to the Linux-Internal VM, and then on the Postman Collections pane, click Create_Virtual_Server to load the API call.

115

FortiADC 6.2 Lab Guide Fortinet Technologies Inc.

DO Exercise NOT2: Configuring REPRINT the FortiADC REST API © FORTINET

Configure Server Load Balancing

2. Click Body, and then update the JSON object with the following settings:

Field

Value

mkey

API-VS

status

enable

type

l7-load-balance

address

10.0.1.70

public-ip

192.168.201.70

port

80

interface

port1

pool

APIRSPool

3. Return to the Request_Token API tab. 4. Highlight the token text string inside the double quotation marks, and then copy the token (Ctrl+C)—do not copy the double quotation marks. 5. Return to the Add_Real_Server_To_Pool tab, and then click Auth. 6. Replace the existing Token with the one you copied. 7. Click Send.

To update a virtual server using PUT 1. Continuing on the Postman Collections pane, click Update_Virtual_Server to load the API call.

Note that when the virtual server was created, the Traffic Log and FortiView settings were not enabled. You will enable both settings using the same API call and an mkey parameter with the PUT method.

2. Click Body, and then add the following values for the virtual server in the JSON object:

Field

Value

mkey

API-VS

traffic-log

enable

fortiview

enable

3. Return to the Request_Token API tab. 4. Highlight the token text string inside the double quotation marks, and then copy the token (Ctrl+C)—do not copy the double quotation marks. 5. Return to the Update_Virtual_Server tab, and then click Auth. 6. Replace the existing Token with the one you copied.

FortiADC 6.2 Lab Guide Fortinet Technologies Inc.

116

DO Validate NOTtheREPRINT Virtual Server Settings © FORTINET

Exercise 2: Configuring the FortiADC REST API

7. Click Send. 8. Close the Linux-Internal VM browser tab.

Validate the Virtual Server Settings You will log in to the FortiADC-Primary VM and validate the configurations performed using the API. Then, you will test the virtual server.

Take the Expert Challenge! Validate the virtual server settings on FortiADC-Primary. l

Validate each of the following virtual server settings configured using the API: l

Type

l

Status

l

Address

l

Port

l

Interface

l

Public IPv4

l

Validate the virtual server update using the API to enable Traffic Log and FortiView.

l

Test the virtual server from the Linux-External VM.

If you require assistance, or to verify your work, use the step-by-step instructions that follow.

To validate the virtual server settings 1. On the FortiADC-Primary GUI, click Server Load Balance > Virtual Server. 2. Click the edit icon (

) to edit the API-VS.

3. On the Basic tab, verify the following settings:

Field

Value

Type

Layer 7

Status

Enable

4. On the General tab, verify the following settings:

117

Field

Value

Address

10.0.1.70

Port

80

Interface

Port1

Public IPv4

192.168.201.70

FortiADC 6.2 Lab Guide Fortinet Technologies Inc.

DO Exercise NOT2: Configuring REPRINT the FortiADC REST API © FORTINET

Validate the Virtual Server Settings

5. On the Monitoring tab, verify that Traffic Log and FortiView are enabled. 6. Log out of the FortiADC-Primary GUI.

To test the virtual server 1. On the Linux-External VM, open a browser, and then access the newly created virtual server http://192.168.201.70. The traffic is routed to two AppSrv servers. There are several Python script examples created for this exercise. The file is located in the Linux-Internal VM /root/Desktop/Resources/restapi directory. You can use the cat or vi commands to see how the API is used in the Python scripts.

2. Close the Linux-External VM browser tab.

FortiADC 6.2 Lab Guide Fortinet Technologies Inc.

118

DO NOT REPRINT © FORTINET Lab 8: Troubleshooting In this lab, you will troubleshoot a web server access issue.

Objectives l

Examine the server access issue

l

Diagnose the server access issue

l

Repair the server access

Time to Complete Estimated: 20 minutes

Prerequisites Before beginning this lab, you must restore a configuration file to FortiADC-Primary.

To restore the FortiADC-Primary configuration file 1. On the Linux-Internal VM, open a browser, and then log in to the FortiADC-Primary GUI with the username admin and password password. 2. Click System > Settings, and then select the Backup&Restore tab. 3. Set Mode to Restore, and then set Storage to Local PC/Server. 4. Click Choose File. 5. Navigate to /root/Desktop/Resources/Lab 8, and then select Lab-8_Init.zip. 6. Click the upload icon.

7. Close the Linux-Internal VM tab.

119

FortiADC 6.2 Lab Guide Fortinet Technologies Inc.

DO NOT REPRINT © FORTINET Exercise 1: Troubleshooting Web Server Access In this exercise, you will examine a web server access issue, and then use the CLI diagnose sniffer tool to identify the problem. Finally, you will resolve the issue and validate the results. The current configuration should route all traffic attempting to access the resources page to AppSrv3 (10.200.1.210).

Observe the Web Server Access Issue You will attempt to access web pages from the Linux-External client and observe a page load error.

To observe the web server access issue 1. On the Linux-External VM, open a browser, and then connect to the URL http://192.168.201.50. 2. Press Ctrl+Shift+R to refresh the browser page several times. Notice that refreshing the main page changes the back-end server. The traffic should be load balanced between the three application servers. 3. Open another browser tab, and then connect to the URL http://192.168.201.50/resources/. 4. Press Ctrl+Shift+R to refresh the browser page several times. A request URL not found error appears.

FortiADC 6.2 Lab Guide Fortinet Technologies Inc.

120

DO Inspect NOT REPRINT the External Traffic Flow © FORTINET

Exercise 1: Troubleshooting Web Server Access

Inspect the External Traffic Flow You will use the CLI diagnose sniffer tool to view HTTP communication between FortiADC-Primary and the LinuxExternal VM.

To inspect the external traffic flow 1. Open an SSH session to the FortiADC-Primary VM. 2. Enter the following sniffer command: diagnose sniffer packet port1 "port 80" 4

3. Return to the Linux-External VM, and then refresh the browser tab that is accessing http://192.168.201.50 and the tab that is accessing http://192.168.201.50/resources/. 4. Return to the FortiADC-Primary SSH session, and then observe the traffic flow between the Linux-External VM (100.64.110.100) and the virtual server (10.0.1.50).

The communication that appears in the sniffer trace is expected. 5. Press Ctrl+C to stop the sniffer.

Inspect the Internal Traffic Flow You will use the CLI diagnose sniffer tool to view HTTP communication between FortiADC-Primary and the real servers.

Take the Expert Challenge! Use the CLI sniffer to inspect the traffic flow between FortiADC-Primary and the application servers. Identify the problem causing the resource page failure. If you require assistance, or to verify your work, use the step-by-step instructions that follow. After you complete the challenge, see Resolve the Configuration Error on page 122.

121

FortiADC 6.2 Lab Guide Fortinet Technologies Inc.

DO Exercise NOT1: Troubleshooting REPRINT Web Server Access © FORTINET

Resolve the Configuration Error

To inspect the internal traffic flow 1. Continuing on the FortiADC-Primary SSH session, enter the following sniffer command: diagnose sniffer packet port2 "port 80" 4

2. Return to the Linux-External VM, and then refresh the browser tab that is accessing http://192.168.201.50/resources/ several times. 3. Return to the FortiADC-Primary SSH session, and then observe the traffic flow between FortiADC-Primary and the real servers. FortiADC-Primary is forwarding the traffic to AppSrv2 (10.200.1.20). The resource page only exists on AppSrv3 (10.200.1.210). 4. Press Ctrl+C to stop the sniffer.

Resolve the Configuration Error You will modify the FortiADC-Primary configuration and resolve the resource page load error.

Take the Expert Challenge! Based on the investigation you have done, modify the FortiADC-Primary configuration to resolve the resources page loading issue. If you require assistance, or to verify your work, use the step-by-step instructions that follow. After you complete the challenge, see Validate the Resolution on page 122.

To resolve the configuration error 1. Log in to the FortiADC-Primary GUI with the username admin and password password. 2. Click Server Load Balance > Virtual Server. 3. Click the Content Routing tab, select the ResourceRoute entry, and then click the edit icon ( Note that the Real Server Pool is Ap_3. This is correct for this content route.

).

4. Click Virtual Server > Real Server Pool. 5. Select the Ap_3 entry, and then click the edit icon ( ). The only member of the Ap_3 real server pool is AppSrv2. This is not correct—only AppSrv3 has the resources page. 6. Edit the AppSrv2 real server pool member. 7. Change the Real Server to AppSrv3, and then click Save. 8. Click Save. 9. Log out of the FortiADC-Primary GUI.

Validate the Resolution You will validate that the resources page is now accessible and that traffic is being routed to the correct real server.

FortiADC 6.2 Lab Guide Fortinet Technologies Inc.

122

DO Validate NOTtheREPRINT Resolution © FORTINET

Exercise 1: Troubleshooting Web Server Access

To validate the resolution 1. Return to the FortiADC-Primary SSH session, and then enter the following sniffer command: diagnose sniffer packet port2 "port 80" 4

2. Return to the Linux-External VM, and then refresh the browser tab that is accessing http://192.168.201.50/resources/ several times. The resources page loads correctly. 3. Close the Linux-External VM browser tab. 4. Return to the FortiADC-Primary SSH session, and then observe the traffic flow between FortiADC-Primary and the real server. FortiADC-Primary is now forwarding the traffic to AppSrv3 (10.200.1.210). 5. Press Ctrl+C to stop the sniffer. 6. Close the FortiADC-Primary SSH session browser tab.

123

FortiADC 6.2 Lab Guide Fortinet Technologies Inc.

DO NOT REPRINT © FORTINET

No part of this publication may be reproduced in any form or by any means or used to make any derivative such as translation, transformation, or adaptation without permission from Fortinet Inc., as stipulated by the United States Copyright Act of 1976. Copyright© 2021 Fortinet, Inc. All rights reserved. Fortinet®, FortiGate®, FortiCare® and FortiGuard®, and certain other marks are registered trademarks of Fortinet, Inc., in the U.S. and other jurisdictions, and other Fortinet names herein may also be registered and/or common law trademarks of Fortinet. All other product or company names may be trademarks of their respective owners. Performance and other metrics contained herein were attained in internal lab tests under ideal conditions, and actual performance and other results may vary. Network variables, different network environments and other conditions may affect performance results. Nothing herein represents any binding commitment by Fortinet, and Fortinet disclaims all warranties, whether express or implied, except to the extent Fortinet enters a binding written contract, signed by Fortinet’s General Counsel, with a purchaser that expressly warrants that the identified product will perform according to certain expressly-identified performance metrics and, in such event, only the specific performance metrics expressly identified in such binding written contract shall be binding on Fortinet. For absolute clarity, any such warranty will be limited to performance in the same ideal conditions as in Fortinet’s internal lab tests. In no event does Fortinet make any commitment related to future deliverables, features, or development, and circumstances may change such that any forward-looking statements herein are not accurate. Fortinet disclaims in full any covenants, representations,and guarantees pursuant hereto, whether express or implied. Fortinet reserves the right to change, modify, transfer, or otherwise revise this publication without notice, and the most current version of the publication shall be applicable.