FortiOS features available for logging

FortiOS features available for logging

Logs record FortiGate activity, providing detailed information about what is happening on your network. This recorded activity is found in log files, which are stored on a log device. However, logging FortiGate activity requires configuring certain settings so that the FortiGate unit can record the activity. These settings are often referred to as log settings, and are found in most security profiles, but also in Log & Report > Log Config > Log Settings.

Log settings provide the information that the FortiGate unit needs so that it knows what activities to record. This topic explains what activity each log file records, as well as additional information about the log file, which will help you determine what FortiGate activity the FortiGate unit should record.

 

Traffic

Traffic logs record the traffic that is flowing through your FortiGate unit. Since traffic needs firewall policies to properly flow through the unit, this type of logging is also referred to as firewall policy logging. Firewall policies control all traffic that attempts to pass through the FortiGate unit, between FortiGate interfaces, zones and VLAN sub-interfaces.

Logging traffic works in the following way:

  • firewall policy has logging enabled on it (Log Allowed Traffic)
  • packet comes into an inbound interface
  • a possible log packet is sent regarding a match in the firewall policy, such as a URL filter
  • traffic log packet is sent, per firewall policy
  • packet passes and is sent out an interface

 

Traffic log messages are stored in the traffic log file. Traffic logs can be stored any log device, even system memory.

All security profile-related logs are now tracked within the Traffic logs, as of FortiOS 5.0, so all forward traffic can be searched in one place, such as if you are looking to see all activity from a particular address, security feature or traffic. Security profile logs are still tracked separately in the Security Log section, which only appears when logs exist.

If you have enabled and configured WAN Optimization, you can enable logging of this activity in the CLI using the config wanopt setting command. These logs contain information about WAN Optimization activity and are found in the traffic log file. When configuring logging of this activity, you must also enable logging within the security policy itself, so that the activity is properly recorded.

 

Sniffer

The Sniffer log records all traffic that passes through a particular interface that has been configured to act as a One-Armed Sniffer, so it can be examined separately from the rest of the Traffic logs.

 

Other Traffic

The traffic log also records interface traffic logging, which is referred to as Other Traffic. Other Traffic is enabled only in the CLI. When enabled, the FortiGate unit records traffic activity on interfaces as well as firewall policies. Logging Other Traffic puts a significant system load on the FortiGate unit and should be used only when necessary.

Logging other traffic works in the following way:

  • firewall policy has logging enabled on it (Log Allowed Traffic) and other-traffic
  • packet comes into an interface
  • interface log packet is sent to the traffic log that is enabled on that particular interface
  • possible log packet is sent regarding a match in the firewall policy, such as URL filter
  • interface log packet is sent to the traffic log if enabled on that particular interface
  • packet passes and is sent out an interface
  • interface log packet is sent to traffic (if enabled) on that particular interface

 

Event

The event log records administration management as well as FortiGate system activity, such as when a configuration has changed, admin login, or high availability (HA) events occur. Event logs are an important log file to record because they record FortiGate system activity, which provides valuable information about how your FortiGate unit is performing.

 

Event logs help you in the following ways:

  • keeping track of configuration setting changes
  • IPsec negotiation, SSL VPN and tunnel activity
  • quarantine events, such as banned users
  • system performance
  • HA events and alerts
  • firewall authentication events
  • wireless events on models with WiFi capabilities
  • activities concerning modem and internet protocols L2TP, PPP and PPPoE
  • VIP activities
  • AMC disk’s bypass mode
  • VoIP activities that include SIP and SCCP protocols.

The FortiGate unit records event logs only when events are enabled.

 

Traffic Shaping

Traffic shaping, per-IP traffic shaping and reverse direction traffic shaping settings can be applied to a firewall policy, appearing within the traffic log messages.

By enabling this feature, you can see what traffic shaping, per-IP traffic shaping and reverse direction traffic shaping settings are being used.

 

Data Leak Prevention

Data Leak Prevention logs, or DLP logs, provide valuable information about the sensitive data trying to get through to your network as well as any unwanted data trying to get into your network. The DLP rules within a DLP sensor can log the following traffic types:

  • email (SMTP, POP3 or IMAP; if SSL content SMTPS, POP3S, and IMAPS)
  • HTTP
  • HTTPS
  • FTP
  • NNTP
  • IM

A DLP sensor must have log settings enabled for each DLP rule and compound rule, as well as applied to a firewall policy so that the FortiGate unit records this type of activity. A DLP sensor can also contain archiving options, which these logs are then archived to the log device.

 

NAC Quarantine

Within the DLP sensor, there is an option for enabling NAC Quarantine. The NAC Quarantine option allows the FortiGate unit to record details of DLP operation that involve the ban and quarantine actions, and sends these to the event log file. The NAC Quarantine option must also be enabled within the Event Log settings. When enabling NAC quarantine within a DLP Sensor, you must enable this in the CLI because it is a CLI-only command.

 

Media Access Control (MAC) Address

MAC address logs provide information about MAC addresses that the FortiGate unit sees on the network as well as those removed from the network. These log messages are stored in the event log (as subtype network; you can view these log messages in Log & Report > Event Log) and are, by default, disabled in the CLI. You can enable logging MAC addresses using the following command syntax:

config log setting

set neighbor-event enable end

When enabled, a new log message is recorded every time a MAC address entry is added to the ARP table, and also when a MAC address is removed as well. A MAC address log message is also recorded when MAC addresses are connected to the local switch, or from a FortiAP or FortiSwitch unit.

 

Application control

Application control logs provide detailed information about the traffic that internet applications such as Skype are generating. The application control feature controls the flow of traffic from a specific application, and the FortiGate unit examines this traffic for signatures that the application generates.

The log messages that are recorded provide information such as the type of application being used (such as P2P software), and what type of action the FortiGate unit took. These log messages can also help you to determine the top ten applications that are being used on your network. This feature is called application control monitoring and you can view the information from a widget on the Executive Summary page.

The application control list that is used must have logging enabled within the list, as well as logging enabled within each application entry. Each application entry can also have packet logging enabled. Packet logging for application control records the packet when an application type is identified, similar to IPS packet logging.

Logging of application control activity can only be recorded when an application control list is applied to a firewall policy, regardless of whether or not logging is enabled within the application control list.

 

Antivirus

Antivirus logs are recorded when, during the antivirus scanning process, the FortiGate unit finds a match within the antivirus profile, which includes the presence of a virus or grayware signature. Antivirus logs provide a way to understand what viruses are trying to get in, as well as additional information about the virus itself, without having to go to the FortiGuard Center and do a search for the detected virus. The link is provided within the log message itself.

 

These logs provide valuable information such as:

  • the name of the detected virus
  • the name of the oversized file or infected file
  • the action the FortiGate unit took, for example, a file was blocked
  • URL link to the FortiGuard Center which gives detailed information about the virus itself

The antivirus profile must have log settings enabled within it so that the FortiGate unit can record this activity, as well as having the antivirus profile applied to a firewall policy.

 

Web Filter

Web filter logs record HTTP traffic activity. These log messages provide valuable and detailed information about this particular traffic activity on your network. Web filtering activity is important to log because it can inform you about:

  • what types of web sites employees are accessing
  • users attempting to access banned web sites and how often this occurs
  • network congestion due to employees accessing the Internet at the same time
  • web-based threats resulting from users visiting non-business-related web sites

Web Filter logs are an effective tool to help you determine if you need to update your web filtering settings within a web filter profile due to unforeseen threats or network congestion. These logs also inform you about web filtering quotas that have been configured for filtering HTTP traffic.

You must configure logging settings within the web filter profile and apply the filter to a firewall policy so that the FortiGate unit can record the activity.

 

IPS (attack)

 

IPS logs, also referred to as attack logs, record attacks that occurred against your network. Attack logs contain detailed information about whether the FortiGate unit protected the network using anomaly-based defense settings or signature-based defense settings, as well as what the attack was.

The IPS or attack log file is especially useful because the log messages that are recorded contain a link to the FortiGuard Center, where you can find more information about the attack. This is similar to antivirus logs, where a link to the FortiGuard Center is provided as well that informs you of the virus that was detected by the FortiGate unit.

An IPS sensor with log settings enabled must be applied to a firewall policy so that the FortiGate unit can record the activity.

 

Packet logs

When you enable packet logging within an IPS signature override or filter, the FortiGate unit examines network packets, and if a match is found, saves them to the attack log. Packet logging is designed to be used as a diagnostic tool that can focus on a narrow scope of diagnostics, rather than a log that informs you of what is occurring on your network.

You should use caution when enabling packet logging, especially within IPS filters. Filter configuration that contains thousands of signatures could potentially cause a flood of saved packets, which would take up a lot of storage space on the log device. It would also take a great deal of time to sort through all the log messages, as well as consume considerable system resources to process.

You can archive packets, but you must enable this option on the Log Settings page. If your log configuration includes multiple FortiAnalyzer units, packet logs are only sent to the primary (first) FortiAnalyzer unit. Sending packet logs to the other FortiAnalyzer units is not supported.

 

Email filter

Email filter logs, also referred to as spam filter logs, records information regarding the content within email messages. For example, within an email filter profile, a match is found that finds the email message to be considered spam.

Email filter logs are recorded when the FortiGate unit finds a match within the email filter profile and logging settings are enabled within the profile.

 

Archives (DLP)

Recording DLP logs for network use is called DLP archiving. The DLP engine examines email, FTP, IM, NNTP, and web traffic. Archived logs are usually saved for historical use and can be accessed at any time. IPS packet logs can also be archived, within the Log Settings page.

You can start with the two default DLP sensors that have been configured specifically for archiving log data, Content_Archive and Content_Summary. They are available in Security Profiles > Data Leak Prevention. Content_Archive provides full content archiving, while Content_Summary provides summary archiving. For more information about how to configure DLP sensors, see the Security Features chapter of the FortiOS Handbook.

You must enable the archiving to record log archives. Logs are not archived unless enabled, regardless of whether or not the DLP sensor for archiving is applied to the firewall policy.

 

Network scan

Network scan logs are recorded when a scheduled scan of the network occurs. These log messages provide detailed information about the network’s vulnerabilities regarding software, as well as the discovery of any further vulnerabilities.

A scheduled scan must be configured and logging enabled within the Event Log settings, for the FortiGate unit to record these log messages.


Having trouble configuring your Fortinet hardware or have some questions you need answered? Check Out The Fortinet Guru Youtube Channel! Want someone else to deal with it for you? Get some consulting from Fortinet GURU!

Chapter 18 – Logging and Reporting

Chapter 18 – Logging and Reporting

This FortiOS Handbook chapter contains the following sections:

Logging and reporting overview provides general information about logging. We recommend that you begin with this chapter as it contains information for both beginners and advanced users as well. It contains an explanation of log messages, files, and devices, and an overview of the Reporting functions.

Logging and reporting for small networks provides an overview of setting up a small network for logging, with a look at a possible setup with a backup solution and a customized report.

Logging and reporting for large networks provides an overview of setting up a larger, enterprise-level network, with configuration of multiple FortiGate units, multiple FortiAnalyzer units as a backup solution, and a sample procedure for creating a more intensive and broad report to suit the larger network.

Advanced logging provides a series of separate tutorials for possible tasks and procedures an advanced user may want to undertake with their FortiGate-powered network. It contains explanations of advanced backup, logging, and report solutions.

Troubleshooting and logging provides a short overview of how log messages can be used to identify and solve problems within the network, how to identify and solve logging database issues, and how to solve connection issues between FortiGate and FortiAnalyzer units.

 

Logging and reporting overview

Logging and reporting in FortiOS can help you in determining what is happening on your network, as well as informing you of certain network activity, such as detection ofa virus or IPsec VPN tunnel errors. Logging and reporting go hand in hand, and can become a valuable tool for information as well as helping to show others the activity that is happening on the network.

This section explains logging and reporting features that are available in FortiOS, and how they can be used to help you manage or troubleshoot issues. This includes how the FortiGate unit records logs, what a log message is, and what the log database is.

 

What is logging?

Logging records the traffic passing through the FortiGate unit to your network and what action the FortiGate unit took during its scanning process of the traffic. This recorded information is called a log message.

After a log message is recorded, it is stored within a log file which is then stored on a log device. A log device is a central storage location for log messages. The FortiGate unit supports several log devices, such as FortiAnalyzer units, the FortiCloud service, and Syslog servers. A FortiGate unit’s system memory and local disk can also be configured to store logs, and because of this, are also considered log devices.

You must subscribe to FortiCloud before you will be able to configure the FortiGate unit to send logs to a FortiCloud server.

When the recorded activity needs to be read in a more human way, the FortiGate unit can generate a Report. A report gathers all the log information that is needed for the report, and presents it in a graphical format, with customizable design and automatically generated charts. Reports can be used to present a graphical representation of what is going on in the network. Reports can also be generated on a FortiAnalyzer unit; if you want to generate reports on a FortiAnalyzer, see the FortiAnalyzer Setup and Administration Guide to help you create and generate those reports.

 

How the FortiGate unit records log messages

The FortiGate unit records log messages in a specific order, storing them on a log device. The order of how the FortiGate unit records log messages is as follows:

1. Incoming traffic is scanned.

2. During the scanning process, the FortiGate unit performs necessary actions, and simultaneously records the actions and results.

3. Log messages are sent to the log device.

 

Example: How the FortiGate unit records a DLP event

1. The FortiGate unit receives incoming traffic and scans for any matches associated within its firewall policies containing a DLP sensor.

2. A match is found; the DLP sensor, dlp_sensor, had a rule within it called All-HTTP with the action Exempt applied to the rule. The sensor also has Enable Logging selected, which indicates to the FortiGate unit that the activity should be recorded and placed in the DLP log file.

3. The FortiGate unit exempts the match, and places the recorded activity (the log message) within the DLP log file.

4. According to the log settings that were configured, logs are stored on the FortiGate unit’s local hard drive. The FortiGate unit places the DLP log file on the local hard drive.


Having trouble configuring your Fortinet hardware or have some questions you need answered? Check Out The Fortinet Guru Youtube Channel! Want someone else to deal with it for you? Get some consulting from Fortinet GURU!

Example Basic IP load balancing configuration

Example Basic IP load balancing configuration

This example shows how to add a server load balancing virtual IP that load balances all traffic among 3 real servers. In the example the Internet is connected to port2 and the virtual IP address of the virtual server is 192.168.20.20. The load balancing method is weighted. The IP addresses of the real servers are 10.10.10.1, 10.10.10.2, and 10.10.10.3. The weights for the real servers are 1, 2, and 3. The default weight is 1 and does not have to be changed for the first real server.

config firewall vip

edit All_Load_Balance

set type server-load-balance set server-type ip

set extintf port2

set extip 192.168.20.20 set ldb-method weighted config realservers

edit 1

set ip 10.10.10.1 next

edit 2

set ip 10.10.10.2 set weight 2

next edit 3

set ip 10.10.10.3 set weight 3

end

end

 

Example Adding a server load balance port forwarding virtual IP

In this example, a virtual web server with IP address 192.168.37.4 on the Internet, is mapped to three real web servers connected to the FortiGate unit dmz1 interface. The real servers have IP addresses 10.10.123.42, 10.10.123.43, and 10.10.123.44. The virtual server uses the First Alive load balancing method.

Each real server accepts HTTP connections on a different port number. The first real server accepts connections on port 8080, the second on port 8081, and the third on 8082. The configuration also includes an HTTP health check monitor that includes a URL used by the FortiGate unit for get requests to monitor the health of the real servers.

Connections to the virtual web server at IP address 192.168.37.4 from the Internet are translated and load balanced to the real servers by the FortiGate unit. First alive load balancing directs all sessions to the first real server. The computers on the Internet are unaware of this translation and load balancing and see a single virtual server at IP address 192.168.37.4 rather than the three real servers behind the FortiGate unit.

 

.10. Z1

2

 

Virtua

192.1 l

68.3

rtu
Z
1 M1

0.2

 

Vi

9

Server load balance virtual IP port forwarding

To complete this configuration, all of the steps would be the same as in Example HTTP load balancing to three real web servers on page 1937 except for configuring the real servers.

 

To add the real servers and associate them with the virtual server

Use the following steps to configure the FortiGate unit to port forward HTTP packets to the three real servers on ports 8080, 8081, and 8082.

1. Go to Policy & Objects > Real Servers.

2. Select Create New.

3. Configure three real servers that include the virtual server Load_Bal_VS1. Each real server must include the IP address of a real server on the internal network and have a different port number.

Configuration for the first real server.

Virtual Server                             Load_Bal_VS1

IP                                                 10.10.10.42

Port                                             8080

Weight                                        Cannot be configured because the virtual server does not include weighted load balancing.

Maximum Connections            0

Configuration for the second real server.

Virtual Server                             Load_Bal_VS1

IP                                                 10.10.10.43

Port                                             8081

Weight                                        Cannot be configured because the virtual server does not include weighted load balancing.

Maximum Connections            0

Configuration for the third real server.

Virtual Server                             Load_Bal_VS1

IP                                                 10.10.10.44

Port                                             8082

Weight                                        Cannot be configured because the virtual server does not include weighted load balancing.

Maximum Connections            0

 

Example Weighted load balancing configuration

This example shows how to using firewall load balancing to load balances all traffic among 3 real servers. In the example the Internet is connected to port2 and the virtual IP address of the virtual server is 192.168.20.20. The load balancing method is weighted. The IP addresses of the real servers are 10.10.10.1, 10.10.10.2, and 10.10.10.3. The weights for the real servers are 1, 2, and 3.

This configuration does not include a health check monitor.

 

Webbased manager configuration

Use the following procedures to configure this load balancing setup from the web-based manager.

 

To add the HTTP virtual server

1. Go to Policy & Objects > Virtual Servers.

2. Select Create New.

3. Add an IP virtual server that allows users on the Internet to connect to the real servers on the internal network. In this example, the FortiGate port2 interface is connected to the Internet.

Name                                           HTTP_weghted_LB

Type                                            IP

Interface                                     port2

Virtual Server IP                        192.168.20.20

Load Balance Method              Weighted

All other virtual server settings are not required or cannot be changed.

4. Select OK.

 

To add the real servers and associate them with the virtual server

1. Go to Policy & Objects > Real Servers.

2. Select Create New.

3. Configure three real servers that include the virtual server All_Load _Balance. Because the Load Balancing Method is Weighted, each real server includes a weight. Servers with a greater weight receive a greater proportion of forwarded connections, Configuration for the first real server.

Virtual Server                             HTTP_weghted_LB

IP Address                                 10.10.10.1

Port                                             Cannot be configured because the virtual server is an IP server.

Weight                                        1

Maximum Connections            0

Setting Maximum Connections to 0 means the FortiGate unit does not limit the number of connections to the real server. Since the virtual server uses First Alive load balancing you may want to limit the number of con- nections to each real server to limit the traffic received by each server. In this example, the Maximum Connections is initially set to 0 but can be adjusted later if the real servers are getting too much traffic.

Configuration for the second real server.

Virtual Server                             HTTP_weghted_LB

IP Address                                 10.10.10.2

Port                                             Cannot be configured because the virtual server is an IP server.

Weight                                        2

Maximum Connections            0

Setting Maximum Connections to 0 means the FortiGate unit does not limit the number of connections to the real server. Since the virtual server uses First Alive load balancing you may want to limit the number of con- nections to each real server to limit the traffic received by each server. In this example, the Maximum Connections is initially set to 0 but can be adjusted later if the real servers are getting too much traffic.

Configuration for the third real server.

Virtual Server                             HTTP_weghted_LB

IP Address                                 10.10.10.3

Port                                             Cannot be configured because the virtual server is an IP server.

Weight                                        3

Maximum Connections            0

Setting Maximum Connections to 0 means the FortiGate unit does not limit the number of connections to the real server. Since the virtual server uses First Alive load balancing you may want to limit the number of con- nections to each real server to limit the traffic received by each server. In this example, the Maximum Connections is initially set to 0 but can be adjusted later if the real servers are getting too much traffic.

 

To add the virtual server to a security policy

Add a port2 to port1 security policy that uses the virtual server so that when users on the Internet attempt to connect to the web server’s IP address, packets pass through the FortiGate unit from the wan1 interface to the dmz1 interface. The virtual IP translates the destination address of these packets from the virtual server IP address to the real server IP addresses.

1. Go to Policy & Objects > IPv4 Policy.

2. Select Create New.

3. Configure the security policy:

Policy Type                                Firewall

Policy Subtype                          Address

Incoming Interface                   port2

Source Address                        all (or a more specific address)

Outgoing Interface                   port1

Destination Address                 HTTP_weghted_LB

Schedule                                    always

Service                                       ALL

Action                                         ACCEPT

Enable NAT                                Select this option and select Use Destination Interface Address.

4. Select other security policy options as required.

5. Select OK.

 

CLI configuration

Load balancing is configured from the CLI using the config firewall vip command and by setting type to server-load-balance. The default weight is 1 and does not have to be changed for the first real server. Use the following command to add the virtual server and the three weighted real servers.

config firewall vip

edit HTTP_weghted_LB

set type server-load-balance set server-type ip

set extintf port2

set extip 192.168.20.20 set ldb-method weighted config realservers

edit 1

set ip 10.10.10.1 next

edit 2

set ip 10.10.10.2 set weight 2

next edit 3

set ip 10.10.10.3 set weight 3

end

end

 

Example HTTP and HTTPS persistence configuration

This example shows how to add a virtual server named HTTP_Load_Balance that load balances HTTP traffic using port 80 and a second virtual server named HTTPS_Load_Balance that load balances HTTPS traffic using port 443. The Internet is connected to port2 and the virtual IP address of the virtual server is 192.168.20.20. Both server load balancing virtual IPs load balance sessions to the same three real servers with IP addresses 10.10.10.2, 10.10.10.2, and 10.10.10.3. The real servers provide HTTP and HTTPS services. For both virtual servers, persistence is set to HTTP Cookie to enable HTTP cookie persistence.

 

To add the HTTP and HTTPS virtual servers

1. Go to Policy & Objects > Virtual Servers.

2. Add the HTTP virtual server that includes HTTP Cookie persistence.

Name                                           HTTP_Load_Balance

Type                                            HTTP

Interface                                     port2

Virtual Server IP                        192.168.20.20

Virtual Server Port                    80

In this example the virtual server uses port 8080 for HTTP sessions instead of port 80.

Load Balance Method              Static

Persistence                                HTTP cookie

3. Select OK.

4. Select Create New.

5. Add the HTTPs virtual server that also includes HTTP Cookie persistence.

 

  Name HTTPS_Load_Balance
Type HTTPS
Interface port2
Virtual Server IP 192.168.20.20
Virtual Server Port 443
Load Balance Method Static
Persistence HTTP cookie
 

6.

 

Select OK.

 

 

To add the real servers and associate them with the virtual servers

1. Go to Policy & Objects > Real Servers.

2. Select Create New.

3. Configure three real servers for HTTP that include the virtual server HTTP_Load_Balance.

Configuration for the first HTTP real server.

Virtual Server                             HTTP_Load_Balance

IP Address                                 10.10.10.1

Port                                             80

Weight                                        Cannot be configured because the virtual server does not include weighted load balancing.

Maximum Connections            0

 

Configuration for the second HTTP real server.

Virtual Server                             HTTP_Load_Balance

IP Address                                 10.10.10.2

Port                                             80

Weight                                        Cannot be configured because the virtual server does not include weighted load balancing.

Maximum Connections            0

 

Configuration for the third HTTP real server.

Virtual Server                             HTTP_Load_Balance

IP Address                                 10.10.10.3

Port                                             80

Weight                                        Cannot be configured because the virtual server does not include weighted load balancing.

Maximum Connections            0

4. Configure three real servers for HTTPS that include the virtual server HTTPS_Load_Balance.

 

Configuration for the first HTTPS real server.

Virtual Server                             HTTP_Load_Balance

IP Address                                 10.10.10.1

Port                                             443

Weight                                        Cannot be configured because the virtual server does not include weighted load balancing.

Maximum Connections            0

 

Configuration for the second HTTPS real server.

Virtual Server                             HTTP_Load_Balance

IP Address                                 10.10.10.2

Port                                             443

Weight                                        Cannot be configured because the virtual server does not include weighted load balancing.

Maximum Connections            0

 

Configuration for the third HTTPS real server.

Virtual Server                             HTTPS_Load_Balance

IP Address                                 10.10.10.3

Port                                             443

Weight                                        Cannot be configured because the virtual server does not include weighted load balancing.

Maximum Connections            0

 

To add the virtual servers to security policies

Add a port2 to port1 security policy that uses the virtual server so that when users on the Internet attempt to connect to the web server’s IP address, packets pass through the FortiGate unit from the wan1 interface to the dmz1 interface. The virtual IP translates the destination address of these packets from the virtual server IP address to the real server IP addresses.

1. Go to Policy & Objects > IPv4 Policy.

2. Select Create New.

3. Configure the HTTP security policy:

Policy Type                                Firewall

Policy Subtype                          Address

Incoming Interface                   port2

Source Address                        all

Outgoing Interface                   port1

Destination Address                 HTTP_Load_Balance

Schedule                                    always

Service                                       HTTP

Action                                         ACCEPT

Enable NAT                                Select this option and select Use Destination Interface Address.

4. Select other security policy options as required.

5. Select OK.

6. Select Create New.

7. Configure the HTTP security policy:

Policy Type                                Firewall

Policy Subtype                          Address

Incoming Interface                   port2

Source Address                        all

Outgoing Interface                   port1

Destination Address                 HTTPS_Load_Balance

Schedule                                    always

Service                                       HTTPS

Action                                         ACCEPT

Enable NAT                                Select this option and select Use Destination Interface Address.

8. Select other security policy options as required.

9. Select OK.

 

CLI configuration: adding persistence for a specific domain

Load balancing is configured from the CLI using the config firewall vip command and by setting type to server-load-balance.

For the CLI configuration, both virtual servers include setting http-cookie-domain to .example.org

because HTTP cookie persistence is just required for the example.org domain. First, the configuration for the HTTP virtual IP:

config firewall vip

edit HTTP_Load_Balance

set type server-load-balance set server-type http

set extport 8080 set extintf port2

set extip 192.168.20.20

set persistence http-cookie

set http-cookie-domain .example.org config realservers

edit 1

set ip 10.10.10.1 next

edit 2

set ip 10.10.10.2 next

edit 3

set ip 10.10.10.3 end

end

Second, the configuration for the HTTPS virtual IP. In this configuration you don’t have to set extport to 443 because extport is automatically set to 443 when server-type is set to https.

config firewall vip

edit HTTPS_Load_Balance

set type server-load-balance set server-type https

set extport 443 set extintf port2

set extip 192.168.20.20

set persistence http-cookie

set http-cookie-domain .example.org config realservers

edit 1

set ip 10.10.10.1 next

edit 2

set ip 10.10.10.2 next

edit 3

set ip 10.10.10.3 end

end


Having trouble configuring your Fortinet hardware or have some questions you need answered? Check Out The Fortinet Guru Youtube Channel! Want someone else to deal with it for you? Get some consulting from Fortinet GURU!

Load balancing configuration examples

Load balancing configuration examples

Example HTTP load balancing to three real web servers

In this example, a virtual web server with IP address 192.168.37.4 on the Internet, is mapped to three real web servers connected to the FortiGate unit dmz1 interface. The real servers have IP addresses 10.10.123.42, 10.10.123.43, and 10.10.123.44. The virtual server uses the First Alive load balancing method. The configuration also includes an HTTP health check monitor that includes a URL used by the FortiGate unit for get requests to monitor the health of the real servers.

Connections to the virtual web server at IP address 192.168.37.4 from the Internet are translated and load balanced to the real servers by the FortiGate unit. First alive load balancing directs all sessions to the first real server. The computers on the Internet are unaware of this translation and load balancing and see a single virtual server at IP address 192.168.37.4 rather than the three real servers behind the FortiGate unit.

 

 

Webbased manager configuration

Use the following procedures to configure this load balancing setup from the web-based manager.

 

To add an HTTP health check monitor

In this example, the HTTP health check monitor includes the URL “/index.html” and the Matched Phrase “Fortinet products”.

1. Go to Policy & Objects > Health Check.

2. Select Create New.

3. Add an HTTP health check monitor that sends get requests to http://<real_server_IP_address>/index.html and searches the returned web page for the phrase “Fortinet products”.

 

  Name HTTP_health_chk_1
Type HTTP
Port 80
URL /index.html
Matched Content Fortinet products
Interval 10 seconds
Timeout 2 seconds
Retry 3
 

4.

 

Select OK.

 

 

To add the HTTP virtual server

1. Go to Policy & Objects > Virtual Servers.

2. Select Create New.

3. Add an HTTP virtual server that allows users on the Internet to connect to the real servers on the internal network.

In this example, the FortiGate wan1 interface is connected to the Internet.

Name                                           Load_Bal_VS1

Type                                            HTTP

Interface                                     wan1

Virtual Server IP                        192.168.37.4

The public IP address of the web server.

The virtual server IP address is usually a static IP address obtained from your ISP for your web server. This address must be a unique IP address that is not used by another host and cannot be the same as the IP address of the external interface the virtual IP will be using. However, the external IP address must be routed to the selected interface. The virtual IP address and the external IP address can be on different subnets. When you add the virtual IP, the external interface responds to ARP requests for the external IP address.

Virtual Server Port                    80

Load Balance Method              First Alive

Persistence                                HTTP cookie

HTTP Multiplexing                    Select.

The FortiGate unit multiplexes multiple client into a few connections between the FortiGate unit and each real HTTP server. This can improve performance by reducing server overhead associated with establishing mul- tiple connections.

 

Preserve Client IP                     Select

The FortiGate unit preserves the IP address of the client in the X-For- warded-For HTTP header.

 

Health Check                             Move the HTTP_health_chk_1 health check monitor to the Selected list.

4. Select OK.

 

To add the real servers and associate them with the virtual server

1. Go to Policy & Objects > Real Servers.

2. Select Create New.

3. Configure three real servers that include the virtual server Load_Bal_VS1. Each real server must include the IP address of a real server on the internal network. Configuration for the first real server.

Virtual Server                             Load_Bal_VS1

IP Address                                 10.10.10.42

Port                                             80

Weight                                        Cannot be configured because the virtual server does not include weighted load balancing.

Maximum Connections            0

Setting Maximum Connections to 0 means the FortiGate unit does not limit the number of connections to the real server. Since the virtual server uses First Alive load balancing you may want to limit the number of con- nections to each real server to limit the traffic received by each server. In this example, the Maximum Connections is initially set to 0 but can be adjusted later if the real servers are getting too much traffic.

Configuration for the second real server.

Virtual Server                             Load_Bal_VS1

IP Address                                 10.10.10.43

Port                                             80

Weight                                        Cannot be configured because the virtual server does not include weighted load balancing.

Maximum Connections            0

Setting Maximum Connections to 0 means the FortiGate unit does not limit the number of connections to the real server. Since the virtual server uses First Alive load balancing you may want to limit the number of con- nections to each real server to limit the traffic received by each server. In this example, the Maximum Connections is initially set to 0 but can be adjusted later if the real servers are getting too much traffic.

Configuration for the third real server.

Virtual Server                             Load_Bal_VS1

IP Address                                 10.10.10.44

Port                                             80

Weight                                        Cannot be configured because the virtual server does not include weighted load balancing.

Maximum Connections            0

Setting Maximum Connections to 0 means the FortiGate unit does not limit the number of connections to the real server. Since the virtual server uses First Alive load balancing you may want to limit the number of con- nections to each real server to limit the traffic received by each server. In this example, the Maximum Connections is initially set to 0 but can be adjusted later if the real servers are getting too much traffic.

 

To add the virtual server to a security policy

Add a wan1 to dmz1 security policy that uses the virtual server so that when users on the Internet attempt to connect to the web server’s IP address, packets pass through the FortiGate unit from the wan1 interface to the dmz1 interface. The virtual IP translates the destination address of these packets from the virtual server IP address to the real server IP addresses.

1. Go to Policy & Objects > IPv4 Policy.

2. Select Create New.

3. Configure the security policy:

Policy Type                                Firewall

Policy Subtype                          Address

Incoming Interface                   wan1

Source Address                        all (or a more specific address)

Outgoing Interface                   dmz1

Destination Address                 Load_Bal_VS1

Schedule                                    always

Service                                       HTTP

Action                                         ACCEPT

Log Allowed Traffic                  Select to log virtual server traffic

Enable NAT                                Select this option and select Use Destination Interface Address.

4. Select other security policy options as required.

5. Select OK.

 

CLI configuration

Use the following procedure to configure this load balancing setup from the CLI.

 

To configure HTTP load balancing

1. Use the following command to add an HTTP health check monitor that sends get requests to http://<real_server_ IP_address>/index.html and searches the returned web page for the phrase “Fortinet products”.

config firewall ldb-monitor edit HTTP_health_chk_1

set type http set port 80

set http-get /index.html

set http-match “Fortinet products”

set interval 10 set timeout 2 set retry 3

end

2. Use the following command to add an HTTP virtual server that allows users on the Internet to connect to the real servers on the internal network. In this example, the FortiGate wan1 interface is connected to the Internet.

config firewall vip edit Load-Bal_VS1

set type server-load-balance set server-type http

set ldb-method first-alive set http-multiplex enable set http-ip-header enable set extip 192.168.37.4

set extintf wan1 set extport 80

set persistence http-cookie set monitor HTTP_health_chk_1

config realservers edit 1

set ip 10.10.10.42 set port 80

next edit 2

set ip 10.10.10.43 set port 80

next edit 3

set ip 10.10.10.44 set port 80

end

end

3. Use the following command to add a security policy that includes the load balance virtual server as the destination address.

config firewall policy edit 0

set srcintf wan1 set srcaddr all set dstintf dmz1

set dstaddr Load-Bal_VS1 set action accept

set schedule always set service ALL

set nat enable end

Configure other security policy settings as required.


Having trouble configuring your Fortinet hardware or have some questions you need answered? Check Out The Fortinet Guru Youtube Channel! Want someone else to deal with it for you? Get some consulting from Fortinet GURU!

IP, TCP, and UDP load balancing

IP, TCP, and UDP load balancing

You can load balance all IP, TCP or UDP sessions accepted by the security policy that includes a load balancing virtual server with the type set to IP, TCP, or UDP. Traffic with destination IP and port that matches the virtual server IP and port is load balanced. For these protocol-level load balancing virtual servers you can select a load balance method and add real servers and health checking. However, you can’t configure persistence, HTTP multiplexing and SSL offloading.

 


Having trouble configuring your Fortinet hardware or have some questions you need answered? Check Out The Fortinet Guru Youtube Channel! Want someone else to deal with it for you? Get some consulting from Fortinet GURU!

SSL offloading support or Internet Explorer 6

SSL offloading support or Internet Explorer 6

In some cases the Internet Explorer 6 web browser may be able to access real servers. To resolve this issue, disable the ssl-send-empty-frags option:

config firewall vip edit vip_name

set ssl-send-empty-frags disable end

You can disable this option if SSL acceleration will be used with an old or buggy SSL implementation that cannot properly handle empty fragments.

 

Selecting the cipher suites available for SSL load balancing

You can use the following command to view the complete list of cipher suites available for SSL offloading:

config firewall vip edit <vip-name>

set type server-load-balance set server-type https

set ssl-algorithm custom config ssl-cipher-suites

edit 0

set cipher ?

In most configurations the matching cipher suite is automatically selected but you can limit the set of cipher suites that are available for a given SSL offloading configuration. For example, use the following command to limit an SSL load balancing configuration to use the three cipher suites that support ChaCha20 and Poly1305:

config firewall vip edit <vip-name>

set type server-load-balance set server-type https

set ssl-algorithm custom config ssl-cipher-suites

edit 1

set cipher TLS-ECDHE-RSA-WITH-CHACHA20-POLY1305-SHA256 next

edit 2

set cipher TLS-ECDHE-ECDSA-WITH-CHACHA20-POLY1305-SHA256 next

edit 3

set cipher TLS-DHE-RSA-WITH-CHACHA20-POLY1305-SHA256 end

end

 

Disabling SSL/TLS re-negotiation

The vulnerability CVE-2009-3555 affects all SSL/TLS servers that support re-negotiation. FortiOS when configured for SSL/TLS offloading is operating as a SSL/TLS server. The IETF is working on a TLS protocol change that will fix the problem identified by CVE-2009-3555 while still supporting re-negotiation. Until that protocol change is available, you can use the ssl-client-renegotiation option to disable support for SSL/TLS re-negotiation. The default value of this option is allow, which allows an SSL client to renegotiate. You can change the setting to deny to abort any attempts by an SSL client to renegotiate. If you select deny as soon as a ClientHello message indicating a re-negotiation is received from the client FortiOS terminates the TCP connection.

Since SSL offloading does not support requesting client certificates the only circumstance in which a re- negotiation is required is when more than 2^32 bytes of data are exchanged over a single handshake. If you are sure that this volume of traffic will not occur then you can disable re-negotiation and avoid any possibility of the attack described in CVE-2009-3555.

The re-negotiation behavior can be tested using OpenSSL. The OpenSSL s_client application has the feature that the user can request that it do renegotiation by typing “R”. For example, the following shows a successful re- negotiation against a FortiGate unit configured with a VIP for 192.168.2.100:443:

$ openssl s_client -connect 192.168.2.100:443

CONNECTED(00000003)

depth=1 /C=US/ST=California/L=Sunnyvale/O=Fortinet/OU=Certificate

Authority/CN=support/emailAddress=support@fortinet.com

verify error:num=19:self signed certificate in certificate chain verify return:0

Certificate chain

0

s:/C=US/ST=California/L=Sunnyvale/O=Fortinet/OU=Fortigate/CN=FW80CM3909604325/emailAdd ress=support@fortinet.com

i:/C=US/ST=California/L=Sunnyvale/O=Fortinet/OU=Certificate

Authority/CN=support/emailAddress=support@fortinet.com

1 s:/C=US/ST=California/L=Sunnyvale/O=Fortinet/OU=Certificate

Authority/CN=support/emailAddress=support@fortinet.com i:/C=US/ST=California/L=Sunnyvale/O=Fortinet/OU=Certificate Authority/CN=support/emailAddress=support@fortinet.com

Server certificate

—–BEGIN CERTIFICATE—–

 

—certificate not shown—

—–END CERTIFICATE—– subject=/C=US/ST=California/L=Sunnyvale/O=Fortinet/OU=Fortigate/CN=FW80CM3909604325/em

ailAddress=support@fortinet.com issuer=/C=US/ST=California/L=Sunnyvale/O=Fortinet/OU=Certificate Authority/CN=support/emailAddress=support@fortinet.com

No client certificate CA names sent

SSL handshake has read 2370 bytes and written 316 bytes

New, TLSv1/SSLv3, Cipher is DHE-RSA-AES256-SHA Server public key is 1024 bit

Compression: NONE Expansion: NONE SSL-Session:

Protocol : TLSv1

Cipher : DHE-RSA-AES256-SHA Session-ID:

02781E1E368DCCE97A95396FAA82E8F740F5BBA96CF022F6FEC3597B0CC88095

Session-ID-ctx: Master-Key:

 

A6BBBD8477A2422D56E57C1792A4EA9C86F37D731E67D0A66E5CDB2B5C76650780C0E7F01CFF851EC44661

86F4C48397

Key-Arg : None

Start Time: 1264453027

Timeout : 300 (sec)

Verify return code: 19 (self signed certificate in certificate chain)

GET /main.c HTTP/1.0

R RENEGOTIATING

depth=1 /C=US/ST=California/L=Sunnyvale/O=Fortinet/OU=Certificate

Authority/CN=support/emailAddress=support@fortinet.com

verify error:num=19:self signed certificate in certificate chain verify return:0

HTTP/1.0 200 ok

Content-type: text/plain

/*

* Copyright (C) 2004-2007 Fortinet

*/

#include <stdio.h>

#include “vsd_ui.h”

int main(int argc, char **argv)

{

return vsd_ui_main(argc, argv);

}

closed

$

The following is the same test, but this time with the VIP configuration changed to ssl-client- renegotation deny:

$ openssl s_client -connect 192.168.2.100:443

CONNECTED(00000003)

depth=1 /C=US/ST=California/L=Sunnyvale/O=Fortinet/OU=Certificate

Authority/CN=support/emailAddress=support@fortinet.com

verify error:num=19:self signed certificate in certificate chain verify return:0

Certificate chain

0

s:/C=US/ST=California/L=Sunnyvale/O=Fortinet/OU=Fortigate/CN=FW80CM3909604325/emailAdd ress=support@fortinet.com

i:/C=US/ST=California/L=Sunnyvale/O=Fortinet/OU=Certificate

Authority/CN=support/emailAddress=support@fortinet.com

1 s:/C=US/ST=California/L=Sunnyvale/O=Fortinet/OU=Certificate

Authority/CN=support/emailAddress=support@fortinet.com i:/C=US/ST=California/L=Sunnyvale/O=Fortinet/OU=Certificate Authority/CN=support/emailAddress=support@fortinet.com

Server certificate

—–BEGIN CERTIFICATE—–

—certificate not shown—

—–END CERTIFICATE—–

subject=/C=US/ST=California/L=Sunnyvale/O=Fortinet/OU=Fortigate/CN=FW80CM3909604325/em ailAddress=support@fortinet.com

issuer=/C=US/ST=California/L=Sunnyvale/O=Fortinet/OU=Certificate

Authority/CN=support/emailAddress=support@fortinet.com

No client certificate CA names sent

SSL handshake has read 2370 bytes and written 316 bytes

New, TLSv1/SSLv3, Cipher is DHE-RSA-AES256-SHA Server public key is 1024 bit

Compression: NONE Expansion: NONE SSL-Session:

Protocol : TLSv1

Cipher : DHE-RSA-AES256-SHA Session-ID:

8253331D266DDE38E4D8A04AFCA9CBDED5B1134932CE1718EED6469C1FBC7474

Session-ID-ctx: Master-Key:

ED05A3EF168AF2D06A486362FE91F1D6CAA55CEFC38A3C36FB8BD74236BF2657D4701B6C1456CEB5BB5EFA A7619EF12D

Key-Arg : None

Start Time: 1264452957

Timeout : 300 (sec)

Verify return code: 19 (self signed certificate in certificate chain)

GET /main.c HTTP/1.0

R RENEGOTIATING

19916:error:1409E0E5:SSL routines:SSL3_WRITE_BYTES:ssl handshake failure:s3_pkt.c:530:

Use the following command to check the SSL stats to see that the renegotiations blocked counter is now 1:

diagnose firewall vip virtual-server stats ssl ssl

client

connections total 0 active 0 max 0

handshakes total 4 active 0 max 0 completed 4 abbreviated 0 session states total 4 active 4 max 4

cipher-suite failures 0

embryonics total 0 active 0 max 0 terminated 0 renegotiations blocked 1

server

connections total 0 active 0 max 0

handshakes total 3 active 0 max 0 completed 2 abbreviated 1 session states total 1 active 1 max 1

cipher-suite failures 0 internal error 0

bad handshake length 0

bad change cipher spec length 0 pubkey too big 0

persistence

find 0 found 0 clash 0 addr 0 error 0

If the virtual server debug log is examined (diagnose debug appl vs -1) then at the point the re-negotiation is blocked there is a log:

vs ssl 12 handshake recv ClientHello vs ssl 12 handshake recv 1

(0100005403014b5e056c7f573a563bebe0258c3254bbaff7046a461164f34f94f4f3d019c418000026

00390038003500160013000a00330032002f00050004001500120009001400110008000600030201000

00400230000)

vs ssl 12 client renegotiation attempted rejected, abort vs ssl 12 closing 0 up

vs src 12 close 0 in

vs src 12 error closing vs dst 14 error closing vs dst 14 closed

vs ssl 14 close

vs sock 14 free vs src 12 closed vs ssl 12 close vs sock 12 free


Having trouble configuring your Fortinet hardware or have some questions you need answered? Check Out The Fortinet Guru Youtube Channel! Want someone else to deal with it for you? Get some consulting from Fortinet GURU!

SSL/TLS load balancing

SSL/TLS load balancing

In a firewall load balancing virtual server configuration, you can select SSL to load balance only SSL and TLS sessions. The virtual server will load balance SSL and TLS sessions received at the virtual server interface with destination IP address that matches the configured virtual server IP and destination port number that matches the configured virtual server port. Change this port to match the destination port of the sessions to be load balanced.

For SSL load balancing you can also set persistence to SSL session ID. Persistence is achieved by the FortiGate unit sending all sessions with the same SSL session ID to the same real server. When you configure persistence, the FortiGate unit load balances a new session to a real server according to the Load Balance Method. If the session has an SSL session ID, the FortiGate unit sends all subsequent sessions with the same SSL session ID to the same real server.

 

SSL offloading

Use SSL offloading to accelerate clients’ SSL or HTTPS connections to real servers by using the FortiGate unit to perform SSL operations (offloading them from the real servers using the FortiGate unit’s SSL acceleration hardware). FortiGate units can offload SSL 3.0 and TLS 1.0. SSL offloading is available on FortiGate units that support SSL acceleration.

To configure SSL offloading from the web-based manager go to Policy & Objects > Virtual Servers. Add a virtual server and set the type to HTTPS or SSL and select the SSL offloading type (Client <-> FortiGate or Client <-> FortiGate <-> Server).

Select Client <-> FortiGate to apply hardware accelerated SSL processing only to the part of the connection between the client and the FortiGate unit. This mode is called half mode SSL offloading. The segment between the FortiGate unit and the server will use clear text communications. This results in best performance, but cannot be used in failover configurations where the failover path does not have an SSL accelerator.

Select Client <-> FortiGate <->Server to apply hardware accelerated SSL processing to both parts of the connection: the segment between client and the FortiGate unit, and the segment between the FortiGate unit and the server. This mode is called full mode SSL offloading. The segment between the FortiGate unit and the server will use encrypted communications, but the handshakes will be abbreviated. This results in performance which is less than the other option, but still improved over communications without SSL acceleration, and can be used in failover configurations where the failover path does not have an SSL accelerator. If the server is already configured to use SSL, this also enables SSL acceleration without requiring changes to the server’s configuration.

SSL Offloading modes

Web server cluster

FortiGate unit

SSL accelerator

Client <-> FortiGate

(Half-mode) SSL accelerator

Web server cluster

NAT Router

FortiGate unit

SSL accelerator

Client <-> FortiGate <-> Server

(Full-mode) SSL accelerator

Configuring SSL offloading also requires selecting a certificate to use for the SSL offloading sessions. The certificate key size must be 1024 or 2048 bits. 4096-bit keys are not supported.

The following CLI command shows an example half mode HTTPS SSL offloading configuration. In the example the ssl-mode option sets the SSL offload mode to half (which is the default mode).

config firewall vip

edit Vserver-ssl-offload

set type server-load-balance

set server-type https

set ldb-method round-robin set extip 172.20.120.30

set extintf wan1 set extport 443

set persistence ssl-session-id set ssl-mode half

set ssl-certificate my-cert set monitor tcp-mon-1

config realservers edit 1

set ip 10.31.101.30 set port 443

next edit 2

set ip 10.31.101.40 set port 443

end

end

 

Additional SSL load balancing options

The following SSL load balancing and SSL offloading options are only available from the CLI:

ssl-client-session-state-max <sessionstates_int>

Enter the maximum number of SSL session states to keep for the segment of the SSL connection between the client and the FortiGate unit.

ssl-client-session-state-timeout <timeout_int>

Enter the number of minutes to keep the SSL session states for the segment of the SSL connection between the client and the FortiGate unit.

ssl-client-session-state-type {both | client | disable | time}

Select which method the FortiGate unit should use when deciding to expire SSL sessions for the segment of the

SSL connection between the client and the FortiGate unit.

  • both: Select to expire SSL session states when either ssl-client-session-state-max or ssl-client- session-state-timeout is exceeded, regardless of which occurs first.
  • count: Select to expire SSL session states when ssl-client-session-state-max is exceeded.
  • disable: Select to keep no SSL session states.
  • time: Select to expire SSL session states when ssl-client-session-state-timeout is exceeded.

ssl-dh-bits <bits_int>

Enter the number of bits of the prime number used in the Diffie-Hellman exchange for RSA encryption of the SSL

connection. Larger prime numbers are associated with greater cryptographic strength.

ssl-http-location-conversion {enable | disable}

Select to replace http with https in the reply’s Location HTTP header field. For example, in the reply,

Location: http://example.com/ would be converted to Location: https://example.com/

ssl-http-match-host {enable | disable}

Select to apply Location conversion to the reply’s HTTP header only if the host name portion of Location matches the request’s Host field, or, if the Host field does not exist, the host name portion of the request’s URI. If disabled, conversion occurs regardless of whether the host names in the request and the reply match.

For example, if host matching is enabled, and a request contains Host: example.com and the reply contains Location: http://example.cc/, the Location field does not match the host of the original request and the reply’s Location field remains unchanged. If the reply contains  Location: http://example.com/, however, then the FortiGate unit detects the matching host name and converts the reply field to Location: https://example.com/.

This option appears only if ssl-http-location-conversion is enable.

ssl-max-version {ssl-3.0 | tls-1.0}

Enter the maximum version of SSL/TLS to accept in negotiation.

ssl-min-version {ssl-3.0 | tls-1.0}

Enter the minimum version of SSL/TLS to accept in negotiation.

ssl-send-empty-frags {enable | disable}

Select to precede the record with empty fragments to thwart attacks on CBC IV. You might disable this option if SSL acceleration will be used with an old or buggy SSL implementation which cannot properly handle empty fragments.

ssl-server-session-state-max <sessionstates_int>

Enter the maximum number of SSL session states to keep for the segment of the SSL connection between the server and the FortiGate unit.

ssl-server-session-state-timeout <timeout_int>

Enter the number of minutes to keep the SSL session states for the segment of the SSL connection between the server and the FortiGate unit. This option appears only if ssl-mode is full.

ssl-server-session-state-type {both | count | disable | time}

Select which method the FortiGate unit should use when deciding to expire SSL sessions for the segment of the

SSL connection between the server and the FortiGate unit. This option appears only if ssl-mode is full.

  • both: Select to expire SSL session states when either ssl-server-session-state-max or ssl-server- session-state-timeout is exceeded, regardless of which occurs first.
  • count: Select to expire SSL session states when ssl-server-session-state-max is exceeded.
  • disable: Select to keep no SSL session states.
  • time: Select to expire SSL session states when ssl-server-session-state-timeout is exceeded

Having trouble configuring your Fortinet hardware or have some questions you need answered? Check Out The Fortinet Guru Youtube Channel! Want someone else to deal with it for you? Get some consulting from Fortinet GURU!

HTTP and HTTPS load balancing, multiplexing, and persistence

HTTP and HTTPS load balancing, multiplexing, and persistence

In a firewall load balancing virtual server configuration, you can select HTTP to load balance only HTTP sessions. The virtual server will load balance HTTP sessions received at the virtual server interface with destination IP address that matches the configured virtual server IP and destination port number that matches the configured virtual server port. The default virtual server port for HTTP load balancing is 80, but you can change this to any port number. Similarly for HTTPS load balancing, set the virtual server type to HTTPS and then select the interface, virtual server IP, and virtual server port that matches the HTTPS traffic to be load balanced. Usually HTTPS traffic uses port 443.

You can also configure load balancing to offload SSL processing for HTTPS and SSL traffic.

 

HTTP and HTTPS multiplexing

For both HTTP and HTTPS load balancing you can multiplex HTTP requests and responses over a single TCP connection. HTTP multiplexing is a performance saving feature of HTTP/1.1 compliant web servers that provides the ability to pipeline many unrelated HTTP or HTTPS requests on the same connection. This allows a single HTTPD process on the server to interleave and serve multiple requests. The result is fewer idle sessions on the web server so server resources are used more efficiently. HTTP multiplexing can take multiple separate inbound sessions and multiplex them over the same internal session. This may reduce the load on the backend server and increase the overall performance.

HTTP multiplexing may improve performance in some cases. For example, if users web browsers are only compatible with HTTP 1.0. HTTP multiplexing can also improve performance between a web server and the FortiGate unit if the FortiGate unit is performing SSL acceleration. However, in most cases HTTP multiplexing should only be used if enabling it leads to a measurable improvement in performance.

To enable HTTP multiplexing from the web-based manager, select multiplex HTTP requests/responses over a single TCP connection. To enable HTTP multiplexing from the CLI enable the http-multiplex option.

 

Preserving the client IP address

Select preserve client IP from the web-based manager or enable the http-ip-header option from the CLI to preserve the IP address of the client in the X-Forwarded-For HTTP header. This can be useful in an HTTP multiplexing configuration if you want log messages on the real servers to the client’s original IP address. If this option is not selected, the header will contain the IP address of the FortiGate unit.

 

Preserving the client IP address but changing the X-Forwarded-For header name

If you select preserve client IP from the web-based manager or enable the http-ip-header option from the CLI you can also change the name of the X-Forwarded-For header to a custom header name. This can be useful if you want to use a custom header name instead of the standard header name.

You can configure changing the header name from the CLI. When http-ip-header is enabled you can add a custom header name to the http-ip-header-name option. If you don’t add a custom header name the X- Forwarded-For header name is maintained.

 

HTTP and HTTPS persistence

Configure load balancing persistence for HTTP or HTTPS to make sure that a user is connected to the same server every time they make a request that is part of the same session. HTTP cookie persistence uses injected cookies to enable persistence.

When you configure persistence, the FortiGate unit load balances a new session to a real server according to the Load Balance Method. If the session has an HTTP cookie or an SSL session ID, the FortiGate unit sends all subsequent sessions with the same HTTP cookie or SSL session ID to the same real server.

The following example shows how to enable cookie persistence and set the cookie domain to .example.org.

config firewall vip

edit HTTP_Load_Balance

set type server-load-balance set server-type http

set extport 8080 set extintf port2

set extip 192.168.20.20

set persistence http-cookie

set http-cookie-domain .example.org config realservers

edit 1

set ip 10.10.10.1 set port 80

next

edit 2

set ip 10.10.10.2 set port 80

next edit 3

set ip 10.10.10.3 set port 80

end

 

How HTTP cookie persistence options work

The following options are available for the config firewall vip command when type is set to server- load-balance, server-type is set to http or https and persistence is set to http-cookie:

http-cookie-domain-from-host http-cookie-domain

http-cookie-path

http-cookie-generation http-cookie-age

http-cookie-share https-cookie-share

When HTTP cookie persistence is enabled the FortiGate unit inserts a header of the following form into each

HTTP response unless the corresponding HTTP request already contains a FGTServer cookie:

Set-Cookie: FGTServer=E7D01637C4B08E89A6714213A9D85D9C7E4D8158; Version=1; Max-Age=3600

The value of the FGTServer cookie encodes the server that traffic should be directed to. The value is encoded so as to not leak information about the internal network.

Enable http-cookie-domain-from-host to extract the cookie domain from the host: header in the HTTP request. For example, to restrict the cookie to.server.com, enter:

The generated cookies could have the following form if the Host: header contains exhost.com:

Set-Cookie: FGTServer=E7D01637C4B08E89A6714213A9D85D9C7E4D8158; Version=1; Domain=.exhost.com; Max-Age=3600

For more information, see “HTTP host-based load balancing”.

Use http-cookie-domain to restrict the domain that the cookie should apply to. For example, to restrict the cookie to.server.com, enter:

set http-cookie-domain .server.com

Now all generated cookies will have the following form:

Set-Cookie: FGTServer=E7D01637C4B08E89A6714213A9D85D9C7E4D8158; Version=1; Domain=.server.com; Max-Age=3600

Use http-cookie-path to limit the cookies to a particular path. For example, to limit cookies to the path /sales, enter:

set http-cookie-path /sales

Now all generated cookies will have the following form:

Set-Cookie: FGTServer=E7D01637C4B08E89A6714213A9D85D9C7E4D8158; Version=1; Domain=.server.com; Path=/sales; Max-Age=3600

Use http-cookie-age to change how long the browser caches the cookie. You can enter an age in minutes or set the age to 0 to make the browser keep the cookie indefinitely:

set http-cookie-age 0

 

Now all generated cookies will have the following form:

Set-Cookie: FGTServer=E7D01637C4B08E89A6714213A9D85D9C7E4D8158; Version=1; Domain=.server.com; Path=/sales

Use http-cookie-generation to invalidate all cookies that have already been generated. The exact value of the generation is not important, only that it is different from any generation that has already been used for cookies in this domain. The simplest approach is to increment the generation by one each time invalidation is required. Since the default is 0, enter the following to invalidate all existing cookies:

set http-cookie-generation 1

Use http-cookie-share {disable | same-ip} to control the sharing of cookies across virtual servers in the same virtual domain. The default setting same-ip means that any FGTServer cookie generated by one virtual server can be used by another virtual server in the same virtual domain. For example, if you have an application that starts on HTTP and then changes to HTTPS and you want to make sure that the same server is used for the HTTP and HTTPS traffic then you can create two virtual servers, one for port 80 (for HTTP) and one for port 443 (for HTTPS). As long as you add the same real servers to both of these virtual servers (and as long as both virtual servers have the same number of real servers with the same IP addresses), then cookies generated by accessing the HTTP server are reused when the application changes to the HTTPS server.

If for any reason you do not want this sharing to occur then select disable to make sure that a cookie generated for a virtual server cannot be used by other virtual servers.

Use https-cookie-secure to enable or disable using secure cookies. Secure cookies are disabled by default because secure cookies can interfere with cookie sharing across HTTP and HTTPS virtual servers. If enabled, then the Secure tag is added to the cookie inserted by the FortiGate unit:

Set-Cookie: FGTServer=E7D01637C4B08E89A6714213A9D85D9C7E4D8158; Version=1; Max-Age=3600; Secure

 

HTTP host-based load balancing

When configuring HTTP or HTTPS load balancing you can select HTTP host load balancing to load balances HTTP host connections across multiple real servers using the host’s HTTP header to guide the connection to the correct real server. HTTP 1.1 includes the concept of a virtual server which allows a HTTP or HTTPS server with a single external IP address to serve requests for multiple DNS domains by using the mandatory Host: header in a HTTP request to indicate which DNS domain the request is destined for.

FortiOS can load-balance HTTP and HTTPS connections among multiple real servers using the Host: header to guide the connection to the correct real server. The host load balancing method allows a real server to specify a http-host attribute which is the domain name of the traffic for that real server. Each real server can only specify a single domain name. The same domain name can appear in more than one real server but only the first one that is up will be used, any others are purely for redundancy. If the Host: header contains a domain that does not match any http-host entry then the connection will be dropped. A real server with no http-host can be matched by any Host: domain.

For example, consider a FortiGate unit that is load-balancing traffic to three real servers. Traffic for www.example1.com should go to 192.168.2.1, traffic for www.example2.com should go to 192.168.2.2 and traffic to any other domain should go to 192.168.2.3. To enable this configuration you would add a virtual server and set the load balance method to HTTP host. Then you would add three real servers and set the HTTP host of the real server with IP address 192.168.2.1 to www.example1.com, the HTTP host of the real server with IP address 192.168.2.2 to www.example2.com and you would not specify an HTTP host for the third real server.

The configuration of a virtual IP to achieve this result would be:

config firewall vip

edit “http-host-ldb”

set type server-load-balance set extip 172.16.67.195

set extintf “lan”

set server-type http

set ldb-method http-host set extport 80

config realservers edit 1

set http-host “www.example1.com” set ip 192.168.2.1

set port 80

next edit 2

set http-host “www.example2.com” set ip 192.168.2.2

set port 80

next edit 3

set ip 192.168.2.3 set port 80

end

next end

 

Host load balancing and HTTP cookie persistence

In an HTTP host-based load balancing configuration with HTTP cookie persistence enabled you can optionally configure cookie persistence to use the domain set in the host header as the cookie domain. You can do this by enabling the http-cookie-domain-from-host option, for example:

config firewall vip

edit “http-host-ldb”

set type server-load-balance set extip 172.16.67.195

set extintf “lan”

set server-type http

set ldb-method http-host set extport 80

set persistence http-cookie

set http-cookie-domain-from-host enable config realservers

edit 1

set http-host “www.example1.com” set ip 192.168.2.1

set port 80 next

edit 2

set http-host “www.example2.com” set ip 192.168.2.2

set port 80 next

edit 3

set ip 192.168.2.3

end

set port 80 next

end

 


Having trouble configuring your Fortinet hardware or have some questions you need answered? Check Out The Fortinet Guru Youtube Channel! Want someone else to deal with it for you? Get some consulting from Fortinet GURU!