FTP proxy concepts

The FortiGate explicit FTP proxy

You can use the FortiGate explicit FTP proxy to enable explicit FTP proxying on one or more FortiGate interfaces. The explicit web and FTP proxies can be operating at the same time on the same or on different FortiGate interfaces.

In most cases you would configure the explicit FTP proxy for users on a network by enabling the explicit FTP proxy on the FortiGate interface connected to that network. Users on the network would connect to and authenticate with the explicit FTP proxy before connecting to an FTP server. In this case the IP address of the explicit FTP proxy is the IP address of the FortiGate interface on which the explicit FTP proxy is enabled.

Enabling the explicit FTP proxy on an interface connected to the Internet is a security risk because anyone on the Internet who finds the proxy could use it to hide their source address.

If the FortiGate unit is operating in transparent mode, users would configure their browsers to use a proxy server with the FortiGate unit management IP address.

The FTP proxy receives FTP sessions to be proxied at FortiGate interfaces with the explicit FTP proxy enabled.

The FTP proxy uses FortiGate routing to route sessions through the FortiGate unit to a destination interface. Before a session leaves the exiting interface, the explicit FTP proxy changes the source addresses of the session packets to the IP address of the exiting interface. When the FortiGate unit is operating in transparent mode the explicit web proxy changes the source addresses to the management IP address.

Example explicit FTP proxy topology

To allow anyone to anonymously log into explicit FTP proxy and connect to any FTP server you can set the explicit FTP proxy default firewall proxy action to accept. When you do this, users can log into the explicit FTP proxy with any username and password.

In most cases you would want to use explicit proxy policies to control explicit FTP proxy traffic and apply security features, access control/authentication, and logging. You can do this by keeping the default explicit FTP proxy firewall policy action to deny and then adding explicit FTP proxy policies. In most cases you would also want users to authenticate with the explicit FTP proxy. By default an anonymous FTP login is required. Usually you would add authentication to explicit FTP proxy policies. Users can then authenticate with the explicit FTP proxy according to users or user groups added to the policies. User groups added to explicit FTP proxy policies can use any authentication method supported by FortiOS including the local user database and RADIUS and other remote servers.

If you leave the default firewall policy action set to deny and add explicit FTP proxy policies, all connections to the explicit FTP proxy must match an or else they will be dropped. Sessions that are accepted are processed according to the ftp-proxy security policy settings.

You can also change the explicit FTP proxy default firewall policy action to accept and add explicit FTP proxy policies. If you do this, sessions that match explicit FTP proxy policies are processed according to the policy settings. Connections to the explicit FTP proxy that do not match an explicit FTP proxy policy are allowed and the users can authenticate with the proxy anonymously.

There are some limitations to the security features that can be applied to explicit FTP proxy sessions. See The FortiGate explicit FTP proxy on page 411.

You cannot configure IPsec, SSL VPN, or Traffic shaping for explicit FTP proxy traffic. Explicit FTP proxy policies can only include firewall addresses not assigned to a FortiGate unit interface or with interface set to any. (On the web-based manager you must set the interface to Any. In the CLI you must unset the associatedinterface.)

How to use the explicit FTP proxy to connect to an FTP server

To connect to an FTP server using the explicit FTP proxy, users must run an FTP client and connect to the IP address of a FortiGate interface on which the explicit FTP proxy is enabled. This connection attempt must use the configured explicit FTP proxy port number (default 21).

The explicit FTP proxy is not compatible with using a web browser as an FTP client. To use web browsers as FTP clients configure the explicit web proxy to accept FTP sessions.

The following steps occur when a user starts an FTP client to connect to an FTP server using the explicit FTP proxy. Any RFC-compliant FTP client can be used. This example describes using a command-line FTP client. Some FTP clients may require a custom FTP proxy connection script.

1. The user enters a command on the FTP client to connect to the explicit FTP proxy.

For example, if the IP address of the FortiGate interface on which the explicit FTP proxy is enabled is 10.31.101.100, enter:

ftp 10.31.101.100

2. The explicit FTP proxy responds with a welcome message and requests the user’s FTP proxy user name and password and a username and address of the FTP server to connect to: Connected to 10.31.101.100. 220 Welcome to FortiGate FTP proxy Name (10.31.101.100:user):

You can change the message by editing the FTP Explicit Banner Message replacement message.

3. At the prompt the user enters their FTP proxy username and password and a username and address for the FTP server. The FTP server address can be a domain name or numeric IP address. This information is entered using the following syntax:

<proxy-user>:<proxy-password>:<server-user>@<server-address>

For example, if the proxy username and password are p-name and p-pass and a valid username for the FTP server is s-name and the server’s IP address is ftp.example.com the syntax would be:

p-name:p-pass:s-name@ftp.example.com

4. The FTP proxy forwards the connection request, including the user name, to the FTP server.
5. If the user name is valid for the FTP server it responds with a password request prompt.
6. The FTP proxy relays the password request to the FTP client.
7. The user enters the FTP server password and the client sends the password to the FTP proxy.
8. The FTP proxy relays the password to the FTP server.
9. The FTP server sends a login successful message to the FTP proxy.
10. The FTP proxy relays the login successful message to the FTP client.
11. The FTP client starts the FTP session.

All commands entered by the client are relayed by the proxy to the server. Replies from the server are relayed back to the FTP client.

Explicit FTP proxy session

From a simple command line FTP client connecting to an the previous sequence could appear as follows:

ftp 10.31.101.100 21 Connected to 10.31.101.100.

220 Welcome to FortiGate FTP proxy

Name (10.31.101.100:user): p-name:p-pass:s-name@ftp.example.com 331 Please specify the password. Password: s-pass 230 Login successful.

Remote system type is UNIX

Using binary mode to transfer files. ftp>

Security profiles, threat weight, device identification, and the explicit FTP proxy

You can apply antivirus, data leak prevention (DLP), and SSL/SSH inspection to explicit FTP proxy sessions.

Security profiles are applied by selecting them in an explicit FTP proxy policy or an authentication rule in an FTP proxy security policy.

Traffic accepted by explicit FTP proxy policies contributes to threat weight data.

The explicit FTP proxy is not compatible with device identification.

Explicit FTP proxy options and SSL/SSH inspection

Since the traffic accepted by the explicit FTP proxy is known to be FTP and since the ports are already known by the proxy, the explicit FTP proxy does not use the FTP port proxy options settings.

When adding UTM features to an FTP proxy security policy, you must select a proxy options profile. In most cases you can select the default proxy options profile. You could also create a custom proxy options profile.

The explicit FTP proxy supports the following proxy options:

l Block Oversized File and oversized file limit

The explicit FTP proxy does not support the following protocol options: l Client comforting

Explicit FTP proxy sessions and antivirus

For explicit FTP proxy sessions, the FortiGate unit applies antivirus scanning to FTP file GET and PUT requests. The FortiGate unit starts virus scanning a file in an FTP session when it receives a file in the body of an FTP request.

Flow-based virus scanning is not available for explicit FTP proxy sessions. Even if the FortiGate unit is configured to use flow-based antivirus, explicit FTP proxy sessions use the regular virus database.

Explicit FTP proxy sessions and user limits

FTP clients do not open large numbers of sessions with the explicit FTP proxy. Most sessions stay open for a short while depending on how long a user is connected to an FTP server and how large the file uploads or downloads are. So unless you have large numbers of FTP users, the explicit FTP proxy should not be adding large numbers of sessions to the session table.

Explicit FTP proxy sessions and user limits are combined with explicit web proxy session and user limits. For information about explicit proxy session and user limits, see Explicit proxy sessions and user limits on page 1.

FTP proxy configuration

General explicit FTP proxy configuration steps

You can use the following general steps to configure the explicit FTP proxy.

To enable the explicit FTP proxy – web-based manager:

1. Go to Network > Explicit Proxy > Explicit FTP Proxy Options. Select Enable Explicit FTP Proxy to turn on the explicit FTP proxy.
2. Select Apply.

The Default Firewall Policy Action is set to Deny and requires you to add a explicit FTP proxy policy to allow access to the explicit FTP proxy. This configuration is recommended and is a best practice because you can use policies to control access to the explicit FTP proxy and also apply security features and authentication.

3. Go to Network > Interfaces and select one or more interfaces for which to enable the explicit web proxy. Edit the interface and select Enable Explicit FTP Proxy.

Enabling the explicit FTP proxy on an interface connected to the Internet is a security risk because anyone on the Internet who finds the proxy could use it to hide their source address. If you enable the proxy on such an interface make sure authentication is required to use the proxy.

4. Go to Policy & Objects > Proxy Policyand select Create New and set the Explicit Proxy Type to

You can add multiple explicit FTP proxy policies.

5. Configure the policy as required to accept the traffic that you want to be processed by the explicit FTP proxy.

The source address of the policy should match client source IP addresses. The firewall address selected as the source address cannot be assigned to a FortiGate interface. The Interface field of the firewall address must be blank or it must be set to Any.

The destination address of the policy should match the IP addresses of FTP servers that clients are connecting to. The destination address could be all to allow connections to any FTP server.

If Default Firewall Policy Action is set to Deny, traffic sent to the explicit FTP proxy that is not accepted by an explicit FTP proxy policy is dropped. If Default Firewall Policy Action is set to Allow then all FTP proxy sessions that don’t match a policy are allowed.

For example the following explicit FTP proxy policy allows users on an internal network to access FTP servers on the Internet through the wan1 interface of a FortiGate unit.

The following explicit FTP proxy policy requires users on an internal network to authenticate with the FortiGate unit before accessing FTP servers on the Internet through the wan1 interface.

6. Select Create New to add an Authentication Rule and configure the rule as follows:

7. Add security profiles as required and select OK.
8. You can add multiple authentication rules to apply different authentication for different user groups and users and also apply different security profiles and logging settings for different users.
9. Select OK.

To enable the explicit FTP proxy – CLI:

1. Enter the following command to turn on the explicit FTP proxy. This command also changes the explicit FTP proxy port to 2121.

config ftp-proxy explicit set status enable set incoming-port 2121

end

The default explicit FTP proxy configuration has sec-default-action set to deny and requires you to add a security policy to allow access to the explicit FTP proxy.

2. Enter the following command to enable the explicit FTP proxy for the internal interface. config system interface edit internal set explicit-ftp-proxy enable

end end

3. Use the following command to add a firewall address that matches the source address of users who connect to the explicit FTP proxy.

config firewall address edit Internal_subnet set type iprange set start-ip 10.31.101.1 set end-ip 10.31.101.255

end

The source address for a ftp-proxy security policy cannot be assigned to a FortiGate unit interface.

4. Use the following command to add an explicit FTP proxy policy that allows all users on the internal subnet to use the explicit FTP proxy for connections through the wan1 interface to the Internet.

config firewall proxy-policy edit 0 set proxy ftp set dstintf wan1 set scraddr Internal_subnet

set dstaddr all set action accept set schedule always

end

5. Use the following command to add an explicit FTP proxy policy that allows authenticated users on the internal subnet to use the explicit FTP proxy for connections through the wan1 interface to the Internet.

config firewall proxy-policy edit 0 set proxy ftp set dstintf wan1 set scraddr Internal_subnet set dstaddr Fortinet-web-sites set action accept set schedule always set groups <User group>

end

end

Restricting the IP address of the explicit FTP proxy

You can use the following command to restrict access to the explicit FTP proxy using only one IP address. The IP address that you specify must be the IP address of an interface that the explicit FTP proxy is enabled on. You might want to use this option if the explicit FTP proxy is enabled on an interface with multiple IP addresses.

For example, to require uses to connect to the IP address 10.31.101.100 to connect to the explicit FTP proxy:

config ftp-proxy explicit set incoming-ip 10.31.101.100 end

Restricting the outgoing source IP address of the explicit FTP proxy

You can use the following command to restrict the source address of outgoing FTP proxy packets to a single IP address. The IP address that you specify must be the IP address of an interface that the explicit FTP proxy is enabled on. You might want to use this option if the explicit FTP proxy is enabled on an interface with multiple IP addresses.

For example, to restrict the outgoing packet source address to 172.20.120.100:

config ftp-proxy explicit set outgoing-ip 172.20.120.100

end

Example users on an internal network connecting to FTP servers on the Internet through the explicit FTP with RADIUS authentication and virus scanning

This example describes how to configure the explicit FTP proxy for the example network shown below. In this example, users on the internal network connect to the explicit FTP proxy through the Internal interface with IP address 10.31.101.100. The explicit web proxy is configured to use port 2121 so to connect to an FTP server on the Internet users must first connect to the explicit FTP proxy using IP address 10.31.101.100 and port 2121.

Example explicit FTP proxy network topology

In this example, explicit FTP proxy users must authenticate with a RADIUS server before getting access to the proxy. To apply authentication, the security policy that accepts explicit FTP proxy traffic includes an identity based policy that applies per session authentication to explicit FTP proxy users and includes a user group with the RADIUS server in it. The identity based policy also applies UTM virus scanning and DLP.

General configuration steps

This section breaks down the configuration for this example into smaller procedures. For best results, follow the procedures in the order given:

1. Enable the explicit FTP proxy and change the FTP port to 2121.
2. Enable the explicit FTP proxy on the internal interface.

Example users on an internal network connecting to FTP servers on the Internet through the explicit                FTP proxy

3. Add a RADIUS server and user group for the explicit FTP proxy.
4. Add a user identity security policy for the explicit FTP proxy.
5. Enable antivirus and DLP features for the identity-based policy.

Configuring the explicit FTP proxy – web-based manager

Use the following steps to configure the explicit FTP proxy from FortiGate web-based manager.

To enable and configure the explicit FTP proxy

1. Go to Network > Explicit Proxy > Explicit FTP Proxy Options and change the following settings:

2. Select Apply.

To enable the explicit FTP proxy on the Internal interface

1. Go to Network > Interfaces, edit the Internal interface and select Enable Explicit FTP Proxy.

To add a RADIUS server and user group for the explicit FTP proxy

1. Go to User & Device > RADIUS Servers.
2. Select Create New to add a new RADIUS server:

3. Go to User > User > User Groups and select Create New.

4. Select OK.

FTP proxy         Example users on an internal network connecting to FTP servers on the Internet through the explicit configuration     FTP with RADIUS authentication and virus scanning

To add a security policy for the explicit FTP proxy

1. Go to Policy & Objects > Addresses and select Create New.
2. Add a firewall address for the internal network:

3. Go to Policy & Objects > Proxy Policyand select Create New.
4. Configure the explicit FTP proxy security policy.

5. Under Configure Authentication Rules select Create New to add an authentication rule:

6. Turn on Antivirus and Web Filter and select the default profiles for both.
7. Select the default proxy options profile.
8. Select OK.
9. Make sure Enable IP Based Authentication is not selected and DefaultAuthentication Method is set to Basic.
10. Select OK.

Configuring the explicit FTP proxy – CLI

Use the following steps to configure the example explicit web proxy configuration from the CLI.

To enable and configure the explicit FTP proxy

1. Enter the following command to enable the explicit FTP proxy and set the TCP port that proxy accepts FTP connections on to 2121.

config ftp-proxy explicit set status enable set incoming-port 2121

Example users on an internal network connecting to FTP servers on the Internet through the explicit                FTP proxy

set sec-default-action deny

end

To enable the explicit FTP proxy on the Internal interface

1. Enter the following command to enable the explicit FTP proxy on the internal interface. config system interface edit internal set explicit-ftp-proxy enable

end

To add a RADIUS server and user group for the explicit FTP proxy

1. Enter the following command to add a RADIUS server:

config user radius edit RADIUS_1 set server 10.31.101.200 set secret RADIUS_server_secret

end

2. Enter the following command to add a user group for the RADIUS server.

config user group edit Explicit_proxy_user_group set group-type firewall set member RADIUS_1

end

To add a security policy for the explicit FTP proxy

1. Enter the following command to add a firewall address for the internal subnet: config firewall address edit Internal_subnet set type iprange set start-ip 10.31.101.1 set end-ip 10.31.101.255

end

2. Enter the following command to add the explicit FTP proxy security policy: config firewall proxy-policy edit 0 set proxy ftp set dstintf wan1 set srcaddr Internal_subnet

set dstaddr all set action accept set identity-based enable set ipbased disable set active-auth-method basic set groups <User group> end

FTP proxy         Example users on an internal network connecting to FTP servers on the Internet through the explicit configuration     FTP with RADIUS authentication and virus scanning

Testing and troubleshooting the configuration

You can use the following steps to verify that the explicit FTP proxy configuration is working as expected. These steps use a command line FTP client.

To test the explicit web proxy configuration

1. From a system on the internal network start an FTP client and enter the following command to connect to the FTP proxy:

ftp 10.31.101.100

The explicit FTP proxy should respond with a message similar to the following:

Connected to 10.31.101.100. 220 Welcome to Floodgate FTP proxy Name (10.31.101.100:user):

2. At the prompt enter a valid username and password for the RADIUS server followed by a user name for an FTP server on the Internet and the address of the FTP server. For example, if a valid username and password on the RADIUS server is ex_name and ex_pass and you attempt to connect to an FTP server at ftp.example.com with user name s_name, enter the following at the prompt:

Name (10.31.101.100:user):ex_name:ex_pass:s_name@ftp.example.com

3. You should be prompted for the password for the account on the FTP server.
4. Enter the password and you should be able to connect to the FTP server.
5. Attempt to explore the FTP server file system and download or upload files.
6. To test UTM functionality, attempt to upload or download an ECAR test file. Or upload or download a text file containing text that would be matched by the DLP sensor.

For eicar test files, go to http://eicar.org.

Diagnose commands for WAN optimization

The following get and diagnose commands are available for troubleshooting WAN optimization, web cache, explicit proxy and WCCP.

get test {wad | wccpd} <test_level>

Display usage information about WAN optimization, explicit proxy, web cache, and WCCP applications. Use <test_level> to display different information.

get test wad <test_level> get test wccpd <test_level>

Examples

Enter the following command to display WAN optimization tunnel protocol statistics. The http tunnel and tcp tunnel parts of the command output below shows that WAN optimization has been processing HTTP and TCP packets.

get test wad 1

WAD manager process status: pid=113 n_workers=1 ndebug_workers=0 Enter the following command to display all test options:

get test wad

WAD process 82 test usage:

1: display process status 2: display total memory usage.

99: restart all WAD processes 1000: List all WAD processes.

1001: dispaly debug level name and values 1002: dispaly status of WANOpt storages 1068: Enable debug for all WAD workers.

1069: Disable debug for all WAD workers.

2yxx: Set No. xx process of type y as diagnosis process. 3: display all fix-sized advanced memory stats

4: display all fix-sized advanced memory stats in details

500000..599999: cmem bucket stats (599999 for usage)

800..899: mem_diag commands (800 for help & usage)

800000..899999: mem_diag commands with 1 arg (800 for help & usage) 80000000..89999999: mem_diag commands with 2 args (800 for help & usage) 60: show debug stats.

diagnose wad

61: discard all wad debug info that is currently pending

62xxx: set xxxM maximum ouput buffer size for WAD debug. 0, set back to default.

68: Enable process debug

69: Disable process debug

98: gracefully stopping WAD process

9xx: Set xx workers(0: default based on user configuration.)

diagnose wad

Display diagnostic information about the WAN optimization daemon (wad).

diagnose wad console-log {disable | enable) diagnose wad debug-url {disable | enable)

diagnose wad filter {clear | dport | dst | list | negate | protocol | sport | src | vd} diagnose wad history {clear | list} diagnose wad session {clear | list}

diagnose wad stats {cache | cifs | clear | crypto | ftp | http | list | mapi | mem | scan | scripts | summary | tcp | tunnel}

diagnose wad user {clear | list} diagnose wad tunnel {clear | list}1

diagnose wad webcache {clear | list} {10min | hour | day | 30days}

diagnose wad

Example diagnose wad tunnel list

Enter the following command to list all of the running WAN optimization tunnels and display information about each one. The command output shows 10 tunnels all created by peer-to-peer WAN optimization rules (autodetect set to off).

diagnose wad tunnel list

Tunnel: id=100 type=manual vd=0 shared=no uses=0 state=3

peer name=Web_servers id=100 ip=172.20.120.141

SSL-secured-tunnel=no auth-grp= bytes_in=348 bytes_out=384

Tunnel: id=99 type=manual vd=0 shared=no uses=0 state=3

peer name=Web_servers id=99 ip=172.20.120.141

SSL-secured-tunnel=no auth-grp= bytes_in=348 bytes_out=384

Tunnel: id=98 type=manual vd=0 shared=no uses=0 state=3

peer name=Web_servers id=98 ip=172.20.120.141

SSL-secured-tunnel=no auth-grp= bytes_in=348 bytes_out=384

Tunnel: id=39 type=manual vd=0 shared=no uses=0 state=3

peer name=Web_servers id=39 ip=172.20.120.141

SSL-secured-tunnel=no auth-grp= bytes_in=1068 bytes_out=1104

Tunnel: id=7 type=manual vd=0 shared=no uses=0 state=3

peer name=Web_servers id=7 ip=172.20.120.141

SSL-secured-tunnel=no auth-grp= bytes_in=1228 bytes_out=1264

Tunnel: id=8 type=manual vd=0 shared=no uses=0 state=3

peer name=Web_servers id=8 ip=172.20.120.141

SSL-secured-tunnel=no auth-grp= bytes_in=1228 bytes_out=1264

Tunnel: id=5 type=manual vd=0 shared=no uses=0 state=3

peer name=Web_servers id=5 ip=172.20.120.141

SSL-secured-tunnel=no auth-grp= bytes_in=1228 bytes_out=1264

Tunnel: id=4 type=manual vd=0 shared=no uses=0 state=3

peer name=Web_servers id=4 ip=172.20.120.141

SSL-secured-tunnel=no auth-grp= bytes_in=1228 bytes_out=1264

diagnose wad

Tunnel: id=1 type=manual vd=0 shared=no uses=0 state=3

peer name=Web_servers id=1 ip=172.20.120.141

SSL-secured-tunnel=no auth-grp= bytes_in=1228 bytes_out=1264

Tunnel: id=2 type=manual vd=0 shared=no uses=0 state=3

peer name=Web_servers id=2 ip=172.20.120.141

SSL-secured-tunnel=no auth-grp= bytes_in=1228 bytes_out=1264

Tunnels total=10 manual=10 auto=0

Example diagnose wad webcache list

This following command displays the web caching stats for the last 10 minutes of activity. The information displayed is divided into 20 slots and each slot contains stats for 30 seconds:

20 * 30 seconds = 600 seconds = 10 minutes

diagnose wad webcache list 10min web cache history vd=0 period=last 10min

The first 20 slots are for HTTP requests in the last 10 minutes. Each slot of stats has four numbers, which is the total number of HTTP requests, the number of cacheable HTTP requests, the number of HTTP requests that are processed by the web cache (hits), and the number of HTTP requests that are processed without checking the web cache (bypass). There are many reasons that a HTTP request may bypass web cache. total cacheable hits bypass

———— ————- ———— ————-

diagnose wad

The following slots are for video requests in the last 10 minutes. Each slot has two numbers for each 30 seconds: total number of video requests, and the number of video requests that are processing using cached data.

video total video hit

———— ————-

0            0

0            0

0            0

0            0

0            0

0            0

0            0

0            0

0            0

0            0

0            0

0            0

0            0

0            0

0            0

The following 20 slots are for traffic details in last 10 minutes. Each slot has four numbers for 30 seconds each.

— LAN —                — WAN —

bytes_in     bytes_out     bytes_in     bytes_out

———— ————- ———— ————-

34360       150261        141086       32347

105408       861863        858501       100670

128359       1365919       1411849     127341

60103 602813 818075      59967 105867 1213192 1463736 97489

154961       1434784       1344911      158667

73967        370275        369847       70626

129327       602834        592399      123676

115719 663446 799445      111262 58151       724993 631721 59989

175681      2092925 1092556 166212 37805 33042        41528 37779

183686       1255118       1114646     172371

106125       904178        807152       81520

66147        473983       543507       66782

170451      1289530      1201639 165540 69196       544559       865370 68446

134142      579605        821430      132113

96895       668037       730633      89872

59576       248734      164002 59448 diagnose wad csvc

The diagnose wad csvc command refers to the cache-service. The next options to the command are listed in the table. Some will have there own sub options for refining the output or results.

diagnose wacs

diagnose wad worker

The diagnose wad worker command has some settings that show useful WAD stats for one or all workers.The next options to the command are listed in the table. Some will have there own sub options for refining the output or results.

diagnose wacs

Display diagnostic information for the web cache database daemon (wacs).

diagnose wacs clear diagnose wacs recents diagnose wacs restart diagnose wacs stats

diagnose wadbd

diagnose wadbd

Display diagnostic information for the WAN optimization database daemon (waddb).

diagnose wadbd {check | clear | recents | restart | stats}

diagnose debug application {wad | wccpd} [<debug_level>]

View or set the debug level for displaying WAN optimization and web cache-related daemon debug messages. Include a <debug_level> to change the debug level. Leave the <debug_level> out to display the current debug level. Default debug level is 0.

diagnose debug application wad [<debug_level>] diagnose debug application wccpd [<debug_level>]

diagnose test application wad 2200

diagnose test application wad 2200

The debug level 2200 switches the debug to explicit proxy mode. You have to enter this debug level first. After that you have to type the command again with a different debug level to check the different explicit proxy statistics. To list what each debug level shows, follow these steps in any FortiGate device:

1. Enable explicit proxy globally and in one interface, to start the wad process. If the wad process is not running, you cannot list the options.
2. Once the wad process starts, type:

diagnose test application wad 2200 diagnose test application wad ///// Do not type any debug level value to list all the options.

This is the output you will get:

# diagnose test application wad 2200

Set diagnosis process: type=wanopt index=0 pid=114 # diagnose test application wad WAD process 114 test usage:

1: display process status

2: display total memory usage

99: restart all WAD processes

1000: List all WAD processes

1001: dispaly debug level name and values

1002: dispaly status of WANOpt storages 1068: Enable debug for all WAD workers

1069: Disable debug for all WAD workers

2yxx: Set No. xx process of type y as diagnosis process

3: display all fix-sized advanced memory stats

4: display all fix-sized advanced memory stats in details

500000..599999: cmem bucket stats (599999 for usage)

800..899: mem_diag commands (800 for help & usage)

800000..899999: mem_diag commands with 1 arg (800 for help & usage)

80000000..89999999: mem_diag commands with 2 args (800 for help & usage)

60: show debug stats

61: discard all wad debug info that is currently pending

62xxx: set xxxM maximum ouput buffer size for WAD debug (0: set back to default)

68: Enable process debug

69: Disable process debug

98: gracefully stopping WAD process

20: display all listeners 21: display TCP port info

22: display SSL stats

23: flush SSL stats

24: display SSL mem stats

70: display av memory usage

71xxxx: set xxxxMiB maximum AV memory (0: set back to default)

72: toggle av memory protection

73: toggle AV conserve mode (for debug purpose)

90: set to test disk failure

91: unset to test disk failure

92: trigger a disk failure event

100: display explicit proxy settings

101: display firewall policies

102: display security profile mapping for regular firewall policy

diagnose test application wad 2200

103: display Web proxy forwarding server and group

104: display DNS stats

105: display proxy redirection scan stats

106: list all used fqdns

107: list all firewall address

110: display current web proxy users

111: flush current web proxy users

112: display current web proxy user summary

113: display WAD fsso state

114: display HTTP digest stats

115: display URL patterns list of cache exemption or forward server

116: toggle dumping URL when daemon crashes

120: display Web Cache stats

121: flush Web Cache stats

122: flush idle Web cache objects

123: display web cache cache sessions

130: display ftpproxy stats

131: clear ftpproxy stats

132: list all current ftpproxy sessions

133: display all catched webfilter profiles

200: display WANopt profiles

201: display all peers

202: display video cache rules (patterns)

203: display all ssl servers

210: toggle disk-based byte-cache

211: toggle memory-based byte-cache

212: toggle cifs read-ahead

221: display tunnel protocol stats

222: flush tunnel protocol stats

223: display http protocol stats

224: flush http protocol stats

225: display cifs protocol stats

226: flush cifs protocol stats

227: display ftp protocol stats

228: flush ftp protocol stats

229: display mapi protocol stats

230: flush mapi protocol stats

231: display tcp protocol stats

232: flush tcp protocol stats

233: display all protocols stats

234: flush all protocols stats

240: display WAD tunnel stats

241: display tunnel compressor state

242: flush tunnel compressor stats

243: display Byte Cache DB state

244: flush Byte Cache DB stats

245: display Web Cache DB state

246: flush Web Cache DB stats

247: display cache state

248: flush cache stats

249: display memory cache state

250: flush memory cache stats

261yxxx: set xxx concurrent Web Cache session for object storage y

262yxxx: set xxxK(32K, 64K,…) unconfirmed write/read size per Web Cache object for object storage y

263yxxxx: set xxxxK maximum ouput buffer size for object storage y

diagnose test application wad 2200

264yxx: set lookup lowmark (only if more to define busy status) to be xx for object storage y

265yxxx: set xxxK maximum ouput buffer size for byte storage y

266yxxx: set number of buffered add requests to be xxx for byte storage y

267yxxxx: set number of buffered query requests to be xxxx for byte storage y

268yxxxxx: set number of concurrent query requests to be xxxxx for byte storage y

This is a short explanation video / white board session where I go over the high level architecture and benefits of an ADVPN. Dynamic VPN’s provide us the opportunity to grow our IT infrastructure without growing our management headache.

Introduction

FortiOS server load balancing includes the features you would expect of any server load balancing solution. Traffic can be distributed across multiple backend servers based on multiple methods including static (failover), round robin, weighted to account for different sized servers, or based on the health and performance of the server including round trip time, number of connections. The load balancer supports HTTP, HTTPS, IMAPS, POP3S, SMTPS, SSL or generic TCP/UDP or IP protocols. Session persistence is supported based on the SSL session ID or based on an injected HTTP cookie.

Before you begin

Before you can configure server load balancing on the GUI go to System > Feature Visibility and turn on Load Balance. Its in the Additional Features list.

To be able to use all of the features described in this chapter you should go to System > Settings and setting the Inspection Mode to Proxy. If Inspection mode is set to Flow-based, you can only configure Virtual Servers with Type set to HTTP, TCP, UDP, or IP. Proxy mode is required for persistence, HTTP Multiplexing, SSL offloading and other advanced HTTP and SSL features.

Inside FortiOS: Server Load Balancing

Server load balancing distributes workloads across multiple network servers, allowing simultaneous IPv4, IPv6, IPv4 to IPv6 and IPv6 to IPv4 requests to be handled quickly and reliably.

Server Load Balancing combined with NGFW and UTM protection

By introducing comprehensive server load balancing functionality to Next Generation Firewall (NGFW) and Unified Threat Management (UTM) solutions FortiOS takes threat protection to a whole new level. Rather than going to the expense of deploying multiple solutions to protect your server farm, you can combine firewalling, NGFW, UTM and load balancing into a single FortiGate unit or cluster. The benefit of consolidation is not only limited to cost.

Key Features & Benefits

The FortiOS server load balancing feature set contains all of the features you would expect of a server load balancing solution. Traffic can be balanced across multiple backend servers based on multiple load balancing schedules including static (failover), round robin, weighted to account for different sized servers, or based on the health and performance of the server including round trip time and number of connections.

The load balancer supports HTTP, HTTPS, IMAPS, POP3S, SMTPS, SSL/TLS, and generic TCP/UDP and IP protocols. Session persistence is supported based on the SSL session ID, based on an injected HTTP cookie, or based on the HTTP or HTTPS host. SSL/TLS load balancing includes protection from protocol downgrade SSL/TLS offloading  Inside FortiOS: Server Load Balancing attacks. Server load balancing is supported on most FortiGate devices and includes up to 10,000 virtual servers on our high end systems.

SSL/TLS offloading

With more and more critical business applications being made available online and in the cloud, the demand for secure remote continues to increase. While securing web and email applications with SSL/TLS is essential, this protection adds significant performance overheads. An SSL/TLS protected application running on a standard server will perform all the costly encryption/decryption and key exchange routines in software which uses vital CPU resources that should be available for running the application. The consequence of this is that many more or more powerful servers are required to deliver the application.

FortiGate SSL/TLS offloading is designed with the explosion of SSL/TLS applications in mind. The key exchange and encryption/decryption tasks are offloaded to the FortiGate unit where they are accelerated using FortiASIC technology providing significantly more performance than a standard server or load balancer could handle. This frees up valuable resources on the server farm which can be used to run a more responsive business. Server load balancing offloads most SSL/TLS versions including SSL 3.0, TLS 1.0 and TLS 1.2 and supports full mode or half mode SSL offloading with DH key sizes up to 4096 bits.

SSL/TLS content inspection

Traditionally, SSL encrypted application data would be invisible to any border gateway filtering solution. This is because the encryption process prevents the payload of any connection from being seen other than by the communicating systems. FortiGate SSL Offloading allows the application payload to be inspected before it reaches your servers; preventing intrusion attempts, blocking viruses, stopping unwanted applications, and preventing data leakage. SSL/TLS content inspection supports TLS versions 1.0, 1.1, and 1.2 and SSL versions 1.0, 1.1, 1.2, and 3.0.

Health Check

Health checking can be enabled to prevent load balancing traffic from being sent to a non-functioning real server. Real server health can be monitored using ICMP ping or more sophisticated TCP testing. The most comprehensive test is HTTP which verifies that the HTTP application is responding and that it is returning the correct content.

Health checking removes real servers from the load balancing cluster which are returning invalid content. The removal of real servers from the clusters is based on the Interval, Timeout and Retry Settings:

Server Monitoring and Management

The health and performance of real servers can be monitored from the FortiGate GUI. Virtual servers and their assigned real servers can be monitored for health status, if there have been any monitor events, number of active sessions, round trip time and number of bytes processed. Should a server become problematic and require

administration, it can be gracefully removed from the Real Server pool to enable disruption free maintenance. When a removed real server is able to operate it can gracefully be added back to the virtual server.

HTTP Multiplexing

A performance saving feature of HTTP/1.1 compliant web servers is the ability to pipeline requests on the same connection. This allows a single HTTPD process on the server to interleave and server multiple requests. HTTP multiplexing reduces the number idle sessions, too many of which can exhaust the resources on a server. The Fortinet solution has the ability to take multiple separate inbound sessions and multiplex them over the same internal session. This reduces the load on the backend server and increases the overall performance.

Basic load balancing configuration example

This section describes the steps required to configure the load balancing configuration shown below. In this configuration a FortiGate-51B unit is load balancing HTTP traffic from the Internet to three HTTP servers on the Internal network. HTTP sessions are accepted at the wan1 interface with destination IP address 172.20.120.121 on TCP port 8080 and forwarded from the internal interface to the web servers. When forwarded the destination address of the sessions is translated to the IP address of one of the web servers.

The load balancing configuration also includes session persistence using HTTP cookies, round-robin load balancing, and TCP health monitoring for the real servers. Ping health monitoring consists of the FortiGate unit using ICMP ping to make sure the web servers can respond to network traffic.

Virtual server and real servers setup

To configure the example load balancing configuration – general configuration steps

1. Add a load balance ping health check monitor.

A ping health check monitor causes the FortiGate unit to ping the real servers every 10 seconds. If one of the servers does not respond within 2 seconds, the FortiGate unit will retry the ping 3 times before assuming that the HTTP server is not responding.

2. Add a load balance virtual server.
3. Add the three load balance real servers to the virtual server.
4. Add a security policy that includes the load balance virtual server as the destination address.

To configure the example load balancing configuration

1. Go to Policy & Objects > Health Check and add the following health check monitor.

2. Go to Policy & Objects > Virtual Servers and add a virtual server that accepts the traffic to be load balanced.

3. On the same GUI page and the real servers to the virtual server.

Basic load balancing configuration example

4. Go to Policy & Objects > IPv4 Policy and add a wan1 to internal security policy that includes the virtual server.

This policy also applies an Antivirus profile to the load balanced sessions.

5. Select OK.

To configure the example load balancing configuration from the CLI

1. Use the following command to add a Ping health check monitor.

config firewall ldb-monitor edit ping-mon-l set type ping set interval 10 set timeout 2

set retry 3 end

2. Use the following command to add the virtual server that accepts HTTP sessions on port 8080 at the wan1 interface and load balances the traffic to three real servers. config firewall vip

Basic load balancing configuration example

edit Vserver-HTTP-1 set type server-load-balance set server-type http set ldb-method round-robin set extip 172.20.120.30 set extintf wan1 set extport 8080 set persistence http-cookie set monitor tcp-mon-1 config realservers edit 1 set ip 10.31.101.30

set port 80 next edit 2 set ip 10.31.101.40

set port 80 end edit 3 set ip 10.31.101.50

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 internal set dstaddr Vserver-HTTP-1 set action accept set schedule always set service ALL set nat enable set utm-status enable

set profile-protocol-options default set av-profile scan end

Configuring load balancing

This section describes how to use the FortiOS server load balancing to load balance traffic to multiple backend servers.

You can configure FortiOS load balancing to intercept incoming traffic with a virtual server and distribute it among one or more backend real servers. By doing so, FortiOS enables multiple real servers to respond as if they were a single device or virtual server. This in turn means that more simultaneous requests can be handled by the servers.

Traffic can be balanced across multiple backend real servers based on a selection of load balancing methods including static (failover), round robin, weighted to account for different sized servers, or based on the health and performance of the server including round trip time, number of connections. The load balancer can balance layer 7 HTTP, HTTPS, SSL, generic layer 4 TCP, UDP and generic layer 3 IP protocols. Session persistence is supported based on injected HTTP/HTTPS cookies or the SSL session ID.

You can bind up to 8 real servers can to one virtual server. The real server topology is transparent to end users, and the users interact with the system as if it were only a single server with the IP address and port number of the virtual server. The real servers may be interconnected by high-speed LAN or by geographically dispersed WAN. The FortiGate unit schedules requests to the real servers and makes parallel services of the virtual server to appear to involve a single IP address.

There are additional benefits to load balancing. First, because the load is distributed across multiple servers, the service being provided can be highly available. If one of the servers breaks down, the load can still be handled by the other servers. Secondly, this increases scalability. If the load increases substantially, more servers can be added behind the FortiGate unit to cope with the increased load.

Server load balancing configuration

Traffic can be balanced across multiple backend real servers based on a selection of load balancing methods including static (failover), round robin, weighted to account for different sized servers, or based on the health and performance of the server including round trip time, number of connections. The load balancer can balance layer 7 HTTP, HTTPS, SSL, generic layer 4 TCP, UDP and generic layer 3 IP protocols. Session persistence is supported based on injected HTTP/HTTPS cookies or the SSL session ID.

You can bind up to 8 real servers can to one virtual server. The real server topology is transparent to end users, and the users interact with the system as if it were only a single server with the IP address and port number of the Load balancing and other FortiOS features

virtual server. The real servers may be interconnected by high-speed LAN or by geographically dispersed WAN. The FortiGate unit schedules requests to the real servers and makes parallel services of the virtual server to appear to involve a single IP address.

Load balancing and other FortiOS features

Flow-based and proxy-based security features such as virus scanning, IPS, DLP, application control, and web filtering can be applied to load balanced sessions. This includes SSL offloading and multiplexing. Applying these UTM features to load balancing traffic may reduce load balancing performance.

Authentication is not supported for load balancing sessions. Usually FortiGate load balancing is used to allow public access to services on servers protected by a FortiGate unit. Authentication is not generally not required for this kind of configuration.

Features such web proxying, web caching, and WAN optimization also do not work with load balanced sessions. However, most other features that can be applied by a security policy are supported.

Configuring load balancing from the GUI

A virtual server is a specialized firewall virtual IP that performs server load balancing. From the GUI you add load balancing virtual server by going to Policy & Objects > Virtual Servers.

You can use the GUI to configure IPv, IPv6, IPv4 to IPv6 (NAT46), or IPv6 to IPv4 (NAT64) load balancing.

Type

Select the type of virtual server to configure. You can select IPv4, IPv6, NAT46, or NAT64. If Type is set to NAT46 or NAT64 you have fewer load balancing options (just HTTP, TCP, UDP and IP) and you can’t configure advanced SSL and HTTPS load balancing features.

Name

Enter the name for the virtual server.

Type

Select the protocol to be load balanced by the virtual server. If you select a general protocol such as IP, TCP, or

UDP the virtual server load balances all IP, TCP, or UDP sessions. If you select specific protocols such as HTTP, HTTPS, or SSL you can apply additional server load balancing features such as Persistence and HTTP Multiplexing.

• Select HTTP to load balance only HTTP sessions with destination port number that matches the Virtual Server

Port setting. Change Virtual Server Port to match the destination port of the sessions to be load balanced (usually port 80 for HTTP sessions). You can also select HTTP Multiplex. You can also set Persistence to HTTP Cookie to select cookie-based persistence.

• Select HTTPS to load balance only HTTPS sessions with destination port number that matches the Virtual Server

Port setting. Change Virtual Server Port to match the destination port of the sessions to be load balanced

(usually port 443 for HTTPS sessions). You can also select Multiplex HTTP requests/responses. You can also set Persistence to HTTP Cookie to select cookie-based persistence. You can also set Persistence to SSL Session ID.

• Select IMAPS to load balance only IMAPS sessions with destination port number that matches the Virtual Server Port Change Virtual Server Port to match the destination port of the sessions to be load balanced (usually port 993 for IMAPS sessions). You can also set Persistence to SSL Session ID. l Select POP3S to load balance only POP3S sessions with destination port number that matches the Virtual Server Port setting. Change Virtual Server Port to match the destination port of the sessions to be load balanced (usually port 995 for POP3S sessions). You can also set Persistence to SSL Session ID.
• Select SMTPS to load balance only SMTPS sessions with destination port number that matches the Virtual Server Port Change Virtual Server Port to match the destination port of the sessions to be load balanced (usually port 465 for SMTPS sessions). You can also set Persistence to SSL Session ID.
• Select SSL to load balance only SSL sessions with destination port number that matches the Virtual Server Port Change Virtual Server Port to match the destination port of the sessions to be load balanced.
• Select TCP to load balance only TCP sessions with destination port number that matches the Virtual Server Port Change Virtual Server Port to match the destination port of the sessions to be load balanced.
• Select UDP to load balance only UDP sessions with destination port number that matches the Virtual Server Port Change Virtual Server Port to match the destination port of the sessions to be load balanced. l Select IP to load balance all sessions accepted by the security policy that contains this virtual server.

Interface

Select the virtual server external or outgoing interface from the list. The outgoing interface is connected to the source network and receives the packets to be forwarded to the destination network.

Virtual Server IP

The IPv4 address of the virtual server. This is an IP address on the external interface that you want to map to an address on the destination network.

Virtual Server Port

Enter the external port number that you want to map to a port number on the destination network. Sessions with this destination port are load balanced by this virtual server.

Load Balance Method

Select the load balancing method used by the virtual server.

Persistence

Configure persistence 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. Session persistence is supported for HTTP and SSL sessions.

Health Check

Select which health check monitor configuration will be used to determine a server’s connectivity status.

HTTP Multiplexing

Select to use the FortiGate unit to multiplex multiple client connections into a few connections between the FortiGate unit and the real server.

Preserve Client IP

Select to preserve the IP address of the client in the X-Forwarded-For HTTP header. This can be useful 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.

This option appears only if Type is set to HTTP or HTTPS.

SSL Offloading

Accelerate clients’ SSL connections to the server by using the FortiGate to perform SSL operations. This option appears only if Type is set to one of the SSL protocols.

Mode

Select which segments of the SSL connection will receive SSL offloading. You can select Client <-> FortiGate (or half mode) or Full (full mode).

This option appears only if Type is set to one of the SSL protocols.

Certificate

Select the certificate to use with SSL Offloading. The certificate key size must be 1024 or 2048 bits. 4096-bit keys are not supported.

This option appears only if Type is set to one of the SSL protocols.

Real Servers

Add Real Servers to the virtual server. The virtual server load balances traffic to these real servers. See Real servers on page 23.

Configuring load balancing from the CLI

From the CLI you configure IPv4 load balancing by adding a firewall virtual IP and setting the virtual IP type to server load balance:

config firewall vip edit Vserver-HTTP-1 set type server-load-balance …

Sever load balancing is also supported for:

Load balancing methods

l IPv6 using the command config firewall vip6 l IPv6 to IPv4 using the command config firewall vip64 l IPv4 to IPv6 using the commmand config firewall vip46

Configuration is the same as IPv4 VIPs except support for advanced HTTP and SSL related features is not available. IPv6 server load balancing supports all the same server types as IPv4 server load balancing (HTTP, HTTPS, IMAPS, POP3S, SMTPS, SSL, TCP, UDP, and IP). IPv4 to IPv6 and IPv6 to IPv4 server load balancing supports fewer server types (HTTP, TCP, UDP, and IP).

A virtual server includes a virtual server IP address bound to an interface. The virtual server IP address is the destination address incoming packets to be load balanced and the virtual server is bound to the interface that receives the packets to be load balanced.

For example, if you want to load balance incoming HTTP traffic from the Internet to a group of web servers on a DMZ network, the virtual server IP address is the known Internet IP address of the web servers and the virtual server binds this IP address to the FortiGate interface connected to the Internet.

When you bind the virtual server’s external IP address to a FortiGate unit interface, by default, the network interface responds to ARP requests for the bound IP address. Virtual servers use proxy ARP, as defined in RFC 1027, so that the FortiGate unit can respond to ARP requests on a network for a real server that is actually installed on another network. In some cases you may not want the network interface sending ARP replies. You can use the arp-reply option disable sending ARP replies:

config firewall vip edit Vserver-HTTP-1 set type server-load-balance set arp-reply disable …

The load balancing virtual server configuration also includes the virtual server port. This is the TCP port on the bound interface that the virtual server listens for traffic to be load balanced on. The virtual server can listen on any port.

Load balancing methods

The load balancing method defines how sessions are load balanced to real servers. A number of load balancing methods are available as listed below.

All load balancing methods will not send traffic to real servers that are down or not responding. However, the FortiGate unit can only determine if a real server is not responding by using a health check monitor. You should always add at least one health check monitor to a virtual server or to individual real servers, or load balancing methods may attempt to distribute sessions to real servers that are not functioning.

Static

The traffic load is statically spread evenly across all real servers. However, sessions are not assigned according to how busy individual real servers are. This load balancing method provides some persistence because all sessions from the same source address always go to the same real server. However, the distribution is stateless, so if a real server is added or removed (or goes up or down) the distribution is changed and persistence could be lost.

Session persistence

Round Robin

Directs new requests to the next real server, and treats all real servers as equals regardless of response time or number of connections. Dead real servers or non responsive real servers are avoided.

Weighted

Real servers with a higher weight value receive a larger percentage of connections. Set the real server weight when adding a real server.

Least Session

Directs requests to the real server that has the least number of current connections. This method works best in environments where the real servers or other equipment you are load balancing all have similar capabilities. This load balancing method uses the FortiGate session table to track the number of sessions being processed by each real server. The FortiGate unit cannot detect the number of sessions actually being processed by a real server.

Least RTT

Directs sessions to the real server with the least round trip time. The round trip time is determined by a Ping health check monitor and is defaulted to 0 if no Ping health check monitors are added to the virtual server.

First Alive

Always directs sessions to the first alive real server. This load balancing schedule provides real server failover protection by sending all sessions to the first alive real server and if that real server fails, sending all sessions to the next alive real server. Sessions are not distributed to all real servers so all sessions are processed by the “first” real server only.

First refers to the order of the real servers in the virtual server configuration. For example, if you add real servers

A, B and C in that order, then all sessions always go to A as long as it is alive. If A goes down then sessions go to B and if B goes down sessions go to C. If A comes back up sessions go back to A. Real servers are ordered in the virtual server configuration in the order in which you add them, with the most recently added real server last. If you want to change the order you must delete and re-add real servers in the required order.

HTTP Host

Load balances HTTP host connections across multiple real servers using the host’s HTTP header to guide the connection to the correct real server.

Session persistence

Use persistence to make sure that a user is connected to the same real server every time they make an HTTP,

HTTPS, or SSL request that is part of the same user session. For example, if you are load balancing HTTP and HTTPS sessions to a collection of eCommerce web servers, when a user is making a purchase they will be starting multiple sessions as they navigate the eCommerce site. In most cases all of the sessions started by this user during on eCommerce session should be processed by the same real server. Typically, the HTTP protocol Real servers

keeps track of these related sessions using cookies. HTTP cookie persistence makes sure that all sessions that are part of the same user session are processed by 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 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. For more information about HTTP and HTTPS persistence, see “HTTP and HTTPS persistence”.

Real servers

Add real servers to a load balancing virtual server to provide the information the virtual server requires to be able to send sessions to the server. A real server configuration includes the IP address of the real server and port number that the real server receives sessions on. The FortiGate unit sends sessions to the real server’s IP address using the destination port number in the real server configuration.

When configuring a real server you can also specify the weight (used if the load balance method is set to weighted) and you can limit the maximum number of open connections between the FortiGate unit and the real server. If the maximum number of connections is reached for the real server, the FortiGate unit will automatically switch all further connection requests other real servers until the connection number drops below the specified limit. Setting Maximum Connections to 0 means that the FortiGate unit does not limit the number of connections to the real server.

Real server active, standby, and disabled modes

By default the real server mode setting is active indicating that the real server is available to receive connections. If the real server is removed from the network (for example, for routine maintenance or because of a hardware or software failure) you can change the mode to standby or disabled. In disabled mode the FortiGate unit no longer sends sessions to the real server.

If a real server is in standby mode the FortiGate also does not send sessions to it unless other real servers added to the same virtual server become unavailable. For example:

• A virtual server that includes two real servers one in active mode and one in standby mode. If the real server in active mode fails, the real server in standby mode is changed to active mode and all sessions are sent to this real server.
• A virtual server includes three real servers, two in active mode and one in standby mode, if one of the real servers in active mode fails, the real server in standby mode is changed to active mode and sessions are load balanced between it and still operating real server. If both real servers in active mode fail, all sessions are sent to the real server in standby mode.

Adding real servers from the GUI

To add a real server from the GUI go to Policy & Objects > Virtual Servers, edit a virtual server and under Real Servers select Create New to add a real server to this virtual server.

IP Address

Enter the IP address of the real server.

Real servers

Port

Enter the port number on the destination network to which the external port number is mapped.

Weight

Enter the weight value of the real server. The higher the weight value, the higher the percentage of connections the server will handle. A range of 1-255 can be used. This option is available only if the associated virtual server’s load balance method is Weighted.

Max Connections

Enter the limit on the number of active connections directed to a real server. A range of 1-99999 can be used. If the maximum number of connections is reached for the real server, the FortiGate unit will automatically switch all further connection requests to another server until the connection number drops below the specified limit.

Setting Maximum Connections to 0 means that the FortiGate unit does not limit the number of connections to the real server.

HTTP Host

Enter the HTTP header for load balancing across multiple real servers. This feature is used for load balancing HTTP host connections across multiple real servers using the host’s HTTP header to guide the connection to the correct real server, providing better load balancing for those specific connections.

Mode

Select a mode for the real server. The real server can be active, on standby, or disabled.

Adding real servers from the CLI

To add a real server from the CLI you configure a virtual server and add real servers to it. For example, to add three real servers to a virtual server that load balances UDP sessions on port 8190 using weighted load balancing. For each real server the port is not changed. The default real server port is 0 resulting in the traffic being sent the real server with destination port 8190. Each real sever is given a different weight. Servers with higher weights have a max-connections limit to prevent too many sessions from being sent to them.

config firewall vip edit Vserver-UDP-1 set type server-load-balance set server-type udp set ldb-method weighted set extip 172.20.120.30 set extintf wan1 set extport 8190 set monitor ping-mon-1 config realservers edit 1 set ip 10.31.101.30 set weight 100 set max-connections 10000

next edit 2 set ip 10.31.101.40 set weight 100

Health check monitoring

set max-connections 10000

next edit 3 set ip 10.31.101.50 set weight 10

end

end

Health check monitoring

From the FortiGate GUI you can go to Policy & Objects > Health Check and configure health check monitoring so that the FortiGate unit can verify that real servers are able respond to network connection attempts. If a real server responds to connection attempts the load balancer continues to send sessions to it. If a real server stops responding to connection attempts the load balancer assumes that the server is down and does not send sessions to it. The health check monitor configuration determines how the load balancer tests the real servers. You can use a single health check monitor for multiple load balancing configurations.

You can configure TCP, HTTP and Ping health check monitors. Usually you would want the health check monitor to use the same protocol for checking the health of the server as the traffic being load balanced to it. For example, for an HTTP load balancing configuration you would normally use an HTTP health check monitor.

For the TCP and HTTP health check monitors you can specify the destination port to use to connect to the real servers. If you set the port to 0, the health check monitor uses the port defined in the real server. This allows you to use the same health check monitor for multiple real servers using different ports. You can also configure the interval, timeout and retry. A health check occurs every number of seconds indicated by the interval. If a reply is not received within the timeout period the health check is repeated every second. If no response is received after the number of configured retires, the virtual server is considered unresponsive, and load balancing does not srend traffic to that real server. The health check monitor will continue to contact the real server and if successful, the load balancer can resume sending sessions to the recovered real server.

The default health check configuration has an interval of 10 seconds, a timeout of 2 seconds and a retry of 3. This means that the health check monitor checks the health of a real server every 10 seconds. If a reply is not received within 2 seconds the health check monitor re-checks the server every second for 3 retries. If no response is received for 2 seconds after the final retry the server is considered unresponsive. This entire process takes a total of 7 seconds to consider a virtual server as unresponsive (2 second timeout + (3 re-checks x 1 second) + 2 second timeout = 7 seconds). Since this health check process is repeated every 10 seconds, a server can be down for a maximum of 10 + 7 = 17 seconds before the health check monitor considers it down.

For HTTP health check monitors, you can add URL that the FortiGate unit connects to when sending a get request to check the health of a HTTP server. The URL should match an actual URL for the real HTTP servers. The URL is optional.

The URL would not usually include an IP address or domain name. Instead it should start with a “/” and be followed by the address of an actual web page on the real server. For example, if the IP address of the real server is 10.31.101.30, the URL “/test_page.htm” causes the FortiGate unit to send an HTTP get request to “http://10.31.101.30/test_page.htm”.

For HTTP health check monitors, you can also add a matched content phrase that a real HTTP server should include in response to the get request sent by the FortiGate unit using the content of the URL option. If the URL returns a web page, the matched content should exactly match some of the text on the web page. You can use the URL and Matched Content options to verify that an HTTP server is actually operating correctly by responding to get requests with expected web pages. Matched content is only required if you add a URL.

Health check monitoring

For example, you can set matched content to “server test page” if the real HTTP server page defined by the URL option contains the phrase “server test page”. When the FortiGate unit receives the web page in response to the URL get request, the system searches the content of the web page for the matched content phrase.

Name

Enter the name of the health check monitor configuration.

Type

Select the protocol used to perform the health check.

l TCP l HTTP l PING

Port

Enter the port number used to perform the health check. If you set the Port to 0, the health check monitor uses the port defined in the real server. This way you can use a single health check monitor for different real servers.

This option does not appear if the Type is PING.

Interval

Enter the number of seconds between each server health check.

URL

For HTTP health check monitors, add a URL that the FortiGate unit uses when sending a get request to check the health of a HTTP server. The URL should match an actual URL for the real HTTP servers. The URL is optional.

The URL would not usually include an IP address or domain name. Instead it should start with a “/” and be followed by the address of an actual web page on the real server. For example, if the IP address of the real server is 10.10.10.1, the URL “/test_page.htm” causes the FortiGate unit to send an HTTP get request to “http://10.10.10.1/test_page.htm”.

This option appears only if Type is HTTP.

Matched Content

For HTTP health check monitors, add a phrase that a real HTTP server should include in response to the get request sent by the FortiGate unit using the content of the URL option. If the URL returns a web page, the Matched Content should exactly match some of the text on the web page. You can use the URL and Matched Content options to verify that an HTTP server is actually operating correctly by responding to get requests with expected web pages. Matched content is only required if you add a URL.

For example, you can set Matched Content to “server test page” if the real HTTP server page defined by the URL option contains the phrase “server test page”. When the FortiGate unit receives the web page in response to the URL get request, the system searches the content of the web page for the Matched Content phrase.

This option appears only if Type is HTTP.

Load balancing limitations

Max Redirects

For an HTTP health check monitor, specify the maximum number of redirects that the health check monitor will follow when testing the health of the real HTTP server. This feature allows you to do health checking of the HTTP server is accessed through one or more redirects.

Timeout

Enter the number of seconds which must pass after the server health check to indicate a failed health check.

Retry

Enter the number of times, if any, a failed health check will be retried before the server is determined to be inaccessible.

Load balancing limitations

The following limitations apply when adding virtual IPs, load balancing virtual servers, and load balancing real servers. Load balancing virtual servers are actually server load balancing virtual IPs. You can add server load balance virtual IPs from the CLI.

• Virtual IP External IP Address/Range entries or ranges cannot overlap with each other or with load balancing virtual server Virtual Server IP
• A virtual IP Mapped IP Address/Range cannot be 0.0.0.0 or 255.255.255.255. l A real server IP cannot be 0.0.0.0 or 255.255.255.255.
• If a static NAT virtual IP External IP Address/Range is 0.0.0.0, the Mapped IP Address/Range must be a single IP address. l If a load balance virtual IP External IP Address/Range is 0.0.0.0, the Mapped IP Address/Range can be an address range.
• When port forwarding, the count of mapped port numbers and external port numbers must be the same. The GUI does this automatically but the CLI does not. l Virtual IP and virtual server names must be different from firewall address or address group names.

Monitoring load balancing

From the GUI you can go to Monitor > Load Balance Monitor to monitor the status of configured virtual servers and real servers and start or stop the real servers. You can also use the get test ipldb command from the CLI to display similar information.

For each real server the monitor displays health status (up or down), active sessions, round trip time (RTT) and the amount of bytes of data processed. From the monitor page you can also stop sending new sessions to any real server. When you select to stop sending sessions the FortiGate unit performs of graceful stop by continuing to send data for sessions that were established or persistent before you selected stop. However, no new sessions are started.

Real Server

The IP addresses of the existing real servers.

Status

Displays the health status according to the health check results for each real server. A green arrow means the server is up. A red arrow means the server is down.

Mode

The mode of the health check monitor. Can be active, standby, or disabled.

Monitor Events

Display each real server’s up and down times.

Active Sessions

Display each real server’s active sessions.

RTT (ms)

Displays the Round Trip Time (RTT) of each real server. By default, the RTT is “<1”. This value will change only when ping monitoring is enabled on a real server.

Bytes Processed

Displays the traffic processed by each real server.

Graceful Stop/Start

Select to start or stop real servers. When stopping a server, the FortiGate unit will not accept new sessions but will wait for the active sessions to finish.

Load balancing diagnose commands

You can also use the following diagnose commands to view status information for load balancing virtual servers and real servers:

diagnose firewall vip realserver {down | healthcheck | list | up} diagnose firewall vip virtual-server {filter | real-server | stats}

For example, the following command lists and displays status information for all real servers: diagnose firewall vip virtual-server real-server

vd root/0 vs vs/2 addr 10.31.101.30:80 status 1/1 conn: max 0 active 0 attempts 0 success 0 drop 0 fail 0

Load balancing diagnose commands

vd root/0 vs vs/2 addr 10.31.101.20:80 status 1/1 conn: max 0 active 0 attempts 0 success 0 drop 0 fail 0

Many of the diagnostic commands involve retrieving information about one or more virtual servers. To control which servers are queried you can define a filter:

diagnose firewall vip virtual-server filter <filter_str> Where <filter_str> can be:

l clear erase the current filter l dst the destination address range to filter by l dst-port the destination port range to filter by l list display the current filter l name the vip name to filter by l negate negate the specified filter parameter l src the source address range to filter by l src-port the source port range to filter by l vd index of virtual domain. -1 matches all

The default filter is empty so no filtering is done.

Logging diagnostics

The logging diagnostics provide information about two separate features:

diagnose firewall vip virtual-server filter

l filter sets a filter for the virtual server debug log l The filter option controls what entries the virtual server daemon will log to the console if diagnose debug application vs level is non-zero. The filtering can be done on source, destination, virtual-server name, virtual domain, and so on:

diagnose firewall vip virtual-server filter <filter_str> Where <filter_str> can be l clear erase the current filter l dst the destination address range to filter by l dst-port the destination port range to filter by l list display the current filter l name the virtual-server name to filter by l negate negate the specified filter parameter l src the source address range to filter by l src-port the source port range to filter by l vd index of virtual domain. -1 matches all

The default filter is empty so no filtering is done.

Real server diagnostics

Enter the following command to list all the real servers:

diagnose firewall vip virtual-server real-server list

In the following example there is only one virtual server called slb and it has two real-servers:

diagnose firewall vip virtual-server server

Load balancing diagnose commands

vd root/0 vs slb/2 addr 172.16.67.191:80 status 1/1 conn: max 10 active 0 attempts 0 success 0 drop 0 fail 0 http: available 0 total 0

vd root/0 vs slb/2 addr 172.16.67.192:80 status 1/1 conn: max 10 active 1 attempts 4 success 4 drop 0 fail 0 http: available 1 total 1

The status indicates the administrative and operational status of the real-server.

• max indicates that the real-server will only allow 10 concurrent connections.
• active is the number of current connections to the server attempts is the total number of connections attempted success is the total number of connections that were successful.
• drop is the total number of connections that were dropped because the active count hit max.
• fail is the total number of connections that failed to complete due to some internal problem (for example, lack of memory).

If the virtual server has HTTP multiplexing enabled then the HTTP section indicates how many established connections to the real-sever are available to service a HTTP request and also the total number of connections.

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. See SSL/TLS load balancing on page 36.

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 GUI, 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 GUI 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 to be able to see the original client IP address in log messages on the destination web server. If this option is not selected, the X-Forwarded-For HTTP header contains the IP address of the FortiGate unit.

Preserving the client IP address in a different HTTP header

If you select preserve client IP from the GUI or enable the http-ip-header option from the CLI you can also preserve the client IP in a different HTTP header. This can be useful if you want to use a custom header name instead of X-Forwarded-For.

You can add the custom 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 name the X-Forwarded-For header is used.

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 serverload-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

HTTP and HTTPS

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 balance 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

next end 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

set port 80 next end

end

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/TLS offloading

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

To configure SSL offloading from the GUI 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 Full).

Select Client <-> FortiGate to apply hardware accelerated SSL/TLS 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 Full 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. The segment between the FortiGate unit and the server uses encrypted communications, but the handshakes are abbreviated. This is not as efficient as half mode SSL offloading, but still improves performance. As well, full-mode SSL offloading 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 (Half Mode and Full Mode)

Configuring SSL offloading also requires selecting a certificate to use for the SSL offloading sessions. SSL offloading supports key sizes up to 4096. FortiGate models with CP9 processors support 3072 and 4096 DH bit sizes in hardware. All FortiGate models up to and including those with CP8 processors only support offloading DH bit sizes up to 2048 so any sizes larger than that are done in software and thus are relatively resource intensive

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

Separate virtual-server client and server TLS version and cipher configuration

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

Separate virtual-server client and server TLS version and cipher configuration

In some cases, you may want the to use different versions of SSL or TLS on the client to FortiGate connection than on the FortiGate to server connection. For example, you may want to use the FortiGate to protect a legacy SSL 3.0 or TLS 1.0 server while making sure that client to FortiGate connections must always use the higher level of protection offered by TLS 1.1 or greater. Also, in some cases you might want to protect a server that only has weak ciphers (for example, DES or RC4) while making sure that all connections between the FortiGate and the client use a strong cipher for better protection.

The following options are available when configuring server load balancing for HTTPS sessions configured with the following command:

config firewall vip edit server-name set type server-load-balance set server-type https set ssl-mode full …

Setting the SSL/TLS versions to use for server and client connections

The ssl-server-min-version, ssl-server-max-version, ssl-min-version and ssl-maxversion configuration options allow the minimum and maximum SSL/TLS versions for the client to FortiGate connection to be independent of the FortiGate to server configuration. By default these options are both set to client and the configured ssl-min-version and ssl-max-version settings are applied to both the client and the server connection.

You can change the ssl-server-min-version and ssl-server-max-version to apply different options to the server connection. The ssl-min-version and ssl-max-version settings are still applied to the client connection. If you set the ssl-server-min-version and ssl-server-max-version to an explicit version then both must be set to an explicit version.

The ssl-server-min-version and ssl-server-max-version options allow you to specify the minimum and maximum SSL/TLS versions the FortiGate will offer to the server (in the record header of the ClientHello) when performing full mode SSL offloading and thus the minimum and maximum SSL/TLS versions the FortiGate accepts from the server (in a ServerHello). If the server responds with a version in its ServerHello Setting the SSL/TLS cipher choices for server and client connections

that is lower than ssl-server-min-version or higher than the ssl-server-max-version then the FortiGate terminates the connection.

Command syntax is:

config firewall vip edit server-name set type server-load-balance set server-type https set ssl-mode full set ssl-min-version {ssl-3.0 | tls-1.0 | tls-1.1 | tls-1.2} set ssl-max-version {ssl-3.0 | tls-1.0 | tls-1.1 | tls-1.2} set ssl-server-min-version {ssl-3.0 | tls-1.0 | tls-1.1 | tls-1.2 | client} set ssl-server-max-version {ssl-3.0 | tls-1.0 | tls-1.1 | tls-1.2 | client}

Setting the SSL/TLS cipher choices for server and client connections

The ssl-algorithm and ssl-server-algorithm configuration options allow the cipher choice for the FortiGate to server connection to be independent of the client to FortiGate connection. By default, sslserver-algorithm is set to client and the configured ssl-algorithm setting is applied to both the client and the server connection.

You can change the ssl-server-algorithm to apply different options to the server connection. The sslalgorithm setting is still applied to the client connection. The following ssl-server-algorithm options are available:

• high, offer AES or 3DES cypher suites in the ServerHello l medium, use AES, 3DES, or RC4 cypher suites in the ServerHello l low, use AES, 3DES, RC4, or DES cypher suites in the ServerHello l custom, specifiy custom cypher suites using the config ssl-server-cipher-suites and offer these custom cypher suites in the ServerHello.
• client, offer the cypher suites in the ServerHello that are offered in the ClientHello.

Command syntax is:

config firewall vip edit server-name set type server-load-balance set server-type https set ssl-mode full

set ssl-algorithm {high | medium | low | custom}

set ssl-server-algorithm {high | medium | low | custom | client}

If you set ssl-server-algorithm to custom, the syntax is: config firewall vip edit server-name set type server-load-balance set server-type https set ssl-mode full

set ssl-server-algorithm custom config ssl-server-cipher-suites edit 10 set cipher <cipher-suite>

set versions {ssl-3.0 | tls-1.0 | tls-1.1 | tls-1.2}

Protection from TLS protocol downgrade attacks

next edit 20 set cipher <cipher-suite>

set versions {ssl-3.0 | tls-1.0 | tls-1.1 | tls-1.2} end

Protection from TLS protocol downgrade attacks

The ssl-client-fallback option, when enabled (the default configuration), performs downgrade attack prevention (RFC 7507).

Command syntax is:

config firewall vip edit server-name set type server-load-balance set server-type https set ssl-client-fallback {disable | enable}

Setting 3072- and 4096-bit Diffie-Hellman values

The ssl-dh-bits option allows you to specify the number of bits of the prime number used in the DiffieHellman exchange for RSA encryption of the SSL connection. Larger prime numbers are associated with greater cryptographic strength. You can set DH values from 768 to 4096 bits.

Command syntax is:

config firewall vip edit server-name set type server-load-balance set server-type https set ssl-dh-bits {768 | 1024 | 1536 | 2048 | 3072 | 4096}

Setting the DH bits to 2048 only provides the equivalent of a symmetric cipher in the range of 112 – 128 bits. This means that if AES 256 is used then the weakest point is the DH of 2048 and a value of at least 3072 should be use if the goal is to have 256 bits of security.

FortiGate models with CP9 processors support 3072 and 4096 DH bit sizes in hardware. All FortiGate models up to and including those with CP8 processors only support offloading DH bit sizes up to 2048 so any sizes larger than that are done in software and thus are relatively resource intensive.

Additional SSL load balancing and SSL offloading 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>

Additional SSL load balancing and SSL offloading options

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-clientsession-state-timeout is exceeded, regardless of which occurs first. l 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-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}

Enable (the default) 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-send-empty-frags {enable | disable}

Select to precede the record with empty fragments to protect from 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-serversession-state-timeout is exceeded, regardless of which occurs first. l count: Select to expire SSL session states when ssl-server-session-state-max is exceeded.
• disable: Select to keep no SSL session states. l time: Select to expire SSL session states when ssl-server-session-state-timeout is exceeded.

SSL offloading support for 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 type server-load-balance set server-type https 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 renegotiation 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 renegotiation 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 —

Disabling SSL/TLS re-negotiation

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-clientrenegotation 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

Disabling SSL/TLS re-negotiation

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

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.

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.

Virtual server configuration example

GUI configuration

Use the following procedures to configure this load balancing setup from the GUI.

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”.

4. Select OK.

To add the HTTP virtual server and the real servers

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.

4. Add three real servers to the virtual server. Each real server must include the IP address of a real server on the internal network.

Configuration for the first real server.

Configuration for the second real server.

Configuration for the third real server.

HTTP load balancing to three real web servers

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:

4. Select other security policy options as required.
5. Select OK.

Building security into FortiOS

The FortiOS operating system, FortiGate hardware devices, and FortiOS virtual machines (VMs) are built with security in mind, so many security features are built into the hardware and software. Fortinet maintains an ISO:9001 certified software and hardware development processes to ensure that FortiOS and FortiGate products are developed in a secure manner

Boot PROM and BIOS security

The boot PROM and BIOS in FortiGate hardware devices use Fortinet’s own FortiBootLoader that is designed and controlled by Fortinet. FortiBootLoader is a secure, proprietary BIOS for all FortiGate appliances. FortiGate physical devices always boot from FortiBootLoader.

FortiOS kernel and user processes

FortiOS is a multi-process operating system with kernel and user processes. The FortiOS kernel runs in a privileged hardware mode while higher-level applications run in user mode. FortiOS is a closed system that does not allow the loading or execution of third-party code in the FortiOS user space. All non-essential services, packages, and applications are removed.

FortiGate appliances with SD drives are encrypted to prevent unauthorized access to data.

Administration access security

Admin administrator account

All FortiGate firewalls ship with a default administrator account called admin. By default, this account does not have a password. FortiOS allows administrators to add a password for this account or to remove the account and create new custom super_admin administrator accounts.

Secure password storage

User and administrator passwords are stored securely on the system in an encrypted format. The encryption hash used for admin account passwords is SHA256/SHA1. The value that is seen in the configuration file is the Base64 encoded hash value. For example:

config system admin edit “admin” set accprofile “super_admin”

set vdom “root”

set password ENC SH2nlSm9QL9tapcHPXIqAXvX7vBJuuqu22hpa0JX0sBuKIo7z2g0Kz/+0KyH4E=

next end

Pre-shared keys in IPSec phase-1 configurations are stored in plain text. In the configuration file these pre-shared keys are encoded. The encoding consists of encrypting the password with a fixed key using DES (AES in FIPS mode) and then Base64 encoding the result.

Maintainer account

Administrators with physical access to a FortiGate appliance can use a console cable and a special administrator account called maintainer to log into the CLI. When enabled, the maintainer account can be used to log in from the console after a hard reboot. The password for the maintainer account is bcpb followed by the FortiGate serial number. An administrator has 60-seconds to complete this login. See Resetting a lost Admin password on the Fortinet Cookbook for details.

The only action the maintainer account has permissions to perform is to reset the passwords of super_admin accounts. Logging in with the maintainer account requires rebooting the FortiGate. FortiOS generates event log messages when you login with the maintainer account and for each password reset.

The maintainer account is enabled by default; however, there is an option to disable this feature. The maintainer account can be disabled using the following command:

config system global set admin-maintainer disable

end

Administrative access security

Secure administrative access features:

• SSH, Telnet, and SNMP are disabled by default. If required, these admin services must be explicitly enabled on each interface from the GUI or CLI.
• SSHv1 is disabled by default. SSHv2 is the default version.
• SSLv3 and TLS1.0 are disabled by default. TLSv1.1 and TLSv1.2 are the SSL versions enabled by default for HTTPS admin access.
• HTTP is disabled by default, except on dedicated MGMT, DMZ, and predefined LAN interfaces. HTTP redirect to HTTPS is enabled by default. l The strong-crypto global setting is enabled by default and configures FortiOS to use strong ciphers (AES, 3DES) and digest (SHA1) for HTTPS/SSH/TLS/SSL functions. l SCP is disabled by default. Enabling SCP allows downloading the configuration file from the FortiGate as an alternative method of backing up the configuration file. To enable SCP:

config system global set admin-scp enable

end

• DHCP is enabled by default on the dedicated MGMT interface and on the predefined LAN port (defined on some FortiGate models).
• The default management access configuration for FortiGate models with dedicated MGMT, DMZ, WAN, and LAN interfaces is shown below. Outside of the interfaces listed below, management access must be explicitly enabled on interfaces – management services are enabled on specific interfaces and not globally.
• Dedicated management interface l Ping l FMG-Access (fgfm) l CAPWAP l HTTPS l HTTP
• Dedicated WAN1/WAN2 interface l Ping l FMG-Access (fgfm)
• Dedicated DMZ interface l Ping l FMG-Access (fgfm) l CAPWAP l HTTPS l HTTP
• Dedicated LAN interface l Ping l FMG-Access (fgfm) l CAPWAP l HTTPS l HTTP

Network security

This section describes FortiOS and FortiGate network security features.

Network interfaces

The following are disabled by default on each FortiGate interface:

l Broadcast forwarding l STP forwarding l VLAN forwarding l L2 forwarding l Netbios forwarding l Ident accept

For more information, see Disable unused protocols on interfaces on page 20.

TCP sequence checking

FortiOS uses TCP sequence checking to ensure a packet is part of a TCP session. By default, anti-replay protection is strict, which means that if a packet is received with sequence numbers that fall out of the expected range, FortiOS drops the packet. Strict anti-replay checking performs packet sequence checking and ICMP antireplay checking with the following criteria:

• The SYN, FIN, and RST bit cannot appear in the same packet.
• FortiOS does not allow more than 1 ICMP error packet to go through before it receives a normal TCP or UDP packet.
• If FortiOS receives an RST packet, FortiOS checks to determine if its sequence number in the RST is within the unACKed data and drops the packet if the sequence number is incorrect. l For each new session, FortiOS checks to determine if the TCP sequence number in a SYN packet has been calculated correctly and started from the correct value.

Reverse path forwarding

FortiOS implements a mechanism called Reverse Path Forwarding (RPF), or Anti Spoofing, to block an IP packet from being forwarded if its source IP does not:

l belong to a locally attached subnet (local interface), or l be in the routing domain of the FortiGate from another source (static route, RIP, OSPF, BGP).

If those conditions are not met, FortiOS silently drops the packet.

FIPS and Common Criteria

FortiOS has received NDPP, EAL2+, and EAL4+ based FIPS and Common Criteria certifications. Common Criteria evaluations involve formal rigorous analysis and testing to examine security aspects of a product or system. Extensive testing activities involve a comprehensive and formally repeatable process, confirming that the security product functions as claimed by the manufacturer. Security weaknesses and potential vulnerabilities are specifically examined during an evaluation.

To see Fortinet’s complete history of FIPS/CC certifications go to the following URL and add Fortinet to the Vendor field:

https://csrc.nist.gov/projects/cryptographic-module-validation-program/validated-modules/search

PSIRT advisories

The FortiGuard Labs Product Security Incident Response Team (PSIRT) continually tests and gathers information about Fortinet hardware and software products, looking for vulnerabilities and weaknesses. Any such findings are fed back to Fortinet’s development teams and serious issues are described along with protective solutions. The PSIRT regulatory releases PSIRT advisories when issues are found and corrected. Advisories are listed at https://www.fortiguard.com/psirt.

Introduction to wireless networking

Wireless concepts

Wireless networking is radio technology, subject to the same characteristics and limitations as the familiar audio and video radio communications. Various techniques are used to modulate the radio signal with a data stream.

Bands and channels

Depending on the wireless protocol selected, you have specific channels available to you, depending on what region of the world you are in.

l IEEE 802.11b and g protocols provide up to 14 channels in the 2.400-2.500 GHz Industrial, Scientific and Medical (ISM) band. l IEEE 802.11a,n (5.150-5.250, 5.250-5.350, 5.725–5.875 GHz, up to 16 channels) in portions of Unlicensed National Information Infrastructure (U-NII) band

Note that the width of these channels exceeds the spacing between the channels. This means that there is some overlap, creating the possibility of interference from adjacent channels, although less severe than interference on the same channel. Truly non-overlapping operation requires the use of every fourth or fifth channel, for example ISM channels 1, 6 and 11.

The capabilities of your wireless clients is the deciding factor in your choice of wireless protocol. If your clients support it, 5GHz protocols have some advantages. The 5GHz band is less used than 2.4GHz and its shorter wavelengths have a shorter range and penetrate obstacles less. All of these factors mean less interference from other access points, including your own.

When configuring your WAP, be sure to correctly select the Geography setting to ensure that you have access only to the channels permitted for WiFi use in your part of the world.

For detailed information about the channel assignments for wireless networks for each supported wireless protocol, see Reference on page 182.

Power

Wireless LANs operate on frequencies that require no license but are limited by regulations to low power. As with other unlicensed radio operations, the regulations provide no protection against interference from other users who are in compliance with the regulations.

Power is often quoted in dBm. This is the power level in decibels compared to one milliwatt. 0dBm is one milliwatt, 10dBm is 10 milliwatts, 27dBm, the maximum power on Fortinet FortiAP equipment, is 500 milliwatts. The FortiGate unit limits the actual power available to the maximum permitted in your region as selected by the WiFi controller country setting.

Received signal strength is almost always quoted in dBm because the received power is very small. The numbers are negative because they are less than the one milliwatt reference. A received signal strength of -60dBm is one millionth of a milliwatt or one nanowatt.

Antennas

Transmitted signal strength is a function of transmitter power and antenna gain. Directional antennas concentrate the signal in one direction, providing a stronger signal in that direction than would an omnidirectional antenna.

FortiWiFi units have detachable antennas. However, these units receive regulatory approvals based on the supplied antenna. Changing the antenna might cause your unit to violate radio regulations.

Security

There are several security issues to consider when setting up a wireless network.

Whether to broadcast SSID

It is highly recommended to broadcast the SSID. This makes connection to a wireless network easier because most wireless client applications present the user with a list of network SSIDs currently being received. This is desirable for a public network.

Attempting to obscure the presence of a wireless network by not broadcasting the SSID does not improve network security. The network is still detectable with wireless network “sniffer” software. Clients search for SSIDs that they know, leaking the SSID. Refer to RFC 3370. Also, many of the latest Broadcom drivers do not support hidden SSID for WPA2.

Encryption

Wireless networking supports the following security modes for protecting wireless communication, listed in order of increasing security.

None — Open system. Any wireless user can connect to the wireless network.

WEP64 — 64-bit Web Equivalent Privacy (WEP). This encryption requires a key containing 10 hexadecimal digits.

WEP128 — 128-bit WEP. This encryption requires a key containing 26 hexadecimal digits.

WPA — 256-bit WiFi Protected Access (WPA) security. This encryption can use either the TKIP or AES encryption algorithm and requires a key of either 64 hexadecimal digits or a text phrase of 8 to 63 characters. It is also possible to use a RADIUS server to store a separate key for each user.

WPA2 — WPA with security improvements fully meeting the requirements of the IEEE 802.11i standard. Configuration requirements are the same as for WPA.

For best security, use the WPA2 with AES encryption and a RADIUS server to verify individual credentials for each user. WEP, while better than no security at all, is an older algorithm that is easily compromised. With either WEP or WAP, changing encryption passphrases on a regular basis further enhances security.

Separate access for employees and guests

Wireless access for guests or customers should be separate from wireless access for your employees. Each of the two networks can have its own SSID, security settings, firewall policies, and user authentication. This does not require additional hardware. Both FortiWiFi units and FortiAP units support multiple wireless LANs on the same access point.

A good practice is to broadcast the SSID for the guest network to make it easily visible to users, but not to broadcast the SSID for the employee network.

Two separate wireless networks are possible because multiple virtual APs can be associated with an AP profile. The same physical APs can provide two or more virtual WLANs.

Captive portal

As part of authenticating your users, you might want them to view a web page containing your acceptable use policy or other information. This is called a captive portal. No matter what URL the user initially requested, the portal page is returned. Only after authenticating and agreeing to usage terms can the user access other web resources.

Power

Reducing power reduces unwanted coverage and potential interference to other WLANs. Areas of unwanted coverage are a potential security risk. There are people who look for wireless networks and attempt to access them. If your office WLAN is receivable out on the public street, you have created an opportunity for this sort of activity.

Monitoring for rogue APs

It is likely that there are APs available in your location that are not part of your network. Most of these APs belong to neighboring businesses or homes. They may cause some interference, but they are not a security threat. There is a risk that people in your organization could connect unsecured WiFi-equipped devices to your wired network, inadvertently providing access to unauthorized parties. The optional On-Wire Rogue AP Detection Technique compares MAC addresses in the traffic of suspected rogues with the MAC addresses on your network. If wireless traffic to non-Fortinet APs is also seen on the wired network, the AP is a rogue, not an unrelated AP.

Decisions about which APs are rogues are made manually on the Rogue AP monitor page. For detailed information, see Wireless network monitoring on page 115.

Suppressing rogue APs

When you have declared an AP to be a rogue, you have the option of suppressing it. To suppress and AP, the FortiGate WiFi controller sends reset packets to the rogue AP. Also, the MAC address of the rogue AP is blocked in the firewall policy. You select the suppression action on the Rogue AP monitor page. For more information, see Wireless network monitoring on page 115.

Wireless Intrusion Detection (WIDS)

You can create a WIDS profile to enable several types of intrusion detection:

l Unauthorized Device Detection l Rogue/Interfering AP Detection l Ad-hoc Network Detection and Containment l Wireless Bridge Detection l Misconfigured AP Detection l Weak WEP Detection l Multi Tenancy Protection l MAC OUI Checking

Authentication

Wireless networks usually require authenticated access. FortiOS authentication methods apply to wireless networks the same as they do to wired networks because authentication is applied in the firewall policy.

The types of authentication that you might consider include:

l user accounts stored on the FortiGate l user accounts managed and verified on an external RADIUS, LDAP or TACACS+ server l Windows Active Directory authentication, in which users logged on to a Windows network are transparently authenticated to use the wireless network.

This FortiWiFi and FortiAP Configuration Guide provides some information about each type of authentication, but more detailed information is available in the Authentication chapter of the FortiOS Handbook.

What all of these types of authentication have in common is the definition of user groups to specify who is authorized. For each wireless LAN, you will create a user group and add to it the users who can use the WLAN. In the identity-based firewall policies that you create for your wireless LAN, you will specify this user group.

Some access points, including FortiWiFi units, support MAC address filtering. You should not rely on this alone for authentication. MAC addresses can be “sniffed” from wireless traffic and used to impersonate legitimate clients.

Wireless networking equipment

Fortinet produces two types of wireless networking equipment:

• FortiWiFi units, which are FortiGate units with a built-in wireless access point/client
• FortiAP units, which are wireless access points that you can control from any FortiGate unit that supports the WiFi Controller featu

FortiWiFi units

A FortiWiFi unit can:

• Provide an access point for clients with wireless network cards. This is called Access Point mode, which is the default

or

• Connect the FortiWiFi unit to another wireless network. This is called Client mode. A FortiWiFi unit operating in client mode can only have one wireless interface.

or

• Monitor access points within radio range. This is called Monitoring mode. You can designate the detected access points as Accepted or Rogue for tracking purposes. No access point or client operation is possible in this mode. But, you can enable monitoring as a background activity while the unit is in Access Point mode.

The Products section of the Fortinet web site (www.fortinet.com) provides detailed information about the FortiWiFi models that are currently available.

FortiAP units

FortiAP units are thin wireless access points are controlled by either a FortiGate unit or FortiCloud service.

FortiAP is a family of Indoor, Outdoor and Remote Access Point models supporting the latest single, dual, and triple stream MIMO 802.11ac and 802.11n technology, as well as 802.11g and 802.11a.

For large deployments, some FortiAP models support a mesh mode of operation in which control and data backhaul traffic between APs and the controller are carried on a dedicated WiFi network. Users can roam seamlessly from one AP to another.

In dual-radio models, each radio can function as an AP or as a dedicated monitor. The monitoring function is also available during AP operation, subject to traffic levels.

The Products section of the Fortinet web site (www.fortinet.com) provides detailed information about the FortiAP models that are currently available.

Automatic Radio Resource Provisioning

To prevent interference between APs, the FortiOS WiFi Controller includes the Distributed Automatic Radio Resource Provisioning (DARRP) feature. Through DARRP, each FortiAP unit autonomously and periodically determines the channel that is best suited for wireless communications. FortiAP units to select their channel so Automatic Radio Resource Provisioning

that they do not interfere with each other in large-scale deployments where multiple access points have overlapping radio ranges.

To enable ARRP – GUI

1. Go to WiFi Controller > FortiAP Profiles and edit the profile for your device.
2. In the Radio sections (Radio 1, Radio 2, etc.), enable Radio Resource Provision.
3. Click OK.

To enable ARRP – CLI

In this example, ARRP is enabled for both radios in the FAP321C-default profile:

config wireless-controller wtp-profile edit FAP321C-default config radio-1 set darrp enable

end config radio-2 set darrp enable

end

end

Setting ARRP timing

By default, ARRP optimization occurs at a fixed interval of 1800 seconds (30 minutes). You can change this interval in the CLI. For example, to change the interval to 3600 seconds enter:

config wireless-controller timers set darrp-optimize 3600

end

Optionally, you can schedule optimization for fixed times. This enables you to confine ARRP activity to a lowtraffic period. Setting darrp-optimize to 0, makes darrp-day and darrp-time available. For example, here’s how to set DARRP optimization for 3:00am every day:

config wireless-controller timers set darrp-optimize 0

set darrp-day sunday monday tuesday wednesday thursday friday saturday set darrp-time 03:00

end

Both darrp-day and darrp-time can accept multiple entries.

Introduction and supported models

This guide provides release information for FortiOS 6.2.0 build 0866.

For FortiOS documentation, see the Fortinet Document Library.

Supported models

FortiOS 6.2.0 supports the following models.

Special Notices

• FortiGuard Security Rating Service l FortiGate hardware limitation l CAPWAP traffic offloading
• FortiClient (Mac OS X) SSL VPN requirements l Use of dedicated management interfaces (mgmt1 and mgmt2) l Using FortiAnalyzer units running older versions on page 8

FortiGuard Security Rating Service

Not all FortiGate models can support running the FortiGuard Security Rating Service as a Fabric “root” device. The following FortiGate platforms can run the FortiGuard Security Rating Service when added to an existing Fortinet Security Fabric managed by a supported FortiGate model: l FGR-30D l FGR-35D l FGT-30E l FGT-30E-MI l FGT-30E-MN l FGT-50E l FGT-51E l FGT-52E l FWF-30E l FWF-30E-MI l FWF-30E-MN l FWF-50E-2R l FWF-50E l FWF-51E

FortiGate hardware limitation

FortiOS 5.4.0 reported an issue with the FG-92D model in the Special Notices > FG-92D High Availability in Interface Mode section of the release notes. Those issues, which were related to the use of port 1 through 14, include:

• PPPoE failing, HA failing to form. l IPv6 packets being dropped. l FortiSwitch devices failing to be discovered. l Spanning tree loops may result depending on the network topology.

Special Notices                                                                                                                                                          7

FG-92D does not support STP. These issues have been improved in FortiOS 5.4.1, but with some side effects with the introduction of a new command, which is enabled by default:

config global set hw-switch-ether-filter <enable | disable>

When the command is enabled:

• ARP (0x0806), IPv4 (0x0800), and VLAN (0x8100) packets are allowed. l BPDUs are dropped and therefore no STP loop results. l PPPoE packets are dropped. l IPv6 packets are dropped. l FortiSwitch devices are not discovered. l HA may fail to form depending the network topology.

When the command is disabled:

• All packet types are allowed, but depending on the network topology, an STP loop may result.

CAPWAP traffic offloading

CAPWAP traffic will not offload if the ingress and egress traffic ports are on different NP6 chips. It will only offload if both ingress and egress ports belong to the same NP6 chip. The following models are affected: l FG-900D l FG-1000D l FG-2000E l FG-2500E

FortiClient (Mac OS X) SSL VPN requirements

When using SSL VPN on Mac OS X 10.8, you must enable SSLv3 in FortiOS.

Use of dedicated management interfaces (mgmt1 and mgmt2)

For optimum stability, use management ports (mgmt1 and mgmt2) for management traffic only. Do not use management ports for general user traffic.

Special Notices

Using FortiAnalyzer units running older versions

When using FortiOS 6.2.0 with FortiAnalyzer units running 5.6.5 or lower, or 6.0.0-6.0.2, FortiAnalyzer might report increased bandwidth and session counts if there are sessions that last longer than two minutes.

For accurate bandwidth and session counts, upgrade the FortiAnalyzer unit to 5.6.6 or higher, or 6.0.2 or higher.

Changes in default behavior

Firewall

Remove dependency of ssl-ssh-profile on utm-status under firewall policy (531885).

Log & Report

Starting from the 6.2.0 release, exe log list displays the result of the current log device.

Separate policy and address log-uuid options into two individual options.

System

Starting from the 6.2.0 release, Global admin can only back up but not restore the configuration file. default behavior

Devices configured under security-exempt-list are void after upgrading to 6.2.0.

Changes in CLI defaults

Anti-Spam

Rename spamfilter to emailfilter.

Data Leak Prevention

Rename DLP fp-sensitivity to sensitivity.

Firewall

Rename utm-inspection-mode to inspection-mode under firewall policy.

Add a new direction command to Internet service group. Members are filtered according to the direction selected. The direction of a group cannot be changed after it is set.

FortiView

The following FortiView CLI has been changed in this release.

HA

The CLI command for HA member management is changed.

Intrusion Prevention

Move Botnet configuration option from interface level and policy level to IPS profile.

IPsec VPN

Add net-device option under static/DDNS tunnel configuration.

Log & Report

Move botnet-connection detection from malware to log threat-weight.

SDS.

Add new certificate verification option under FortiAnalyzer setting.

Proxy

Move SSH redirect option from firewall ssl-ssh-profile to firewall policy.

Move HTTP redirect option from profile protocol option to firewall policy.

Move UTM inspection mode from VDOM setting/AV profile/webfilter profile/emailfilter profile/DLP sensor to firewall policy.

Routing

For compatibility with the API, the CLI command for OSPF MD5 is changed from a single line configuration to sub-table configuration.

The name internet-service-ctrl and internet-service-ctrl-group is changed to internetservice-app-ctrl and internet-service-app-ctrl-group to specify it’s using application control.

Add cost for each SD-WAN member so that in the SLA mode in a SD-WAN rule, if SLAs are met for each member, the selection is based on the cost.

Add a load-balance mode for SD-WAN rule. When traffic matches this rule, this traffic should be distributed based on the LB algorithm.

Security Fabric

Add control to collect private or public IP address in SDN connectors.

Add generic support for integrating ET products (FortiADC, FortiMail, FortiWeb, FortiDDoS, FortiWLC) with Security Fabric.

Add support for multiple SDN connectors under dynamic firewall address.

System

Add split VDOM mode configuration.

WiFi Controller

Remove http and telnet in allowaccess options under wireless-controller wtp-profile and wireless-controller wtp.

Changes in default values

Firewall

The default profile for ssl-ssh-profile is changed from certificate-inspection to no-inspection.

IPsec VPN

The default value for net-device option under dynamic(dialup) tunnel has changed from disable to enable.

Log & Report

The default value, minimum value, and maximum value for memory log is changed.

Changes in default values                                                                                                                                         21

Routing

The default SD-WAN health-check interval is changed from 1 to 500 and the unit is changed from seconds to milliseconds.

The default link-monitor interval is changed from 1 to 500 and the unit is changed from seconds to milliseconds.

System

The default protocol used for FortiGuard service communication is changed from UDP to HTTPS.

The protocol setting remains unchanged for FortiGates upgrading from v6.0 to v6.2.

Changes in default values

Switch Controller

The default value for FortiLink split interface is changed from disable to enable.

WiFi Controller

The default value of broadcast-suppression under wireless vap is changed from dhcp-up arp-known to dhcp-up arp-known dhcp-ucast.

The default value of control-message-offload under wireless-controller wtp-profile is changed from ebp-frame aeroscout-tag ap-list sta-list sta-cap-list stats aeroscout-mu to ebpframe aeroscout-tag ap-list sta-list sta-cap-list stats aeroscout-mu sta-health.

Upgrade Information

Supported upgrade path information is available on the Fortinet Customer Service & Support site.

To view supported upgrade path information:

1. Go to https://support.fortinet.com.
2. From the Download menu, select Firmware Images.
3. Check that Select Product is FortiGate.
4. Click the Upgrade Path tab and select the following:

l Current Product l Current FortiOS Version l Upgrade To FortiOS Version

5. Click Go.

FortiClient Endpoint Telemetry license

Starting with FortiOS 6.2.0, the FortiClient Endpoint Telemetry license is deprecated and as a result there are two upgrade scenarios:

• Customers using only a FortiGate device in FortiOS 6.0 to enforce compliance must install FortiClient EMS 6.2.0 and purchase a FortiClient Security Fabric Agent License.
• Customers using both a FortiGate device in FortiOS 6.0 and FortiClient EMS running 6.0 for compliance enforcement, must upgrade both the FortiGate device to FortiOS 6.2.0, FortiClient to 6.2.0, and FortiClient EMS to 6.2.0.

Fortinet Security Fabric upgrade

FortiOS 6.2.0 greatly increases the interoperability between other Fortinet products. This includes:

l FortiAnalyzer 6.2.0 l FortiClient EMS 6.2.0 l FortiClient 6.2.0 l FortiAP 5.4.4 and later l FortiSwitch 3.6.9 and later

Upgrade the firmware of each product in the correct order. This maintains network connectivity without the need to use manual steps.

If Security Fabric is enabled, then all FortiGate devices must be upgraded to 6.2.0. When Security Fabric is enabled in FortiOS 6.2.0, all FortiGate devices must be running FortiOS 6.2.0.

Minimum version of TLS services automatically changed

For improved security, FortiOS 6.2.0 uses the ssl-min-proto-version option (under config system global) to control the minimum SSL protocol version used in communication between FortiGate and third-party SSL and TLS services.

When you upgrade to FortiOS 6.2.0 and later, the default ssl-min-proto-version option is TLS v1.2. The following SSL and TLS services inherit global settings to use TLS v1.2 as the default. You can override these settings.

l Email server (config system email-server) l Certificate (config vpn certificate setting) l FortiSandbox (config system fortisandbox) l FortiGuard (config log fortiguard setting) l FortiAnalyzer (config log fortianalyzer setting) l LDAP server (config user ldap) l POP3 server (config user pop3)

Downgrading to previous firmware versions

Downgrading to previous firmware versions results in configuration loss on all models. Only the following settings are retained:

l operation mode l interface IP/management IP l static route table l DNS settings l admin user account l session helpers l system access profiles

Amazon AWS enhanced networking compatibility issue

With this enhancement, there is a compatibility issue with older AWS VM versions. After downgrading a 6.2.0 image to an older version, network connectivity is lost. Since AWS does not provide console access, you cannot recover the downgraded image.

When downgrading from 6.2.0 to older versions, running the enhanced nic driver is not allowed. The following AWS instances are affected:

• C3 l C4 l R3 l I2
• M4 l D2

FortiLink access-profile setting

The new FortiLink local-access profile controls access to the physical interface of a FortiSwitch that is managed by FortiGate.

After upgrading FortiGate to 6.2.0, the interface allowaccess configuration on all managed FortiSwitches are overwritten by the default FortiGate local-access profile. You must manually add your protocols to the localaccess profile after upgrading to 6.2.0.

To configure local-access profile:

config switch-controller security-policy local-access edit [Policy Name] set mgmt-allowaccess https ping ssh set internal-allowaccess https ping ssh

next

end

To apply local-access profile to managed FortiSwitch:

config switch-controller managed-switch edit [FortiSwitch Serial Number] set switch-profile [Policy Name] set access-profile [Policy Name]

next

end

FortiGate VM with V-license

This version allows FortiGate VM with V-License to enable split-vdom.

To enable split-vdom:

config system global set vdom-mode [no-vdom | split vdom] end

FortiGate VM firmware

Fortinet provides FortiGate VM firmware images for the following virtual environments:

Citrix XenServer and Open Source XenServer

• .out: Download the 64-bit firmware image to upgrade your existing FortiGate VM installation.
• .out.OpenXen.zip: Download the 64-bit package for a new FortiGate VM installation. This package contains the QCOW2 file for Open Source XenServer.
• .out.CitrixXen.zip: Download the 64-bit package for a new FortiGate VM installation. This package contains the Citrix XenServer Virtual Appliance (XVA), Virtual Hard Disk (VHD), and OVF files.

Linux KVM

• .out: Download the 64-bit firmware image to upgrade your existing FortiGate VM installation.
• .out.kvm.zip: Download the 64-bit package for a new FortiGate VM installation. This package contains QCOW2 that can be used by qemu.

Microsoft Hyper-V

• .out: Download the 64-bit firmware image to upgrade your existing FortiGate VM installation.
• .out.hyperv.zip: Download the 64-bit package for a new FortiGate VM installation. This package contains three folders that can be imported by Hyper-V Manager on Hyper-V 2012. It also contains the file vhd in the Virtual Hard Disks folder that can be manually added to the Hyper-V Manager.

VMware ESX and ESXi

• .out: Download either the 64-bit firmware image to upgrade your existing FortiGate VM installation.
• .ovf.zip: Download either the 64-bit package for a new FortiGate VM installation. This package contains Open Virtualization Format (OVF) files for VMware and two Virtual Machine Disk Format (VMDK) files used by the OVF file during deployment.

Firmware image checksums

The MD5 checksums for all Fortinet software and firmware releases are available at the Customer Service & Support portal, https://support.fortinet.com. After logging in select Download > Firmware Image Checksums, enter the image file name including the extension, and select Get Checksum Code.

FortiGuard update-server-location setting

The FortiGuard update-server-location default setting is different between hardware platforms and VMs. On hardware platforms, the default is any. On VMs, the default is usa.

On VMs, after upgrading from 5.6.3 or earlier to 5.6.4 or later (including 6.0.0 or later), update-server-location is set to usa.

If necessary, set update-server-location to use the nearest or low-latency FDS servers.

To set FortiGuard update-server-location:

config system fortiguard set update-server-location [usa|any]

end

FortiView widgets

FortiView widgets have been rewritten in 6.2.0. FortiView widgets created in previous versions are deleted in the upgrade.

Product Integration and Support

The following table lists FortiOS 6.2.0 product integration and support information:

Language support

The following table lists language support information.

Language support

Language	GUI
English
Chinese (Simplified)
Chinese (Traditional)
French
Japanese
Korean
Portuguese (Brazil)
Spanish

SSL VPN support

SSL VPN standalone client

The following table lists SSL VPN tunnel client standalone installer for the following operating systems.

Operating system and installers

Other operating systems may function correctly, but are not supported by Fortinet.

SSL VPN web mode

The following table lists the operating systems and web browsers supported by SSL VPN web mode.

Supported operating systems and web browsers

Other operating systems and web browsers may function correctly, but are not supported by Fortinet.

SSL VPN host compatibility list

The following table lists the antivirus and firewall client software packages that are supported.

Supported Microsoft Windows XP antivirus and firewall software

Product	Antivirus		Firewall
Symantec Endpoint Protection 11
Kaspersky Antivirus 2009
McAfee Security Center 8.1
Trend Micro Internet Security Pro
F-Secure Internet Security 2009

Supported Microsoft Windows 7 32-bit antivirus and firewall software

Product	Antivirus	Firewall
CA Internet Security Suite Plus Software
AVG Internet Security 2011
F-Secure Internet Security 2011
Kaspersky Internet Security 2011
McAfee Internet Security 2011
Norton 360 Version 4.0
Norton Internet Security 2011
Panda Internet Security 2011
Sophos Security Suite
Trend Micro Titanium Internet Security
ZoneAlarm Security Suite
Symantec Endpoint Protection Small Business Edition 12.0

Resolved Issues

The following issues have been fixed in version 6.2.0. For inquires about a particular bug, please contact Customer Service & Support.

Anti-Spam

AntiVirus

Application Control

Data Leak Prevention

DNS Filter

Endpoint Control

Explicit Proxy

Firewall

FortiView

GUI

HA

ICAP

Intrusion Prevention

IPsec VPN

Log & Report

Proxy

REST API

Routing

Security Fabric

SSL VPN

Switch Controller

System

Upgrade

User & Device

VM

VoIP

WCCP Web Application Firewall

Web Filter

WiFi Controller

Common Vulnerabilities and Exposures

Visit https://fortiguard.com/psirt for more information.

Known Issues

The following issues have been identified in version 6.2.0. For inquires about a particular bug or to report a bug, please contact Customer Service & Support.

Application Control

Data Leak Prevention

Explicit Proxy

FortiView

GUI

HA

Intrusion Prevention

IPsec VPN

Log & Report

Proxy

Security Fabric

SSL VPN

Switch Controller

System

Upgrade

VM

Web Filter

Limitations

Citrix XenServer limitations

The following limitations apply to Citrix XenServer installations:

• XenTools installation is not supported.
• FortiGate-VM can be imported or deployed in only the following three formats:
• XVA (recommended)
• VHD l OVF
• The XVA format comes pre-configured with default configurations for VM name, virtual CPU, memory, and virtual NIC. Other formats will require manual configuration before the first power on process.

Open source XenServer limitations

When using Linux Ubuntu version 11.10, XenServer version 4.1.0, and libvir version 0.9.2, importing issues may arise when using the QCOW2 format and existing HDA issues.

FortiOS ports and protocols

Communication to and from FortiOS is strictly controlled and only selected ports are opened for supported functionality such as administrator logins and communication with other Fortinet products or services.

Accessing FortiOS using an open port is protected by authentication, identification, and encryption requirements. As well, ports are only open if the feature using them is enabled.

FortiOS open ports

The following diagram and tables shows the incoming and outgoing ports that are potentially opened by FortiOS. For more details about open ports and the communication protocols that FortiOS uses, see the document Fortinet Communication Ports and Protocols.

Closing open ports

You can close open ports by disabling the feature that opens them. For example, if FortiOS is not managing a FortiAP then the CAPWAP feature for managing FortiAPs can be disabled, closing the CAPWAP port.

The following sections of this document described a number of options for closing open ports:

Security best practices

This chapter describes some techniques and best practices that you can use to improve FortiOS security.

Install the FortiGate unit in a physically secure location

A good place to start with is physical security. Install your FortiGate in a secure location, such as a locked room or one with restricted access. A restricted location prevents unauthorized users from getting physical access to the device.

If unauthorized users have physical access, they can disrupt your entire network by disconnecting your FortiGate (either by accident or on purpose). They could also connect a console cable and attempt to log into the CLI. Also, when a FortiGate unit reboots, a person with physical access can interrupt the boot process and install different firmware.

Register your product with Fortinet Support

You need to register your Fortinet product with Fortinet Support to receive customer services, such as firmware updates and customer support. You must also register your product for FortiGuard services, such as up-to-date antivirus and IPS signatures. To register your product the Fortinet Support website.

Keep your FortiOS firmware up to date

Always keep FortiOS up to date. The most recent version is the most stable and has the most bugs fixed and vulnerabilities removed. Fortinet periodically updates the FortiGate firmware to include new features and resolve important issues.

After you register your FortiGate, you can receive notifications on FortiGate GUI about firmware updates. You can update the firmware directly from the GUI or by downloading firmware updates from the Fortinet Support website.

Before you install any new firmware, be sure to follow these steps:

• Review the release notes for the latest firmware release.
• Review the Supported Upgrade Paths guide to determine the best path to take from your current version of FortiOS to the latest version.
• Back up the current configuration.

Only FortiGate administrators who have read and write privileges can upgrade the FortiOS firmware.

System administrator best practices

This section describes a collection of changes you can implement to make administrative access to the GUI and CLI more secure.

Disable administrative access to the external (Internet-facing) interface

When possible, don’t allow administration access on the external (Internet-facing) interface.

To disable administrative access, go to Network > Interfaces, edit the external interface and disable HTTPS, PING, HTTP, SSH, and TELNET under Administrative Access.

From the CLI:

config system interface edit <external-interface-name> unset allowaccess

end

Allow only HTTPS access to the GUI and SSH access to the CLI

For greater security never allow HTTP or Telnet administrative access to a FortiGate interface, only allow HTTPS and SSH access. You can change these settings for individual interfaces by going to Network > Interfaces and adjusting the administrative access to each interface.

From the CLI:

config system interface edit <interface-name> set allowaccess https ssh

end

Require TLS 1.2 for HTTPS administrator access

Use the following command to require TLS 1.2 for HTTPS administrator access to the GUI:

config system global set admin-https-ssl-versions tlsv1-2

end

TLS 1.2 is currently the most secure SSL/TLS supported version for SSL-encrypted administrator access.

Re-direct HTTP GUI logins to HTTPS

Go to System > Settings > Administrator Settings and enable Redirect to HTTPS to make sure that all attempted HTTP login connections are redirected to HTTPS.

From the CLI:

config system global set admin-https-redirect enable end

Change the HTTPS and SSH admin access ports to non-standard ports

Go to System > Settings > Administrator Settings and change the HTTPS and SSH ports.

You can change the default port configurations for HTTPS and SSH administrative access for added security. To connect to a non-standard port, the new port number must be included in the collection request. For example:

l If you change the HTTPS port to 7734, you would browse to https://<ip-address>:7734. l If you change the SSH port to 2345, you would connect to ssh admin@<ip-address>:2345 To change the HTTPS and SSH login ports from the CLI:

config system global set admin-sport 7734 set admin-ssh-port 2345

end

If you change to the HTTPS or SSH port numbers, make sure your changes do not conflict with ports used for other services.

Maintain short login timeouts

Set the idle timeout to a short time to avoid the possibility of an administrator walking away from their management computer and leaving it exposed to unauthorized personnel.

To set the administrator idle timeout, go to System > Settings and enter the amount of time for the Idle timeout. A best practice is to keep the default time of 5 minutes.

To set the administrator idle timeout from the CLI:

config system global set admintimeout 5

end

You can use the following command to adjust the grace time permitted between making an SSH connection and authenticating. The range can be between 10 and 3600 seconds, the default is 120 seconds (minutes). By shortening this time, you can decrease the chances of someone attempting a brute force attack a from being successful. For example, you could set the time to 30 seconds.

config system global set admin-ssh-grace-time 30

end

Restrict logins from trusted hosts

Setting up trusted hosts for an administrator limits the addresses from where they can log into FortiOS. The trusted hosts configuration applies to most forms of administrative access including HTTPS, SSH, and SNMP. When you identify a trusted host for an administrator account, FortiOS accepts that administrator’s login only from one of the trusted hosts. A login, even with proper credentials, from a non-trusted host is dropped.

System administrator best practices

To identify trusted hosts, go to System > Administrators, edit the administrator account, enable Restrict login to trusted hosts, and add up to ten trusted host IP addresses.

To add two trusted hosts from the CLI:

config system admin edit <administrator-name> set trustedhost1 172.25.176.23 255.255.255.255 set trustedhost2 172.25.177.0 255.255.255.0

end

Trusted host IP addresses can identify individual hosts or subnets. Just like firewall policies, FortiOS searches through the list of trusted hosts in order and acts on the first match it finds. When you configure trusted hosts, start by adding specific addresses at the top of the list. Follow with more general IP addresses. You don’t have to add addresses to all of the trusted hosts as long as all specific addresses are above all of the 0.0.0.0 0.0.0.0 addresses.

Set up two-factor authentication for administrators

FortiOS supports FortiToken and FortiToken Mobile 2-factor authentication. FortiToken Mobile is available for iOS and Android devices from their respective application stores.

Every registered FortiGate unit includes two trial tokens for free. You can purchase additional tokens from your reseller or from Fortinet.

To assign a token to an administrator, go to System > Administrators and select Enable Two-factor Authentication for each administrator.

Create multiple administrator accounts

Rather than allowing all administrators to access ForiOS with the same administrator account, you can create accounts for each person or each role that requires administrative access. This configuration allows you to track the activities of each administrator or administrative role.

If you want administrators to have different functions you can add different administrator profiles. Go to System > Admin Profiles and select Create New.

Modify administrator account lockout duration and threshold values

By default, the FortiGate sets the number of password retries at three, allowing the administrator a maximum of three attempts to log into their account before locking the account for a set amount of time.

Both the number of attempts (admin-lockout-threshold) and the wait time before the administrator can try to enter a password again (admin-lockout-duration) can be configured within the CLI.

To configure the lockout options:

config system global set admin-lockout-threshold <failed_attempts> set admin-lockout-duration <seconds>

end

The default value of admin-lockout-threshold is 3 and the range of values is between 1 and 10. The admin-lockout-duration is set to 60 seconds by default and the range of values is between 1 and 4294967295 seconds.

Global commands for stronger and more secure encryption

Keep in mind that the higher the lockout threshold, the higher the risk that someone may be able to break into the FortiGate.

Example:

To set the admin-lockout-threshold to one attempt and the admin-lockout-duration to a five minute duration before the administrator can try to log in again, enter the commands:

config system global set admin-lockout-threshold 1 set admin-lockout-duration 300 end

If the time span between the first failed login attempt and the admin-lockoutthreshold failed login attempt is less than admin-lockout-duration, the lockout will be triggered.

Rename the admin administrator account

You can improve security by renaming the admin account. To do this, create a new administrator account with the super_admin admin profile and log in as that administrator. Then go to System > Administrators and edit the admin administrator and change the User Name. Renaming the admin account makes it more difficult for an attacker to log into FortiOS.

Add administrator disclaimers

FortiOS can display a disclaimer before or after logging into the GUI or CLI (or both). In either case the administrator must read and accept the disclaimer before they can proceed.

Use the following command to display a disclaimer before logging in:

config system global set pre-login-banner enable

end

Use the following command to display a disclaimer after logging in:

config system global set post-login-banner enable

end

You can customize the replacement messages for these disclaimers by going to System > Replacement Messages. Select Extended View to view and edit the Administrator replacement messages.

From the CLI:

config system replacemsg admin pre_admin-disclaimer-text config system replacemsg admin post_admin-disclaimer-text

Global commands for stronger and more secure encryption

This section describes some best practices for employing stronger and more secure encryption.

Disable sending malware statistics to FortiGuard

Turn on global strong encryption

Enter the following command to configure FortiOS to use only strong encryption and allow only strong ciphers (AES, 3DES) and digest (SHA1) for HTTPS, SSH, TLS, and SSL functions.

config sys global set strong-crypto enable

end

Disable MD5 and CBC for SSH

In some cases, you may not be able to enable strong encryption. For example, your FortiGate may be communicating with a system that does not support strong encryption. With strong-crypto disabled you can use the following options to prevent SSH sessions with the FortiGate from using less secure MD5 and CBC algorithms:

config sys global set ssh-hmac-md5 disable set ssh-cbc-cipher disable

end

Disable static keys for TLS

You can use the following command to prevent TLS sessions from using static keys (AES128-SHA, AES256-SHA, AES128-SHA256, AES256-SHA256):

config sys global set ssl-static-key-ciphers disable

end

Require larger values for Diffie-Hellman exchanges

Larger Diffie-Hellman values result in stronger encryption. Use the following command to force Diffie-Hellman exchanges to use 8192 bit values (the highest configurable DH value).

config sys global set dh-params 8192

end

Disable sending malware statistics to FortiGuard

By default FortiOS periodically sends encrypted malware statistics to FortiGuard. The malware statistics record Antivirus, IPS, or Application Control events. This data is used to improved FortiGuard services. The malware statistics that FortiOS sends do not include any personal or sensitive customer data. The information is not shared with any external parties and is used in accordance with Fortinet’s Privacy Policy.

To disable sending malware statistics to FortiGuard, enter the following command: config system global set fds-statistics disable

end

Disable sending Security Rating statistics to FortiGuard

Security Rating is a Fortinet Security Fabric feature that allows customers to audit their Security Fabric and find and fix security problems. As part of the feature, FortiOS sends your security rating to FortiGuard every time a security rating test runs.

You can opt out of submitting Security Rating scores to FortiGuard. If you opt out you won’t be able to see how your organization’s scores compare with the scores of other organizations. Instead, an absolute score is shown. Use the following command to disable FortiGuard Security Rating result submission:

config system global set fortiguard-audit-result-submission disable

end

Disable auto USB installation

If USB installation is enabled, an attacker with physical access to a FortiGate could load a new configuration or firmware on the FortiGate using the USB port. You can disable USB installation by entering the following from the CLI:

config system auto-install set auto-install-config disable set auto-install-image disable

end

Set system time by synchronizing with an NTP server

For accurate time, use an NTP server to set system time. Synchronized time facilitates auditing and consistency between expiry dates used in expiration of certificates and security protocols.

From the GUI go to System > Settings > System Time and select Synchronize with NTP Server. By default, this causes FortiOS to synchronize with Fortinet’s FortiGuard secure NTP server.

From the CLI you can use one or more different NTP servers:

config system ntp set type custom set ntpsync enable config ntpserver edit 1 set server <ntp-server-ip>

next edit 2 set server <other-ntp-server-ip> end

Disable the maintainer admin account

Administrators with physical access to a FortiGate appliance can use a console cable and a special administrator account called maintainer to log into the CLI without a password. This feature allows you to log into a FortiGate if you have lost all administrator passwords. See Resetting a lost Admin password on the Fortinet Cookbook for details.

The maintainer account can be disabled using the following command:

config system global set admin-maintainer disable

end

Enable password policies

Go to System > Settings > Password Policy, to create a password policy that all administrators must follow. Using the available options you can define the required length of the password, what it must contain (numbers, upper and lower case, and so on) and an expiry time.

Use the password policy feature to make sure all administrators use secure passwords that meet your organization’s requirements.

Configure auditing and logging

For optimum security go to Log & Report > Log Settings enable Event Logging. For best results send log messages to FortiAnalyzer or FortiCloud.

From FortiAnalyzer or FortiCloud, you can view reports or system event log messages to look for system events that may indicate potential problems. You can also view system events by going to FortiView > System Events.

Establish an auditing schedule to routinely inspect logs for signs of intrusion and probing.

Encrypt logs sent to FortiAnalyzer/FortiManager

To keep information in log messages sent to FortiAnalyzer private, go to Log & Report > Log Settings and when you configure Remote Logging to FortiAnalyzer/FortiManager select Encrypt log transmission.

From the CLI.

config log {fortianalyzer | fortianalyzer2 | fortianalyzer3} setting set enc-algorithm high end

Disable unused interfaces

To disable an interface from the GUI, go to Network > Interfaces. Edit the interface to be disabled and set Interface State to Disabled.

From the CLI, to disable the port21 interface:

config system interface edit port21 set status down

end

Disable unused protocols on interfaces

You can use the config system interface command to disable unused protocols that attackers may attempt to use to gather information about a FortiGate unit. Many of these protocols are disabled by default. Using the config system interface command you can see the current configuration of each of these options for the selected interface and then choose to disable them if required.

config system interface edit <interface-name> set dhcp-relay-service disable set pptp-client disable set arpforward disable set broadcast-forward disable set l2forward disable set icmp-redirect disable set vlanforward disable set stpforward disable set ident-accept disable set ipmac disable set netbios-forward disable set security-mode none set device-identification disable set lldp-transmission disable end

Use local-in policies to close open ports or restrict access

You can also use local-in policies to close open ports or otherwise restrict access to FortiOS.

Close ICMP ports

Use the following command to close all ICMP ports on the WAN1 interface. The following example blocks traffic that matches the ICMP_ANY firewall service.

config firewall local-in-policy edit 1 set intf wan1 set scraddr all set dstaddr all set action deny set service ICMP_ANY set schedule always

end

Close the BGP port

Use the following command to close the BGP port on the wan1 interface. The following example blocks traffic that matches the BGP firewall service.

config firewall local-in-policy edit 1 set intf wan1 set scraddr all set dstaddr all

Use local-in policies to close open ports or restrict access

set action deny set service BGP set schedule always end

Supported RFCs

FortiOS supports the following RFCs.

BGP

l RFC 4724: Graceful Restart Mechanism for BGP l RFC 4456: BGP Route Reflection: An Alternative to Full Mesh Internal BGP (IBGP) l RFC 4360: BGP Extended Communities Attribute l RFC 4271: A Border Gateway Protocol 4 (BGP-4) l RFC 2918: Route Refresh Capability for BGP-4 l RFC 2545: Use of BGP-4 Multiprotocol Extensions for IPv6 Inter-Domain Routing l RFC 2439: BGP Route Flap Damping l RFC 1997: BGP Communities Attribute l RFC 1930: Guidelines for creation, selection, and registration of an Autonomous System (AS) l RFC 1772: Application of the Border Gateway Protocol in the Internet

Cryptography

• RFC 8031: Curve25519 and Curve448 for the Internet Key Exchange Protocol Version 2 (IKEv2) Key Agreement l RFC 7634: ChaCha20, Poly1305, and Their Use in the Internet Key Exchange Protocol (IKE) and IPsec l RFC 7627: Transport Layer Security (TLS) Session Hash and Extended Master Secret Extension l RFC 7539: ChaCha20 and Poly1305 for IETF Protocols l RFC 7427: Signature Authentication in the Internet Key Exchange Version 2 (IKEv2) l RFC 7383: Internet Key Exchange Protocol Version 2 (IKEv2) Message Fragmentation l RFC 7296: Internet Key Exchange Protocol Version 2 (IKEv2) l RFC 7027: Elliptic Curve Cryptography (ECC) Brainpool Curves for Transport Layer Security (TLS) l RFC 6989: Additional Diffie-Hellman Tests for the Internet Key Exchange Protocol Version 2 (IKEv2)
• RFC 6954: Using the Elliptic Curve Cryptography (ECC) Brainpool Curves for the Internet Key Exchange Protocol

Version 2 (IKEv2) l RFC 6290: A Quick Crash Detection Method for the Internet Key Exchange Protocol (IKE) l RFC 6023: A Childless Initiation of the Internet Key Exchange Version 2 (IKEv2) Security Association (SA) l RFC 5723: Internet Key Exchange Protocol Version 2 (IKEv2) Session Resumption l RFC 5282: Using Authenticated Encryption Algorithms with the Encrypted Payload of the Internet Key Exchange version 2 (IKEv2) Protocol

• RFC 5280: Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile l RFC 4754: IKE and IKEv2 Authentication Using the Elliptic Curve Digital Signature Algorithm (ECDSA) l RFC 4635: HMAC SHA TSIG Algorithm Identifiers l RFC 4492: Elliptic Curve Cryptography (ECC) Cipher Suites for Transport Layer Security (TLS)

DHCP

• RFC 4478: Repeated Authentication in Internet Key Exchange (IKEv2) Protocol l RFC 4106: The Use of Galois/Counter Mode (GCM) in IPsec Encapsulating Security Payload (ESP) l RFC 3947: Negotiation of NAT-Traversal in the IKE l RFC 3602: The AES-CBC Cipher Algorithm and Its Use with IPsec l RFC 3526: More Modular Exponential (MODP) Diffie-Hellman groups for Internet Key Exchange (IKE) l RFC 2986: PKCS #10: Certification Request Syntax Specification Version 1.7 l RFC 2845: Secret Key Transaction Authentication for DNS (TSIG) l RFC 2631: Diffie-Hellman Key Agreement Method l RFC 2451: The ESP CBC-Mode Cipher Algorithms l RFC 2410: The NULL Encryption Algorithm and Its Use With IPsec l RFC 2405: The ESP DES-CBC Cipher Algorithm With Explicit IV l RFC 2404: The Use of HMAC-SHA-1-96 within ESP and AH l RFC 2403: The Use of HMAC-MD5-96 within ESP and AH l RFC 2315: PKCS #7: Cryptographic Message Syntax Version 1.5 l RFC 2104: HMAC: Keyed-Hashing for Message Authentication l RFC 2085: HMAC-MD5 IP Authentication with Replay Prevention l RFC 1422: Privacy Enhancement for Internet Electronic Mail: Part II: Certificate-Based Key Management l RFC 1321: The MD5 Message-Digest Algorithm l PKCS #12: PKCS 12 v1: Personal Information Exchange Syntax

DHCP

l RFC 4361: Node-specific Client Identifiers for Dynamic Host Configuration Protocol Version Four (DHCPv4) l RFC 3736: Stateless Dynamic Host Configuration Protocol (DHCP) Service for IPv6 l RFC 3633: IPv6 Prefix Options for Dynamic Host Configuration Protocol (DHCP) version 6 l RFC 3456: Dynamic Host Configuration Protocol (DHCPv4) Configuration of IPsec Tunnel Mode l RFC 3315: Dynamic Host Configuration Protocol for IPv6 (DHCPv6) l RFC 2132: DHCP Options and BOOTP Vendor Extensions l RFC 2131: Dynamic Host Configuration Protocol

Diffserv

l RFC 3260: New Terminology and Clarifications for Diffserv l RFC 2597: Assured Forwarding PHB Group l RFC 2475: An Architecture for Differentiated Services l RFC 2474: Definition of the Differentiated Services Field (DS Field) in the IPv4 and IPv6 Headers 7

DNS

DNS

l RFC 6895: Domain Name System (DNS) IANA Considerations l RFC 6604: xNAME RCODE and Status Bits Clarification l RFC 6147: DNS64: DNS Extensions for Network Address Translation from IPv6 Clients to IPv4 Servers l RFC 4592: The Role of Wildcards in the Domain Name System l RFC 4035: Protocol Modifications for the DNS Security Extensions l RFC 4034: Resource Records for the DNS Security Extensions l RFC 4033: DNS Security Introduction and Requirements l RFC 3597: Handling of Unknown DNS Resource Record (RR) Types l RFC 3226: DNSSEC and IPv6 A6 aware server/resolver message size requirements l RFC 3007: Secure Domain Name System (DNS) Dynamic Update l RFC 2308: Negative Caching of DNS Queries (DNS NCACHE) l RFC 2181: Clarifications to the DNS Specification l RFC 2136: Dynamic Updates in the Domain Name System (DNS UPDATE) l RFC 1996: A Mechanism for Prompt Notification of Zone Changes (DNS NOTIFY) l RFC 1995: Incremental Zone Transfer in DNS l RFC 1982: Serial Number Arithmetic l RFC 1876: A Means for Expressing Location Information in the Domain Name System l RFC 1706: DNS NSAP Resource Records l RFC 1183: New DNS RR Definitions l RFC 1101: DNS Encoding of Network Names and Other Types l RFC 1035: Domain Names – Implementation and Specification l RFC 1034: Domain Names – Concepts and Facilities

ICMP

l RFC 6918: Formally Deprecating Some ICMPv4 Message Types l RFC 6633: Deprecation of ICMP Source Quench Messages l RFC 4884: Extended ICMP to Support Multi-Part Messages l RFC 4443: Internet Control Message Protocol (ICMPv6) for the Internet Protocol Version 6 (IPv6) Specification l RFC 1191: Path MTU Discovery l RFC 792: Internet Control Message Protocol

IP

• RFC 5798: Virtual Router Redundancy Protocol (VRRP) Version 3 for IPv4 and IPv6 l RFC 4301: Security Architecture for the Internet Protocol l RFC 3272: Overview and Principles of Internet Traffic Engineering

IP multicast

• RFC 3168: The Addition of Explicit Congestion Notification (ECN) to IP l RFC 2072: Router Renumbering Guide l RFC 2071: Network Renumbering Overview: Why would I want it and what is it anyway?
• RFC 1918: Address Allocation for Private Internets l RFC 1123: Requirements for Internet Hosts — Application and Support l RFC 1122: Requirements for Internet Hosts — Communication Layers l RFC 791: Internet Protocol

IP multicast

• RFC 5059: Bootstrap Router (BSR) Mechanism for Protocol Independent Multicast (PIM)
• RFC 4604: Using Internet Group Management Protocol Version 3 (IGMPv3) and Multicast Listener Discovery

Protocol Version 2 (MLDv2) for Source-Specific Multicast l RFC 3973: Protocol Independent Multicast – Dense Mode (PIM-DM): Protocol Specification (Revised) l RFC 3956: Embedding the Rendezvous Point (RP) Address in an IPv6 Multicast Address l RFC 3306: Unicast-Prefix-based IPv6 Multicast Addresses l RFC 2365: Administratively Scoped IP Multicast l RFC 1112: Host Extensions for IP Multicasting

IPsec

• RFC 4304: Extended Sequence Number (ESN) Addendum to IPsec Domain of Interpretation (DOI) for Internet

Security Association and Key Management Protocol (ISAKMP) l RFC 4303: IP Encapsulating Security Payload (ESP)

• RFC 3706: A Traffic-Based Method of Detecting Dead Internet Key Exchange (IKE) Peers

IPv4

l RFC 6864: Updated Specification of the IPv4 ID Field l RFC 5177: Network Mobility (NEMO) Extensions for Mobile IPv4 l RFC 4632: Classless Inter-domain Routing (CIDR): The Internet Address Assignment and Aggregation Plan l RFC 3927: Dynamic Configuration of IPv4 Link-Local Addresses l RFC 3021: Using 31-Bit Prefixes on IPv4 Point-to-Point Links l RFC 1812: Requirements for IP Version 4 Routers

IPv6

l RFC 6343: Advisory Guidelines for 6to4 Deployment l RFC 5175: IPv6 Router Advertisement Flags Option

9

IS-IS

• RFC 5095: Deprecation of Type 0 Routing Headers in IPv6 l RFC 4941: Privacy Extensions for Stateless Address Autoconfiguration in IPv6 l RFC 4862: IPv6 Stateless Address Autoconfiguration l RFC 4861: Neighbor Discovery for IP version 6 (IPv6) l RFC 4389: Neighbor Discovery Proxies (ND Proxy) l RFC 4213: Basic Transition Mechanisms for IPv6 Hosts and Routers l RFC 4193: Unique Local IPv6 Unicast Addresses l RFC 4007: IPv6 Scoped Address Architecture l RFC 3971: SEcure Neighbor Discovery (SEND) l RFC 3596: DNS Extensions to Support IP Version 6 l RFC 3587: IPv6 Global Unicast Address Format l RFC 3493: Basic Socket Interface Extensions for IPv6 l RFC 3056: Connection of IPv6 Domains via IPv4 Clouds l RFC 3053: IPv6 Tunnel Broker l RFC 2894: Router Renumbering for IPv6 l RFC 2675: IPv6 Jumbograms l RFC 2185: Routing Aspects Of IPv6 Transition
• RFC 1752: The Recommendation for the IP Next Generation Protocol

IS-IS

l RFC 5310: IS-IS Generic Cryptographic Authentication l RFC 5308: Routing IPv6 with IS-IS l RFC 3359: Reserved Type, Length and Value (TLV) Codepoints in Intermediate System to Intermediate System l RFC 1195: Use of OSI IS-IS for Routing in TCP/IP and Dual Environments

LDAP

• RFC 4513: Lightweight Directory Access Protocol (LDAP): Authentication Methods and Security Mechanisms l RFC 4512: Lightweight Directory Access Protocol (LDAP): Directory Information Models l RFC 4511: Lightweight Directory Access Protocol (LDAP): The Protocol
• RFC 3494: Lightweight Directory Access Protocol version 2 (LDAPv2) to Historic Status

MPLS

• RFC 7026: Retiring TLVs from the Associated Channel Header of the MPLS Generic Associated Channel l RFC 6426: MPLS On-Demand Connectivity Verification and Route Tracing l RFC 6425: Detecting Data-Plane Failures in Point-to-Multipoint MPLS – Extensions to LSP Ping l RFC 6423: Using the Generic Associated Channel Label for Pseudowire in the MPLS Transport Profile (MPLS-TP) l RFC 5586: MPLS Generic Associated Channel

NAT

• RFC 5462: Multiprotocol Label Switching (MPLS) Label Stack Entry: “EXP” Field Renamed to “Traffic Class” Field l RFC 5332: MPLS Multicast Encapsulations l RFC 5129: Explicit Congestion Marking in MPLS l RFC 4448: Encapsulation Methods for Transport of Ethernet over MPLS Networks l RFC 4182: Removing a Restriction on the use of MPLS Explicit NULL l RFC 3564: Requirements for Support of Differentiated Services-aware MPLS Traffic Engineering l RFC 3469: Framework for Multi-Protocol Label Switching (MPLS)-based Recovery l RFC 3443: Time To Live (TTL) Processing in Multi-Protocol Label Switching (MPLS) Networks l RFC 3270: Multi-Protocol Label Switching (MPLS) Support of Differentiated Services l RFC 3032: MPLS Label Stack Encoding

NAT

• RFC 6888: Common Requirements for Carrier-Grade NATs (CGNs) l RFC 6146: Stateful NAT64: Network Address and Protocol Translation from IPv6 Clients to IPv4 Servers l RFC 4966: Reasons to Move the Network Address Translator – Protocol Translator (NAT-PT) to Historic Status l RFC 4787: Network Address Translation (NAT) Behavioral Requirements for Unicast UDP l RFC 4380: Teredo: Tunneling IPv6 over UDP through Network Address Translations (NATs) l RFC 3948: UDP Encapsulation of IPsec ESP Packets
• RFC 3022: Traditional IP Network Address Translator (Traditional NAT)

OSPF

l RFC 6860: Hiding Transit-Only Networks in OSPF l RFC 6845: OSPF Hybrid Broadcast and Point-to-Multipoint Interface Type l RFC 5340: OSPF for IPv6 l RFC 4812: OSPF Restart Signaling l RFC 4811: OSPF Out-of-Band Link State Database (LSDB) Resynchronization l RFC 4203: OSPF Extensions in Support of Generalized Multi-Protocol Label Switching (GMPLS) l RFC 3630: Traffic Engineering (TE) Extensions to OSPF Version 2 l RFC 3623: Graceful OSPF Restart l RFC 3509: Alternative Implementations of OSPF Area Border Routers l RFC 3101: The OSPF Not-So-Stubby Area (NSSA) Option l RFC 2328: OSPF Version 2 l RFC 1765: OSPF Database Overflow l RFC 1370: Applicability Statement for OSPF

PPP

PPP

• RFC 2516: A Method for Transmitting PPP Over Ethernet (PPPoE) l RFC 2364: PPP Over AAL5
• RFC 1661: The Point-to-Point Protocol (PPP)

RADIUS

• RFC 5176: Dynamic Authorization Extensions to Remote Authentication Dial In User Service (RADIUS) l RFC 2866: RADIUS Accounting
• RFC 2548: Microsoft Vendor-specific RADIUS Attributes

RIP

l RFC 4822: RIPv2 Cryptographic Authentication l RFC 2453: RIP Version 2 l RFC 2080: RIPng for IPv6 l RFC 1724: RIP Version 2 MIB Extension l RFC 1058: Routing Information Protocol

SIP

l RFC 3960: Early Media and Ringing Tone Generation in the Session Initiation Protocol (SIP) l RFC 3325: Private Extensions to the Session Initiation Protocol (SIP) for Asserted Identity within Trusted Networks l RFC 3262: Reliability of Provisional Responses in the Session Initiation Protocol (SIP) l RFC 3261: SIP: Session Initiation Protocol

SNMP

• RFC 4293: Management Information Base for the Internet Protocol (IP) l RFC 4273: Definitions of Managed Objects for BGP-4 l RFC 4113: Management Information Base for the User Datagram Protocol (UDP) l RFC 4022: Management Information Base for the Transmission Control Protocol (TCP) l RFC 3635: Definitions of Managed Objects for the Ethernet-like Interface Types l RFC 3417: Transport Mappings for the Simple Network Management Protocol (SNMP) l RFC 3416: Version 2 of the Protocol Operations for the Simple Network Management Protocol (SNMP) l RFC 3414: User-based Security Model (USM) for version 3 of the Simple Network Management Protocol (SNMPv3) SSL
• RFC 3413: Simple Network Management Protocol (SNMP) Applications l RFC 3412: Message Processing and Dispatching for the Simple Network Management Protocol (SNMP) l RFC 3411: An Architecture for Describing Simple Network Management Protocol (SNMP) Management

Frameworks l RFC 3410: Introduction and Applicability Statements for Internet Standard Management Framework l RFC 2863: The Interfaces Group MIB l RFC 2578: Structure of Management Information Version 2 (SMIv2)

• RFC 1238: CLNS MIB for use with Connectionless Network Protocol (ISO 8473) and End System to Intermediate

System (ISO 9542) l RFC 1215: A Convention for Defining Traps for use with the SNMP l RFC 1213: Management Information Base for Network Management of TCP/IP-based internets: MIB-II l RFC 1212: Concise MIB Definitions l RFC 1157: A Simple Network Management Protocol (SNMP) l RFC 1156: Management Information Base for Network Management of TCP/IP-based internets l RFC 1155: Structure and Identification of Management Information for TCP/IP-based Internets

SSL

l RFC 6176: Prohibiting Secure Sockets Layer (SSL) Version 2.0 l RFC 6101:The Secure Sockets Layer (SSL) Protocol Version 3.0

TCP

l RFC 6691: TCP Options and Maximum Segment Size (MSS) l RFC 6298: Computing TCP’s Retransmission Timer l RFC 6093: On the Implementation of the TCP Urgent Mechanism l RFC 793: Transmission Control Protocol

TLS

l RFC 6347: Datagram Transport Layer Security Version 1.2 l RFC 6066:Transport Layer Security (TLS) Extensions: Extension Definitions l RFC 5746: Transport Layer Security (TLS) Renegotiation Indication Extension l RFC 5425: Transport Layer Security (TLS) Transport Mapping for Syslog l RFC 5246: The Transport Layer Security (TLS) Protocol Version 1.2 l RFC 4681: TLS User Mapping Extension l RFC 4680: TLS Handshake Message for Supplemental Data

VPN

VPN

• RFC 4761: Virtual Private LAN Service (VPLS) Using BGP for Auto-Discovery and Signaling
• RFC 4684: Constrained Route Distribution for Border Gateway Protocol/MultiProtocol Label Switching (BGP/MPLS)

Internet Protocol (IP) Virtual Private Networks (VPNs) l RFC 4577: OSPF as the Provider/Customer Edge Protocol for BGP/MPLS IP Virtual Private Networks (VPNs) l RFC 4364: BGP/MPLS IP Virtual Private Networks (VPNs)

• RFC 3715: IPsec-Network Address Translation (NAT) Compatibility Requirements

Other protocols

l RFC 5357: A Two-Way Active Measurement Protocol (TWAMP) l RFC 5214: Intra-Site Automatic Tunnel Addressing Protocol (ISATAP) l RFC 4960: Stream Control Transmission Protocol l RFC 4251: The Secure Shell (SSH) Protocol Architecture l RFC 3435: Media Gateway Control Protocol (MGCP) Version 1.0 l RFC 3376 : Internet Group Management Protocol, Version 3 l RFC 2890: Key and Sequence Number Extensions to GRE l RFC 2784: Generic Routing Encapsulation (GRE) l RFC 2661: Layer Two Tunneling Protocol “L2TP” l RFC 2637: Point-to-Point Tunneling Protocol (PPTP) l RFC 2412: The OAKLEY Key Determination Protocol l RFC 2225: Classical IP and ARP over ATM l RFC 2033: Local Mail Transfer Protocol l RFC 1413: Identification Protocol l RFC 1011: Official Internet Protocols l RFC 862: Echo Protocol l RFC 768: User Datagram Protocol l The TACACS+ Protocol

Miscellaneous

• RFC 7348: Virtual eXtensible Local Area Network (VXLAN): A Framework for Overlaying Virtualized Layer 2

Networks over Layer 3 Networks l RFC 4784: Verizon Wireless Dynamic Mobile IP Key Update for cdma2000(R) Networks for cdma2000(R) Networks l RFC 4470: Minimally Covering NSEC Records and DNSSEC On-line Signing l RFC 3985: Pseudo Wire Emulation Edge-to-Edge (PWE3) Architecture l RFC 2979: Behavior of and Requirements for Internet Firewalls

Miscellaneous

• RFC 2827: Network Ingress Filtering: Defeating Denial of Service Attacks which employ IP Source Address

Spoofing l RFC 2780: IANA Allocation Guidelines For Values In the Internet Protocol and Related Headers l RFC 2647: Benchmarking Terminology for Firewall Performance l RFC 2644: Changing the Default for Directed Broadcasts in Routers l RFC 2231: MIME Parameter Value and Encoded Word Extensions: Character Sets, Languages, and Continuations l RFC 1945: Hypertext Transfer Protocol — HTTP/1.0 l RFC 950: Internet Standard Subnetting Procedure l RFC 894: A Standard for the Transmission of IP Datagrams over Ethernet Networks

Captive portals

Introduction to captive portals

You can authenticate your users on a web page that requests the user’s name and password. Until the user authenticates successfully, the authentication page is returned in response to any HTTP request. This is called a captive portal.

After successful authentication, the user accesses the requested URL and can access other web resources, as permitted by security policies. Optionally, the captive portal itself can allow web access to only the members of specified user group.

The captive portal can be hosted on the FortiGate unit or on an external authentication server. You can configure captive portal authentication on any network interface, including WiFi and VLAN interfaces.

When a captive portal is configured on a WiFi interface, the access point initially appears open. The wireless client can connect to the access point with no security credentials, but sees only the captive portal authentication page.

WiFi captive portal types:

• Authentication — until the user enters valid credentials, no communication beyond the AP is permitted.
• Disclaimer + Authentication — immediately after successful authentication, the portal presents the disclaimer page—an acceptable use policy or other legal statement—to which the user must agree before proceeding.
• Disclaimer Only — the portal presents the disclaimer page—an acceptable use policy or other legal statement— to which the user must agree before proceeding. The authentication page is not presented.
• Email Collection — the portal presents a page requesting the user’s email address, for the purpose of contacting the person in future. This is often used by businesses who provide free WiFi access to their customers. The authentication page is not presented.
• MAC Bypass — when clients are authenticated against their bridged SSID and their MAC addresses are known, they are redirected to the external captive portal.

Configuring a captive portal

Captive portals are configured on network interfaces. A WiFi interface does not exist until the WiFi SSID is created. You can configure a WiFi captive portal at the time that you create the SSID. Afterwards, the captive portal settings will also be available by editing the WiFi network interface in System > Network > Interfaces.

On a physical (wired) network interface, you edit the interface configuration in System > Network > Interfaces and set Security Mode to Captive Portal.

To configure a WiFi captive portal – web-based manager:

1. Go to WiFi & Switch Controller > SSID and create your SSID.

If the SSID already exists, you can edit the SSID or you can edit the WiFi interface in Network > Interfaces.

2. Under WiFi Settings, for Security Mode, select Captive Portal.
3. Enter the following:

4. Select OK.

To configure an SSID with external-web enabled – CLI:

config wireless-controller vap edit “web-ext” set vdom “root” set ssid “web-ext” set security captive-portal set selected-usergroups “qnap“

Configuring a

set security-exempt-list “wifi”

set security-redirect-url “ http://www.fortinet.com” set intra-vap-privacy enable set local-switching disable

set external-web “192.168.234.51/portal.php”

next

end

Note that the external-web entry is the URL of the external authentication web server. When this entry is not set, the FortiGate will use the local web server hosting the local login/splash page.

The external web URL is not explicitly set with HTTP/HTTPS – FortiGate uses the auth-secure-http entry under config user setting.

Exemption from the captive portal

A captive portal requires all users on the interface to authenticate. But some devices are not able to authenticate. You can create an exemption list of these devices. For example, a printer might need to access the Internet for firmware upgrades. Using the CLI, you can create an exemption list to exempt all printers from authentication.

config user security-exempt-list edit r_exempt config rule edit <id> set devices printer

end

end

Furthermore, a walled garden firewall policy can be created:

config firewall policy edit <id> set captive-portal-exempt enable …

next

end

MAC Bypass for captive portal

It is possible to provide a MAC address bypass for authenticated clients.When clients are authenticated with bridged SSID and their MAC addresses are known, they are redirected to the External Captive Portal.

A new portal type has been added, under config wireless-controller vap, to provide successful MAC authentication Captive Portal functionality.

Syntax

config wireless-controller vap edit {name} set portal-type {cmcc-macauth}

next

end

MAC-auth-bypass for the captive-portal SSID

Captive-portal SSID supports MAC-auth-bypass. If a client’s MAC can be authenticated from localuser or RADIUS, then the client can bypass firewall authentication directly.

config wireless-controller vap edit <name> set security captive-portal set MAC-auth-bypass {enable | disable}

next

end

Customizing captive portal pages

These pages are defined in replacement messages. Defaults are provided. In the web-based manager, you can modify the default messages in the SSID configuration by selecting Customize Portal Messages. Each SSID can have its own unique portal content.

The captive portal contains the following default web pages: l Login page—requests user credentials

Typical modifications for this page would be to change the logo and modify some of the text.

You can change any text that is not part of the HTML code nor a special tag enclosed in double percent (%) characters.

There is an exception to this rule. The line “Please enter your credentials to continue” is provided by the %%QUESTION%% tag. You can replace this tag with text of your choice. Except for this item, you should not remove any tags because they may carry information that the FortiGate unit needs.

• Login failed page—reports that the entered credentials were incorrect and enables the user to try again.

The Login failed page is similar to the Login page. It even contains the same login form. You can change any text that is not part of the HTML code nor a special tag enclosed in double percent (%) characters.

There is an exception to this rule. The line “Firewall authentication failed. Please try again.” is provided by the %%FAILED_MESSAGE%% tag. You can replace this tag with text of your choice. Except for this item, you should not remove any tags because they may carry information that the FortiGate unit needs.

• Disclaimer page—is a statement of the legal responsibilities of the user and the host organization to which the user must agree before proceeding.(WiFi or SSL VPN only)
• Declined disclaimer page—is displayed if the user does not agree to the statement on the Disclaimer page. Access is denied until the user agrees to the disclaimer.

Changing images in portal messages

You can replace the default Fortinet logo with your organization’s logo. First, import the logo file into the FortiGate unit and then modify the Login page code to reference your file.

To import a logo file:

1. Go to System > Replacement Messages and select Manage Images.
2. Select Create New.
3. Enter a Name for the logo and select the appropriate Content Type. The file must not exceed 24 Kilo bytes.
4. Select Browse, find your logo file and then select Open.
5. Select OK.

To specify the new logo in the replacement message:

1. Go to Network > Interfaces and edit the interface. The Security Mode must be Captive Portal.
2. Select the portal message to edit.
   • In SSL VPN or WiFi interfaces, in Customize Portal Messages click the link to the portal messages that you want to edit.
   • In other interfaces, make sure that Customize Portal Messages is selected, select the adjacent Edit icon, then select the message that you want to edit.
3. In the HTML message text, find the %%IMAGE tag.

By default it specifies the Fortinet logo: %%IMAGE:logo_fw_auth%%

4. Change the image name to the one you provided for your logo. The tag should now read, for example, %%IMAGE:mylogo%%
5. Select Save.
6. Select OK.

Modifying text in portal messages

Generally, you can change any text that is not part of the HTML code nor a special tag enclosed in double percent (%) characters. You should not remove any tags because they may carry information that the FortiGate unit needs. See the preceding section for any exceptions to this rule for particular pages.

To modify portal page text

1. Go to System > Network > Interfaces and edit the interface. The SSID Security Mode must be Captive Portal.
2. Select the portal message to edit.
   • In SSL VPN or WiFi interfaces, in Customize Portal Messages click the link to the portal messages that you want to edit.
   • In other interfaces, make sure that Customize Portal Messages is selected, select the adjacent Edit icon, then select the message that you want to edit.
3. Edit the HTML message text, then select Save.
4. Select OK.

Configuring disclaimer page for ethernet interface captive portals

While you can customize a disclaimer page for captive portals that connect via WiFi, the same can be done for wired connections. However, this can only be configured on the CLI Console, and only without configuring user groups.

When configuring a captive portal through the CLI, you may set security-groups to a specific user group. The result of this configuration will show an authentication form to users who wish to log in to the captive portal— not a disclaimer page. If you do not set any security-groups in your configuration, an “Allow all” status will be in effect, and the disclaimer page will be displayed for users.

The example CLI configuration below shows setting up a captive portal interface without setting security-groups, resulting in a disclaimer page for users:

config system interface edit “port1” set vdom “root” set ip 172.16.101.1 255.255.255.0 set allowaccess ping https ssh snmp http set type physical set explicit-web-proxy enable set alias “LAN”

set security-mode captive-portal

set snmp-index 1

next

end

Roaming support

Client devices can maintain captive portal authentication as they roam across different APs. By maintaining a consistent authentication, uninterrupted access to latency sensitive applications such as VoIP is ensured.

The Cloud will push a random per-AP Network encryption key to the AP. The key is 32 bytes in length, and is used in captive portal fast roaming. All APs of an AP Network will use the same encryption key. This key is randomly generated, and will be updated daily.

Session timeout interval for captive portal

The following syntax can be set to configure a session timeout interval in seconds for Captive Portal users. Set the range between 0 – 864000 (or no timeout to ten days). The default is set to 0.

Syntax

config wireless-controller vap edit <name> …

set captive-portal-session-timeout-interval <seconds>

next end

Configuration example – captive portal WiFi access control

In this scenario, you will configure the FortiGate for captive portal access so users can log on to your WiFi network.

You will create a user account (rgreen), add it to a user group (employees), create a captive portal SSID (example-staff), and configure a FortiAP unit. When the user attempts to browse the Internet, they will be redirected to the captive portal login page and asked to enter their username and password.

1. Enabling HTTPS authentication

Go to User & Device > Authentication Settings.

Under Protocol Support, enable Redirect HTTP Challenge to a Secure Channel (HTTPS). This will make sure that user credentials are communicated securely through the captive portal.

2. Creating the user

Go to User & Device > User Definition and create a Local user (rgreen).

Create additional users if needed, and assign any authentication methods.

3. Creating the user group

Go to User & Device > User Groups and create a user group (employees).

Add rgreen to the group.

4. Creating the SSID

Go to WiFi & Switch Controller > SSID and configure the wireless network.

Some FortiGate models may show the GUI path as WiFi & Switch Controller.

Enter an Interface Name (example-wifi) and IP/Network Mask.

An address range under DHCP Server will be automatically configured.

Under WiFi Settings, enter an SSID name (example-staff), set Security Mode to Captive Portal, and add the employees user group.

5. Creating the security policy

Go to Policy & Objects > Addresses and create a new address for the SSID (example-wifi-net).

Set Subnet/IP Range to the same range set on the DHCP server in the previous step.

Set Interface to the SSID interface.

Go to Policy & Objects > IPv4 Policy and create a new policy for WiFi users to connect to the Internet.

Add both the example-wifi-net address and employees user group to Source.

6. Connecting and authorizing the FortiAP

Go to Network > Interfaces and edit an available interface.

Under Address, set Addressing mode to Dedicated to Extension Device and assign it an IP address.

Connect the FortiAP unit to the configured interface, then go to WiFi & Switch Controller > Managed FortiAPs.

The FortiAP is listed, but its State shows a greyed-out question mark — this is because it is waiting for authorization.

Highlight the FortiAP and select Authorize.

The question mark is now replaced by a red down-arrow — this is because it is authorized, but still offline.

Go to WiFi & Switch Controller > FortiAP Profiles and edit the profile.

For each radio, enable Radio Resource Provision and select your SSID.

Go back to WiFi & Switch Controller > Managed FortiAPs to verify that the FortiAP unit is online.

7. Results

When a user attempts to connect to the wireless network, they will be redirected to the captive portal login screen.

Members of the employees group must enter their Username and Password. The user will then be redirected to the URL originally requested.

On the FortiGate, go to Monitor > WiFi Client Monitor to verify that the user is authenticated.

Configuring a WiFi LAN

When working with a FortiGate WiFi controller, you can configure your wireless network before you install any access points. If you are working with a standalone FortiWiFi unit, the access point hardware is already present but the configuration is quite similar. Both are covered in this section.

Overview of WiFi controller configuration

Setting your geographic location

Creating a FortiAP profile

Defining a wireless network interface (SSID)

Defining SSID groups

Dynamic user VLAN assignment

Configuring user authentication

Configuring firewall policies for the SSID

Configuring the built-in access point on a FortiWiFi unit

Enforcing UTM policies on a local bridge SSID for managed smart APs

On FortiGate model 30D, web-based manager configuration of the WiFi controller is disabled by default. To enable it, enter the following CLI commands:

config system global

set gui-wireless-controller enable end

The WiFi Controller and Switch Controller are enabled through the Feature Store (under System > Feature Select). However, they are separately enabled and configured to display in the GUI via the CLI.

To enable both WiFi and Switch controllers, enter the following:

config system global set wireless-controller enable set switch-controller enable

end

To enable the GUI display for both controllers, have also been separated:

config system settings set gui-wireless-controller enable set gui-switch-controller enable end