WAN optimization configuration

WAN optimization configuration

This chapter describes FortiGate WAN optimization client server architecture and other concepts you need to understand to be able to configure FortiGate WAN optimization.

Manual (peer-to-peer) and active-passive WAN optimization

You can create manual (peer-to-peer) and active-passive WAN optimization configurations.

In reality, because WAN optimization traffic can only be processed by one CPU core, it is not recommended to increase the number of manual mode peers on the FortiGate unit per VDOM.

Note that the maximum number of manual peers are restricted to 256 per VDOM. However, in Active-Passive configurations, there is no hard-limit to the maximum number of manual peers per VDOM.

Manual (peer to peer) configurations

Manual configurations allow for WAN optimization between one client-side FortiGate unit and one server-side FortiGate unit. To create a manual configuration you add a manual mode WAN optimization security policy to the client-side FortiGate unit. The manual mode policy includes the peer ID of a server-side FortiGate unit.

In a manual mode configuration, the client-side peer can only connect to the named server-side peer. When the client-side peer initiates a tunnel with the server-side peer, the packets that initiate the tunnel include extra information so that the server-side peer can determine that it is a peer-to-peer tunnel request. This extra information is required because the server-side peer does not require a WAN optimization policy; however, you need to add the client peer host ID and IP address to the server-side FortiGate unit peer list.

In addition, from the server-side FortiGate unit CLI you must and an Explicit Proxy security policy with proxy set to wanopt and the destination interface and network set to the network containing the servers that clients connect to over the WAN optimization tunnel. WAN optimization tunnel requests are accepted by the explicit proxy policy and if the client-side peer is in the server side peer’s address list the traffic is forwarded to the servers on the destination network.

Manual mode client-side policy

You must configure manual mode client-side policies from the CLI. From the GUI a manual mode policy has WAN Optimization turned on and includes the following text beside the WAN optimization field: Manual (Profile: <profile-name>. Peer: <peer-name>.

Add a manual mode policy to the client-side FortiGate unit from the CLI. The policy enables WAN optimization, sets wanopt-detection to off, and uses the wanopt-peer option to specify the server-side peer. The following example uses the default WAN optimization profile.

config firewall policy edit 2 set srcintf internal

set dstintf wan1 set srcaddr client-subnet set dstaddr server-subnet set action accept set schedule always set service ALL set wanopt enable set wanopt-detection off set wanopt-profile default set wanopt-peer server

next

end

Manual mode server-side explicit proxy policy

The server-side explicit proxy policy allows connections from the WAN optimization tunnel to the server network by setting the proxy type to wanopt. You must add policies that set proxy to wanopt from the CLI and these policies do not appear on the GUI. The policy should look like the following:

configure firewall proxy-policy edit 3 set proxy wanopt set dstintf internal set srcaddr all set dstaddr server-subnet set action accept set schedule always set service ALL

next

end

Active-passive configurations

Active-passive WAN optimization requires an active WAN optimization policy on the client-side FortiGate unit and a passive WAN optimization policy on the server-side FortiGate unit. The server-side FortiGate unit also requires an explicit proxy policy with proxy set to wanopt.

You can use the passive policy to control WAN optimization address translation by specifying transparent mode or non-transparent mode. SeeManual (peer-to-peer) and active-passive WAN optimization on page 284. You can also use the passive policy to apply security profiles, web caching, and other FortiGate features at the server-side FortiGate unit. For example, if a server-side FortiGate unit is protecting a web server, the passive policy could enable web caching.

A single passive policy can accept tunnel requests from multiple FortiGate units as long as the server-side FortiGate unit includes their peer IDs and all of the client-side FortiGate units include the server-side peer ID.

Active client-side policy

Add an active policy to the client-side FortiGate unit by turning on WAN Optimization and selecting active. Then select a WAN optimization Profile. From the CLI the policy could look like the following:

config firewall policy edit 2 set srcintf internal set dstintf wan1 set srcaddr client-subnet set dstaddr server-subnet

WAN optimization profiles

set action accept set schedule always set service ALL set wanopt enable set wanopt-detection active set wanopt-profile default

next

end

Server-side tunnel policy

The server-side requires an explicit proxy policy that sets the proxy to wanopt. You must add this policy from the CLI and policies with proxy set to wanopt do not appear on the GUI. From the CLI the policy could look like the following:

configure firewall proxy-policy edit 3 set proxy wanopt set dstintf internal set srcaddr all set dstaddr server-subnet set action accept set schedule always set service ALL

next

end

Server-side passive policy

Add a passive policy to the server-side FortiGate unit by selecting Enable WAN Optimization and selecting passive. Then set the Passive Option to transparent. From the CLI the policy could look like the following:

config firewall policy edit 2 set srcintf “wan1” set dstintf “internal” set srcaddr “all” set dstaddr “all” set action accept set schedule “always” set service “ANY” set wanopt enable set wanopt-detection passive set wanopt-passive-opt transparent

next

WAN optimization profiles

Use WAN optimization profiles to apply WAN optimization techniques to traffic to be optimized. In a WAN optimization profile you can select the protocols to be optimized and for each protocol you can enable SSL offloading (if supported), secure tunneling, byte caching and set the port or port range the protocol uses. You can also enable transparent mode and optionally select an authentication group. You can edit the default WAN optimization profile or create new ones.

To configure a WAN optimization profile go to WAN Opt. & Cache > Profiles and edit a profile or create a new one.

Configuring a WAN optimization profile

From the CLI you can use the following command to configure a WAN optimization profile to optimize HTTP traffic.

config wanopt profile edit new-profile config http set status enable

end

Transparent Mode Servers receiving packets after WAN optimization “see” different source addresses depending on whether or not you select Transparent Mode.

For more information, see WAN optimization profiles on page 286.

Authentication Group Select this option and select an authentication group so that the client and server-side FortiGate units must authenticate with each other before starting the WAN optimization tunnel. You must also select an authentication group if you select Secure Tunneling for any protocol.

You must add identical authentication groups to both of the FortiGate units that will participate in the WAN optimization tunnel. For more information, see Configuring authentication groups on page 1.

Protocol Select CIFS, FTP, HTTP or MAPI to apply protocol optimization for the selected protocols. See WAN optimization profiles on page 286.

Select TCP if the WAN optimization tunnel accepts sessions that use more than one protocol or that do not use the CIFS, FTP, HTTP, or MAPI protocol.

 

SSL Offloading Select to apply SSL offloading for HTTPS or other SSL traffic. You can use

SSL offloading to offload SSL encryption and decryption from one or more HTTP servers to the FortiGate unit. If you enable this option, you must configure the security policy to accept SSL-encrypted traffic.

If you enable SSL offloading, you must also use the CLI command config firewall ssl-server to add an SSL server for each HTTP server that you want to offload SSL encryption/decryption for. For more information, see Turning on web caching for HTTPS traffic on page 1.

Secure

Tunneling

The WAN optimization tunnel is encrypted using SSL encryption. You must also add an authentication group to the profile. For more information, see Secure tunneling on page 1.
Byte Caching Select to apply WAN optimization byte caching to the sessions accepted by this rule. For more information, see “Byte caching”.
Port Enter a single port number or port number range. Only packets whose destination port number matches this port number or port number range will be optimized.

Processing non-HTTP sessions accepted by a WAN optimization profile with HTTP optimization

From the CLI, you can use the following command to configure how to process non-HTTP sessions when a rule configured to accept and optimize HTTP traffic accepts a non-HTTP session. This can occur if an application sends non-HTTP sessions using an HTTP destination port.

config wanopt profile edit default config http set status enable

set tunnel-non-http {disable | enable}

end

To drop non-HTTP sessions accepted by the rule set tunnel-non-http to disable, or set it to enable to pass non-HTTP sessions through the tunnel without applying protocol optimization, byte-caching, or web caching. In this case, the FortiGate unit applies TCP protocol optimization to non-HTTP sessions.

Processing unknown HTTP sessions

Unknown HTTP sessions are HTTP sessions that do not comply with HTTP 0.9, 1.0, or 1.1. From the CLI, use the following command to specify how a rule handles such HTTP sessions.

config wanopt profile edit default config http set status enable

set unknown-http-version {best-effort | reject | tunnel} end

Monitoring WAN optimization performance

To assume that all HTTP sessions accepted by the rule comply with HTTP 0.9, 1.0, or 1.1, select besteffort. If a session uses a different HTTP version, WAN optimization may not parse it correctly. As a result, the FortiGate unit may stop forwarding the session and the connection may be lost. To reject HTTP sessions that do not use HTTP 0.9, 1.0, or 1.1, select reject.

To pass HTTP sessions that do not use HTTP 0.9, 1.0, or 1.1, but without applying HTTP protocol optimization, byte-caching, or web caching, you can also select tunnel. TCP protocol optimization is applied to these HTTP sessions.

WAN optimization concepts

WAN optimization concepts

Client/server architecture

Traffic across a WAN typically consists of clients on a client network communicating across a WAN with a remote server network. The clients do this by starting communication sessions from the client network to the server network. These communication sessions can be open text over the WAN or they can be encrypted by SSL VPN or IPsec VPN.

To optimize these sessions, you can add WAN optimization security policies to the client-side FortiGate unit to accept sessions from the client network that are destined for the server network. The client-side FortiGate unit is located between the client network and the WAN. WAN optimization security policies include WAN optimization profiles that control how the traffic is optimized.

The client-side FortiGate unit must also include the IP address of the server-side FortiGate unit in its WAN optimization peer configuration. The server-side FortiGate unit is located between the server network and the WAN, The peer configuration allows the client-side FortiGate unit to find the server-side FortiGate unit and attempt to establish a WAN optimization tunnel with it.

For the server-side FortiGate unit you must add a security policy with wanopt as the Incoming Interface. This security policy allows the FortiGate unit to accept WAN optimization sessions from the client-side FortiGate unit. For the server-side FortiGate unit to accept a WAN optimization connection it must have the client-side FortiGate unit in its WAN optimization peer configuration.

WAN optimization profiles are only added to the client-side WAN optimization security policy. The server-side FortiGate unit employs the WAN optimization settings set in the WAN optimization profile on the client-side FortiGate unit.

Client/server architecture

When both peers are identified the FortiGate units attempt to establish a WAN optimization tunnel between them. WAN optimization tunnels use port 7810. All optimized data flowing across the WAN between the clientside and server-side FortiGate units use this tunnel. WAN optimization tunnels can be encrypted use SSL encryption to keep the data in the tunnel secure.

Any traffic can be sent through a WAN optimization tunnel. This includes SSL and IPsec VPN traffic. However, instead of configuring SSL or IPsec VPN for this communication you can add SSL encryption using the WAN optimization tunnel.

In addition to basic identification by peer host ID and IP address you can configure WAN optimization authentication using certificates and pre-shared keys to improve security. You can also configure FortiGate units involved in WAN optimization to accept connections from any identified peer or restrict connections to specific peers.

The FortiClient application can act in the same manner as a client-side FortiGate unit to optimize traffic between a computer running FortiClient and a FortiGate unit.

WAN optimization peers

The client-side and server-side FortiGate units are called WAN optimization peers because all of the FortiGate units in a WAN optimization network have the same peer relationship with each other. The client and server roles just relate to how a session is started. Any FortiGate unit configured for WAN optimization can be a client-side and a server-side FortiGate unit at the same time, depending on the direction of the traffic. Client-side FortiGate units initiate WAN optimization sessions and server-side FortiGate units respond to the session requests. Any FortiGate unit can simultaneously be a client-side FortiGate unit for some sessions and a server-side FortiGate unit for others.

WAN optimization peer and tunnel architecture

To identify all of the WAN optimization peers that a FortiGate unit can perform WAN optimization with, you add host IDs and IP addresses of all of the peers to the FortiGate unit configuration. The peer IP address is actually the IP address of the peer unit interface that communicates with the FortiGate unit.

Protocol optimization

Protocol optimization techniques optimize bandwidth use across the WAN. These techniques can improve the efficiency of communication across the WAN optimization tunnel by reducing the amount of traffic required by Protocol optimization and MAPI

communication protocols. You can apply protocol optimization to Common Internet File System (CIFS), FTP, HTTP, MAPI, and general TCP sessions. You can apply general TCP optimization to MAPI sessions.

For example, CIFS provides file access, record locking, read/write privileges, change notification, server name resolution, request batching, and server authentication. CIFS is a fairly “chatty” protocol, requiring many background transactions to successfully transfer a single file. This is usually not a problem across a LAN. However, across a WAN, latency and bandwidth reduction can slow down CIFS performance.

When you select the CIFS protocol in a WAN optimization profile, the FortiGate units at both ends of the WAN optimization tunnel use a number of techniques to reduce the number of background transactions that occur over the WAN for CIFS traffic.

If a policy accepts a range of different types of traffic, you can set Protocol to TCP to apply general optimization techniques to TCP traffic. However, applying this TCP optimization is not as effective as applying more protocolspecific optimization to specific types of traffic. TCP protocol optimization uses techniques such as TCP SACK support, TCP window scaling and window size adjustment, and TCP connection pooling to remove TCP bottlenecks.

Protocol optimization and MAPI

By default the MAPI service uses port number 135 for RPC port mapping and may use random ports for MAPI messages. The random ports are negotiated through sessions using port 135. The FortiOS DCE-RPC session helper learns these ports and opens pinholes for the messages. WAN optimization is also aware of these ports and attempts to apply protocol optimization to MAPI messages that use them. However, to configure protocol optimization for MAPI you should set the WAN optimization profile to a single port number (usually port 135). Specifying a range of ports may reduce performance.

Byte caching

Byte caching breaks large units of application data (for example, a file being downloaded from a web page) into small chunks of data, labeling each chunk of data with a hash of the chunk and storing those chunks and their hashes in a database. The database is stored on a WAN optimization storage device. Then, instead of sending the actual data over the WAN tunnel, the FortiGate unit sends the hashes. The FortiGate unit at the other end of the tunnel receives the hashes and compares them with the hashes in its local byte caching database. If any hashes match, that data does not have to be transmitted over the WAN optimization tunnel. The data for any hashes that does not match is transferred over the tunnel and added to that byte caching database. Then the unit of application data (the file being downloaded) is reassembled and sent to its destination.

The stored byte caches are not application specific. Byte caches from a file in an email can be used to optimize downloading that same file or a similar file from a web page.

The result is less data transmitted over the WAN. Initially, byte caching may reduce performance until a large enough byte caching database is built up.

To enable byte caching, you select Byte Caching in a WAN optimization profile.

Byte caching cannot determine whether or not a file is compressed (for example a zip file), and caches compressed and non-compressed versions of the same file separately.

Dynamic data chunking for byte caching

Dynamic data chunking can improve byte caching by improving detection of data chunks that are already cached in changed files or in data embedded in traffic using an unknown protocol. Dynamic data chunking is available for HTTP, CIFS and FTP.

Use the following command to enable dynamic data chunking for HTTP in the default WAN optimization profile.

config wanopt profile edit default config http set prefer-chunking dynamic

end

By default dynamic data chunking is disabled and prefer-chunking is set to fix.

WAN optimization transparent mode

WAN optimization is transparent to users. This means that with WAN optimization in place, clients connect to servers in the same way as they would without WAN optimization. However, servers receiving packets after WAN optimization “see” different source addresses depending on whether or not transparent mode is selected for WAN optimization. If transparent mode is selected, WAN optimization keeps the original source address of the packets, so servers appear to receive traffic directly from clients. Routing on the server network should be configured to route traffic with client source IP addresses from the server-side FortiGate unit to the server and back to the server-side FortiGate unit.

Some protocols, for example CIFS, may not function as expected if transparent mode is not selected. In most cases, for CIFS WAN optimization you should select transparent mode and make sure the server network can route traffic as described to support transparent mode.

If transparent mode is not selected, the source address of the packets received by servers is changed to the address of the server-side FortiGate unit interface that sends the packets to the servers. So servers appear to receive packets from the server-side FortiGate unit. Routing on the server network is simpler in this case because client addresses are not involved. All traffic appears to come from the server-side FortiGate unit and not from individual clients.

Do not confuse WAN optimization transparent mode with FortiGate transparent mode. WAN optimization transparent mode is similar to source NAT. FortiGate’s transparent mode is a system setting that controls how the FortiGate unit (or a VDOM) processes traffic.

Configuring transparent mode

You can configure transparent mode by selecting Transparent in a WAN Optimization profile. The profile is added to an active WAN Optimization policy.

When you configure a passive WAN Optimization policy you can accept the active policy transparent setting or you can override the active policy transparent setting. From the GUI you can do this by setting the Passive Option as follows:

  • default use the transparent setting in the WAN Optimization profile added to the active policy (client-side configuration).
  • transparent impose transparent mode (override the active policy transparent mode setting). Packets exiting the FortiGate keep their original source addresses.
  • non-transparent impose non-transparent mode (override the active policy transparent mode setting). Packets exiting the FortiGate have their source address changed to the address of the server-side FortiGate unit interface that sends the packets to the servers.

From the CLI you can use the following command:

config firewall policy set wanopt-passive-opt {default | transparent | non-transparent}

end

Operating modes and VDOMs

To use WAN optimization, the FortiGate units can operate in either NAT/Route or transparent mode. The clientside and server-side FortiGate units do not have to be operating in the same mode.

As well, the FortiGate units can be configured for multiple virtual domain (VDOM) operation. You configure WAN optimization for each VDOM and configure one or both of the units to operate with multiple VDOMs enabled.

If a FortiGate unit or VDOM is operating in transparent mode with WAN optimization enabled, WAN optimization uses the management IP address as the peer IP address of the FortiGate unit instead of the address of an interface.

WAN optimization tunnels

All optimized traffic passes between the FortiGate units over a WAN optimization tunnel. Traffic in the tunnel can be sent in plain text or encrypted using AES-128bit-CBC SSL.

WAN optimization tunnels

Both plain text and the encrypted tunnels use TCP destination port 7810.

Before a tunnel can be started, the peers must be configured to authenticate with each other. Then, the clientside peer attempts to start a WAN optimization tunnel with the server-side peer. Once the peers authenticate with each other, they bring up the tunnel and WAN optimization communication over the tunnel starts. After a tunnel has been established, multiple WAN optimization sessions can start and stop between peers without restarting the tunnel.

Tunnel sharing

You can use the tunnel-sharing WAN optimization profile CLI keyword to configure tunnel sharing for WAN optimization rules. Tunnel sharing means multiple WAN optimization sessions share the same tunnel. Tunnel sharing can improve performance by reducing the number of WAN optimization tunnels between FortiGate units. Having fewer tunnels means less data to manage. Also, tunnel setup requires more than one exchange of information between the ends of the tunnel. Once the tunnel is set up, each new session that shares the tunnel avoids tunnel setup delays.

Tunnel sharing also uses bandwidth more efficiently by reducing the chances that small packets will be sent down the tunnel. Processing small packets reduces network throughput, so reducing the number of small packets improves performance. A shared tunnel can combine all the data from the sessions being processed by the tunnel and send the data together. For example, suppose a FortiGate unit is processing five WAN optimization sessions and each session has 100 bytes to send. If these sessions use a shared tunnel, WAN optimization combines the packets from all five sessions into one 500-byte packet. If each session uses its own private tunnel, five 100-byte packets will be sent instead. Each packet also requires a TCP ACK reply. The combined packet in the shared tunnel requires one TCP ACK packet. The separate packets in the private tunnels require five.

Use the following command to configure tunnel sharing for HTTP traffic in a WAN optimization profile.

config wanopt profile edit default config http set tunnel-sharing {express-shared | private | shared}

end

Tunnel sharing is not always recommended and may not always be the best practice. Aggressive and nonaggressive protocols should not share the same tunnel. An aggressive protocol can be defined as a protocol that is able to get more bandwidth than a non-aggressive protocol. (The aggressive protocols can “starve” the non-

 

WAN optimization and user and device identity policies, load balancing and traffic shaping

aggressive protocols.) HTTP and FTP are considered aggressive protocols. If aggressive and non-aggressive protocols share the same tunnel, the aggressive protocols may take all of the available bandwidth. As a result, the performance of less aggressive protocols could be reduced. To avoid this problem, rules for HTTP and FTP traffic should have their own tunnel. To do this, set tunnel-sharing to private for WAN optimization rules that accept HTTP or FTP traffic.

It is also useful to set tunnel-sharing to express-shared for applications, such as Telnet, that are very interactive but not aggressive. Express sharing optimizes tunnel sharing for Telnet and other interactive applications where latency or delays would seriously affect the user’s experience with the protocol.

Set tunnel-sharing to shared for applications that are not aggressive and are not sensitive to latency or delays. WAN optimization rules set to sharing and express-shared can share the same tunnel.

WAN optimization and user and device identity policies, load balancing and traffic shaping

Please note the following about WAN optimization and firewall policies:

  • WAN optimization is not compatible with firewall load balancing.
  • WAN optimization is compatible with source and destination NAT options in firewall policies (including firewall virtual IPs). If a virtual IP is added to a policy the traffic that exits the WAN optimization tunnel has its destination address changed to the virtual IPs mapped to IP address and port.
  • WAN optimization is compatible with user identity-based and device identity security policies. If a session is allowed after authentication or device identification the session can be optimized.

Traffic shaping

Traffic shaping works for WAN optimization traffic that is not in a WAN optimization tunnel. So traffic accepted by a WAN optimization security policy on a client-side FortiGate unit can be shaped on ingress. However, when the traffic enters the WAN optimization tunnel, traffic shaping is not applied.

In manual mode:

  • Traffic shaping works as expected on the client-side FortiGate unit. l Traffic shaping cannot be applied to traffic on the server-side FortiGate unit.

In active-passive mode:

  • Traffic shaping works as expected on the client-side FortiGate unit.
  • If transparent mode is enabled in the WAN optimization profile, traffic shaping also works as expected on the server-side FortiGate unit. l If transparent mode is not enabled, traffic shaping works partially on the server-side FortiGate unit.

WAN optimization and HA

You can configure WAN optimization on a FortiGate HA cluster. The recommended best practice HA configuration for WAN optimization is active-passive mode. When the cluster is operating, all WAN optimization WAN optimization, web caching and memory usage

sessions are processed by the primary unit only. Even if the cluster is operating in active-active mode, HA does not load-balance WAN optimization sessions.

You can also form a WAN optimization tunnel between a cluster and a standalone FortiGate unit or between two clusters.

In a cluster, only the primary unit stores the byte cache database. This database is not synchronized to the subordinate units. So, after a failover, the new primary unit must rebuild its byte cache. Rebuilding the byte cache can happen relatively quickly because the new primary unit gets byte cache data from the other FortiGate unit that it is participating with in WAN optimization tunnels.

WAN optimization, web caching and memory usage

To accelerate and optimize disk access and to provide better throughput and less latency FortiOS WAN optimization uses provisioned memory to reduce disk I/O and increase disk I/O efficiency. In addition, WAN optimization requires a small amount of additional memory per session for comprehensive flow control logic and efficient traffic forwarding.

When WAN optimization is enabled you will see a reduction in available memory. The reduction increases when more WAN optimization sessions are being processed. If you are thinking of enabling WAN optimization on an operating FortiGate unit, make sure its memory usage is not maxed out during high traffic periods.

In addition to using the system dashboard to see the current memory usage you can use the get test wad 2 command to see how much memory is currently being used by WAN optimization. See “get test {wad | wccpd} <test_level>” for more information.

Inside FortiOS: WAN optimization

Inside FortiOS: WAN optimization

Enterprises deploying FortiOS can leverage WAN optimization to provide fast and secure application responses between locations on a Wide Area Network (WAN). The web caching component of FortiOS WAN optimization extends this protection and performance boost to cloud services.

Centralize without compromising your WAN performance

Many multi-location enterprise environments reduce costs and consolidate resources by centralizing applications or providing applications in the cloud. Efficient and high-speed communication between applications and their users is critical. Remote sites don’t always have access to high bandwidth, but users at all sites expect consistent network performance. Minimizing user impact and improving performance is especially vital when applications designed for local area networks (LANs) are on the cloud.

Even applications that work fine on a local LAN, such as Windows File Sharing (CIFS), email exchange (MAPI), and many others, suffer from bandwidth limitations and latency issues when accessed over a WAN. This results in a loss of productivity and a perceived need for expensive network upgrades. FortiOS’s WAN Optimization provides an inexpensive and easy way to deploy a solution to this problem.

FortiOS is commonly deployed in central offices, satellite offices, and in the cloud to provide secure communications across a WAN using IPsec or SSL VPN. This installed infrastructure can be leveraged to add more value by using WAN Optimization to accelerate WAN traffic and web caching to accelerate could services.

FortiOS WAN optimization

FortiOS includes license-free WAN optimization on most current FortiGate devices. WAN optimization is a comprehensive solution that maximizes your WAN performance and provides intelligent bandwidth management and unmatched consolidated security performance. WAN optimization reduces your network overhead and removes unnecessary traffic for a better overall performance experience. Efficient use of bandwidth and better application performance will remove the need for costly WAN link upgrades between data centers and other expensive solutions for your network traffic growth.

Protocol optimization

Protocol optimization is effective for applications designed for the LAN that do not function well on low bandwidth high latency networks. FortiOS protocol optimization improves the efficiency of CIFS, FTP, HTTP, MAPI, and general TCP sessions.

For example, CIFS, which is a fairly “chatty” protocol, requires many background transactions to successfully transfer a single file. When transferring the file, CIFS sends small chunks of data and waits sequentially for each chunk’s arrival and acknowledgment before sending the next. This large amount of request/acknowledgement traffic can delay transfers. FortiOS CIFS WAN Optimization removes this chatiness and gets on with the job of transferring the file.

TCP protocol optimization uses techniques such as SACK support, window scaling and window size adjustment, and connection pooling to remove common WAN TCP bottlenecks.

Web caching

In an enterprise environment, multiple users will often want to get the same content (for example, a sales spreadsheet, a corporate presentation or a PDF from a cloud service, or a software update). With FortiOS Web caching, content from the cloud, from the web or from other sites on the WAN is download once and cached on the local FortiGate device. When other uses access the same content they download it from the cache. The result is less bandwidth use and reduced latency for the file requester.

FortiOS web caching also recognizes requests for Windows or MS-Office updates and downloads the new update file in the background. Once downloaded to the cache, the new update file is available to all users and all subsequent requests for this update are rapidly downloaded from the cache.

Byte caching

Byte caching improves caching by accelerating the transfer of similar, but not identical content. Byte caching accelerates multiple downloads of different email messages with the same corporate disclaimer by downloading the disclaimer over the WAN once and then downloading all subsequent disclaimers from a local FortiGate unit. Byte caching reduces the amount of data crossing the WAN when multiple different emails with the same or similar attachments or different versions of an attachment are downloaded from a corporate email server to different locations over the WAN.

Dynamic data chunking

Dynamic data chunking detects and optimizes persistent data chunks in changed files or in data embedded in traffic that uses an unknown protocol. For example, dynamic chunking can cache data in Lotus notes traffic and make the data chunks available for email and other protocols.

Data deduplication

Byte caching breaks large units of application data, like an email attachment or a file download, into manageable small chunks of data. Each chunk of data is labeled with a hash, and chunks with their respective hashes are stored in a database on the local FortiGate unit. When a remote user request a file, the WAN Optimization sends the hashes, rather than the actual data. The FortiGate unit at the other end of the WAN tunnel reassembles the data from its own hash database, only downloading chunks that it is missing. Deduplication, or the process of eliminating duplicate data, will reduce space consumption. In addition to reducing the amount of data downloaded across the WAN, byte caching is not application specific and assists by accelerating all of the protocols supported by WAN Optimization.

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.

SSL acceleration

SSL is used by many organizations to keep WAN communications private. WAN Optimization boosts SSL acceleration properties of FortiGate FortiASIC hardware by accelerating SSL traffic across the WAN. The FortiGate unit handles SSL encryption/decryption for corporate servers providing SSL encrypted connections over the WAN.

VPN replacement

FortiOS WAN optimization supports secure SSL-encrypted tunnels between FortiGate units on the WAN. Employing secure WAN Optimization tunnels can replace IPsec VPNs between sites. The result is a single, relatively simple configuration that supports optimization and privacy of communication across the WAN and uses FortiGate SSL acceleration to provide high performance.

Road warriors and home workers

The drive to give employees greater flexibility and reduce operational costs has led to more remote workers, both at home and on the road. Whether accessing the office from a hotel, public wireless hotspot, or home, the problem is the same: low bandwidth and high latency harming application performance. WAN Optimization is integrated into FortiClient, which can be installed on PCs and wireless devices to optimize communication between remote workers and their offices.

Reduce your…

  • Capital outlay: Organizations only need to purchase a single device per location. l Licensing costs: WAN Optimization is included with FortiOS. Additional licenses are not needed.
  • Network complexity: Small offices that may not have the space or power connections for multiple devices do not need to worry: no additional devices are required.

Example topologies relevant to WAN optimization

Example topologies relevant to WAN optimization

FortiGate WAN optimization consists of a number of techniques that you can apply to improve the efficiency of communication across your WAN. These techniques include protocol optimization, byte caching, web caching, SSL offloading, and secure tunneling. Protocol optimization can improve the efficiency of traffic that uses the

CIFS, FTP, HTTP, or MAPI protocol, as well as general TCP traffic. Byte caching caches files and other data on

FortiGate units to reduce the amount of data transmitted across the WAN. Web caching stores web pages on FortiGate units to reduce latency and delays between the WAN and web servers. SSL offloading offloads SSL decryption and encryption from web servers onto FortiGate SSL acceleration hardware. Secure tunneling secures traffic as it crosses the WAN.

You can apply different combinations of these WAN optimization techniques to a single traffic stream depending on the traffic type. For example, you can apply byte caching and secure tunneling to any TCP traffic. For HTTP and HTTPS traffic, you can also apply protocol optimization and web caching.

You can configure a FortiGate unit to be an explicit web proxy server for both IPv4 and IPv6 traffic and an explicit FTP proxy server. Users on your internal network can browse the Internet through the explicit web proxy server or connect to FTP servers through the explicit FTP proxy server. You can also configure these proxies to protect access to web or FTP servers behind the FortiGate unit using a reverse proxy configuration.

Web caching can be applied to any HTTP or HTTPS traffic, this includes normal traffic accepted by a security policy, explicit web proxy traffic, and WAN optimization traffic.

You can also configure a FortiGate unit to operate as a Web Cache Communication Protocol (WCCP) client or server. WCCP provides the ability to offload web caching to one or more redundant web caching servers.

FortiGate units can also apply security profiles to traffic as part of a WAN optimization, explicit web proxy, explicit FTP proxy, web cache and WCCP configuration. Security policies that include any of these options can also include settings to apply all forms of security profiles supported by your FortiGate unit.

Basic WAN optimization topology

The basic FortiGate WAN optimization topology consists of two FortiGate units operating as WAN optimization peers intercepting and optimizing traffic crossing the WAN between the private networks.

Security device and WAN optimization topology

Out-of-path WAN optimization topology

FortiGate units can be deployed as security devices that protect private networks connected to the WAN and also perform WAN optimization. In this configuration, the FortiGate units are configured as typical security devices for the private networks and are also configured for WAN optimization. The WAN optimization configuration intercepts traffic to be optimized as it passes through the FortiGate unit and uses a WAN optimization tunnel with another FortiGate unit to optimize the traffic that crosses the WAN.

You can also deploy WAN optimization on single-purpose FortiGate units that only perform WAN optimization. In the out of path WAN optimization topology shown below, FortiGate units are located on the WAN outside of the private networks. You can also install the WAN optimization FortiGate units behind the security devices on the private networks.

The WAN optimization configuration is the same for FortiGate units deployed as security devices and for singlepurpose WAN optimization FortiGate units. The only differences would result from the different network topologies.

Out-of-path WAN optimization topology

In an out-of-path topology, one or both of the FortiGate units configured for WAN optimization are not directly in the main data path. Instead, the out-of-path FortiGate unit is connected to a device on the data path, and the device is configured to redirect sessions to be optimized to the out-of-path FortiGate unit.

Single-purpose WAN optimization topology

The following out-of-path FortiGate units are configured for WAN optimization and connected directly to FortiGate units in the data path. The FortiGate units in the data path use a method such as policy routing to redirect traffic to be optimized to the out-of-path FortiGate units. The out-of-path FortiGate units establish a WAN optimization tunnel between each other and optimize the redirected traffic.

Out-of-path WAN optimization

One of the benefits of out-of-path WAN optimization is that out-of-path FortiGate units only perform WAN optimization and do not have to process other traffic. An in-path FortiGate unit configured for WAN optimization also has to process other non-optimized traffic on the data path.

The out-of-path FortiGate units can operate in NAT/Route or transparent mode.

Other out-of-path topologies are also possible. For example, you can install the out-of-path FortiGate units on the private networks instead of on the WAN. Also, the out-of-path FortiGate units can have one connection to the network instead of two. In a one-arm configuration such as this, security policies and routing have to be configured to send the WAN optimization tunnel out the same interface as the one that received the traffic.

Topology for multiple networks

As shown in below, you can create multiple WAN optimization configurations between many private networks. Whenever WAN optimization occurs, it is always between two FortiGate units, but you can configure any FortiGate unit to perform WAN optimization with any of the other FortiGate units that are part of your WAN.

WAN optimization among multiple networks

You can also configure WAN optimization between FortiGate units with different roles on the WAN. FortiGate units configured as security devices and for WAN optimization can perform WAN optimization as if they are single-purpose FortiGate units just configured for WAN optimization.

WAN optimization with web caching

WAN optimization with web caching

You can add web caching to a WAN optimization topology when users on a private network communicate with web servers located across the WAN on another private network.

WAN optimization with web caching topology

The topology above is the same as that shown in WAN optimization with web caching on page 269 with the addition of web caching to the FortiGate unit in front of the private network that includes the web servers. You can also add web caching to the FortiGate unit that is protecting the private network. In a similar way, you can add web caching to any WAN Optimization topology.

Explicit web proxy topologies

You can configure a FortiGate unit to be an explicit web proxy server for Internet web browsing of IPv4 and IPv6 web traffic. To use the explicit web proxy, users must add the IP address of the FortiGate interface configured for the explicit web proxy to their web browser proxy configuration.

Explicit web proxy topology

If the FortiGate unit supports web caching, you can also add web caching to the security policy that accepts explicit web proxy sessions The FortiGate unit then caches Internet web pages on a hard disk to improve web browsing performance.

Explicit web proxy with web caching topology

Explicit FTP proxy topologies

You can configure a FortiGate unit to be an explicit FTP proxy server for FTP users. To use the explicit web proxy, FTP users must connect to and authenticate with the explicit FTP proxy before connecting to an FTP server.

Explicit FTP proxy topology

You can also configure reverse explicit FTP proxy. In this configuration, users on the Internet connect to the explicit web proxy before connecting to an FTP server installed behind a FortiGate unit.

Reverse explicit FTP proxy topology

Web caching topologies

FortiGate web caching can be added to any security policy and any HTTP or HTTPS traffic accepted by that security policy can be cached on the FortiGate unit hard disk. This includes WAN optimization and explicit web proxy traffic. The network topologies for these scenarios are very similar. They involved a FortiGate unit installed between users and web servers with web caching enabled.

A typical web-caching topology includes one FortiGate unit that acts as a web cache server. Web caching is enabled in a security policy and the FortiGate unit intercepts web page requests accepted by the security policy, requests web pages from the web servers, caches the web page contents, and returns the web page contents to the users. When the FortiGate unit intercepts subsequent requests for cached web pages, the FortiGate unit contacts the destination web server just to check for changes.

WCCP topologies

Web caching topology

You can also configure reverse proxy web-caching. In this configuration, users on the Internet browse to a web server installed behind a FortiGate unit. The FortiGate unit intercepts the web traffic (HTTP and HTTPS) and caches pages from the web server. Reverse proxy web caching on the FortiGate unit reduces the number of requests that the web server must handle, leaving it free to process new requests that it has not serviced before. Reverse proxy web caching topology

WCCP topologies

You can operate a FortiGate unit as a Web Cache Communication Protocol (WCCP) router or cache engine. As a router, the FortiGate unit intercepts web browsing requests from client web browsers and forwards them to a WCCP cache engine. The cache engine returns the required cached content to the client web browser. If the cache server does not have the required content it accesses the content, caches it and returns the content to the client web browser.

WCCP topology

FortiGate units can also operate as WCCP cache servers, communicating with WCCP routers, caching web content and providing it to client web browsers as required.

WCCP is transparent to client web browsers. The web browsers do not have to be configured to use a web proxy.

Secure web gateway, WAN optimization, web caching and WCCP

Secure web gateway, WAN optimization, web caching and WCCP

You can use FortiGate WAN optimization and web caching to improve performance and security of traffic passing between locations on your wide area network (WAN) or from the Internet to your web servers. You can also use the FortiGate unit as an explicit FTP and web proxy server. If your FortiGate unit supports web caching, you can also add web caching to any HTTP sessions including WAN optimization, explicit web proxy and other HTTP sessions.

the next sections of this document describes how FortiGate WAN optimization, web caching, explicit web proxy, explicit FTP proxy and WCCP work and also describes how to configure these features.

Before you begin

Before you begin to configure WAN optimization, Web caching, explicit proxies or WCCP, take a moment to note the following:

  • To use WAN optimization and web caching, your FortiGate unit must support these features and not all do. In general your FortiGate unit must include a hard disk to support these features. See “FortiGate models that support WAN optimization” on page 263. Most FortiGate units support Explicit Web and FTP proxies.
  • To be able to configure WAN optimization and web caching from the web manager you should begin by going to System > Feature Visibility and turning on WAN Opt. & Cache.
  • To be able to configure the Web and FTP proxies from the web manager you should begin by going to System > Feature Visibility and turning on Explicit Proxy.
  • If you enable virtual domains (VDOMs) on the FortiGate unit, WAN optimization, web caching, and the explicit web and FTP proxies are available separately for each VDOM.
  • This guide is based on the assumption that you are a FortiGate administrator. It is not intended for others who may also use the FortiGate unit, such as FortiClient administrators or end users.
  • FortiGate WAN optimization is proprietary to Fortinet. FortiGate WAN optimization will not work with other vendors’ WAN optimization or acceleration features.
  • FortiGate web caching, explicit web and FTP proxies, and WCCP support known standards for these features. See the appropriate chapters of this document for details.

At this stage, the following installation and configuration conditions are assumed:

  • For WAN optimization you have already successfully installed two or more FortiGate units at various locations across your WAN.
  • For web caching, the explicit proxies and WCCP you have already successfully installed one or more FortiGate units on your network.
  • You have administrative access to the web-based manager and/or CLI. l The FortiGate units are integrated into your WAN or other networks l The operation mode has been configured. l The system time, DNS settings, administrator password, and network interfaces have been configured. l Firmware, FortiGuard Antivirus and FortiGuard Antispam updates are completed.

Secure web gateway, WAN optimization, web caching and WCCP          FortiGate models that support WAN optimization

  • You Fortinet products have been registered. Register your Fortinet products at the Fortinet Technical Support web site, https://support.fortinet.com.

FortiGate models that support WAN optimization

WAN optimization is available on FortiGate models with internal storage that also support SSL acceleration.

Internal storage includes high-capacity internal hard disks, AMC hard disk modules, FortiGate Storage Modules (FSMs) or over 4 Gbytes of internal flash storage. All of these storage locations can provide similar web caching and byte caching performance. If you add more than one storage location (for example, by creating multiple partitions on a storage device, by using more than one FSM, or by using an FSM and AMC hard disk in the same FortiGate unit) you can configure different storage locations for web caching and byte caching.

Distributing WAN optimization, explicit proxy, and web caching to multiple CPU cores

By default WAN optimization, explicit proxy and web caching is handled by half of the CPU cores in a FortiGate unit. For example, if your FortiGate unit has 4 CPU cores, by default two will be used for WAN optimization, explicit proxy and web caching. You can use the following command to change the number of CPU cores that are used.

config system global set wad-worker-count <number>

end

The value for <number> can be between 1 and the total number of CPU cores in your FortiGate unit. Adding more cores may enhance WAN optimization, explicit proxy and web caching performance and reduce the performance of other FortiGate systems.

Dispatching traffic to WAD worker based on source affinity

The wad-worker balancing algorithm supports a more balanced dispersal of traffic to the wad processes even, if the bulk of the traffic is coming from a small set of, or single source.

By default, dispatching traffic to WAD workers is based on source affinity. This may negatively affect performance when users have another explicit proxy in front of the FortiGate. Source affinity causes the FortiGate to process the traffic as if it originated from the single (or small set of ) ip address of the outside proxy. This results in the use of one, or a small number, of WAD processes.

By disabling wad-source-affinity the traffic is balanced over all of the WAD processes. When the wadsource-affinity is disabled, the WAD dispatcher will not assign the traffic based on the source IP, but will assign the traffic to available workers in a round-robin fashion.

Toggling disk usage for logging or wan-opt                  Secure web gateway, WAN optimization, web caching and WCCP

Handling the traffic by different WAD workers results in losing some of the benefits of using source affinity, as is explained by the warning message that appears when it is disabled:

“WARNING: Disabling this option results in some features to be unsupported. IP-based user authentication, disclaimer messages, security profile override, authentication cookies, MAPI scanning, and some video caches such as YouTube are not supported.

Do you want to continue? (y/n)”

CLI

config system global set wad-source-affinity {enable|disable}

end

Toggling disk usage for logging or wan-opt

Both logging and WAN Optimization use hard disk space to save data. In FortiOS, you cannot use the same hard disk for WAN Optimization and logging.

  • If the FortiGate has one hard disk, then it can be used for either disk logging or WAN optimization, but not both. By default, the hard disk is used for disk logging.
  • If the FortiGate has two hard disks, then one disk is always used for disk logging and the other disk is always used for WAN optimization.

On the FortiGate, go to System > Advanced > Disk Settings to switch between Local Log and WAN Optimization.

You can also change disk usage from the CLI using the following command:

configure system global set disk-usage {log | wanopt}

end

You can configure WAN Optimization from the CLI or the GUI. To configure WAN Optimization from the GUI you must go to System > Feature Visibility and turn on WAN Optimization.

Enabling WAN optimization affects more than just disk logging

In addition to affecting WAN Optimization, the following table shows other features affected by the FortiGate disk configuration.

Features affected by Disk Usage as per the number of internal hard disks on the FortiGate

Feature Logging Only (1 hard disk) WAN Opt. Only

(1 hard disk)

Logging & WAN Opt.

(2 hard disks)

Logging Supported Not supported Supported
Report/Historical FortiView Supported Not supported Supported
Firewall Packet

Capture (Policy

Capture and

Interface Capture)

Supported Not supported Supported
AV Quarantine Supported Not supported Supported
IPS Packet Capture Supported. Not supported Supported
DLP Archive Supported Not supported Supported
Sandbox

DB & Results

FortiSandbox database and results are also stored on disk, but will not be affected by this feature.

Firewall schedules

Firewall schedules

Firewall schedules control when policies are in effect. When you add a security policy on a FortiGate unit you need to set a schedule to determine the time frame in which that the policy will be functioning. While it is not set by default, the normal schedule would be always. This would mean that the policy that has been created is always function and always policing the traffic going through the FortiGate. The time component of the schedule is based on a 24 hour clock notation or military time as some people would say.

There are two types of schedules: One-time schedules and recurring schedules.

One-time schedule object

One-Time schedules are in effect only once for the period of time specified in the schedule. This can be useful for testing to limit how long a policy will be in effect in case it is not removed, or it can be used for isolated events such as a conference where you will only need a temporary infrastructure change for a few days.

The time frame for a One-time schedule is configured by using a start time which includes, Year | Month | Day | Hour | Minute and a Stop time which includes the same variables. So while the frequency of the schedule is only once it can last anywhere from 1 minute to multiple years. Configuring a one-time schedule object in the GUI

  1. Go to Policy & Objects > Schedules.
  2. Select Create New. A drop down menu is displayed. Select Schedule.
  3. From the Type options, choose One-time.
  4. Input a Name for the schedule object.
  5. If you which to add a Color to the icon in the GUI, you can click on the Change link to choose 1 of 32 color options.
  6. Choose a Start Date.

Selecting the field with the mouse will bring up a interactive calendar graphic that will allow the user to select the date. The date can also be typed in using the format YYYY/MM/DD.

  1. Choose a Start Time.

The Start Time is composed of two fields, Hour and Minute. Think of setting the time for a digital clock in 24 hour mode. The Hour value can be an integer from 0 and 23. The Minute value can be from 0 to 59. 0 and 0 would be midnight at the start of the day and 23 and 59 would be one minute to midnight at the end of the day. The value can be entered by keyboard or by using the up and down arrows in the field to select the value.

  1. Choose an End Date.

Configuration is the same as Start Date.

  1. Choose a Stop Time.

Configuration is the same as Start Time.

  1. Enable/Disable Pre-expiration event log.

This configures the system to create an event log 1 to 100 days before the End Date as a warning in case the schedule needs to be extended.

  1. If the Pre-expiration event log is enabled, set the value for Number of days before.
  2. Press OK.

Example: Firewall schedule – one-time

The company wants to change over their web site image to reference the new year. They have decided to take this opportunity to do some hardware upgrades as well. Their web site is business oriented so they have determined that over New Year’s Eve there will be very limited traffic.

l They are going to need a maintenance window of 2 hours bracketing midnight on New Year’s Eve.

Configuration in the GUI
  1. Go to Policy & Objects > Objects > Schedule.
  2. Select Create New > Schedule.
  3. Fill out the fields with the following information:
Type One-time
Name NewYearsEve_Maintenance
Start Date 2014/12/31 <use the built in calendar>
End Date 2015/01/01 <use the built in calendar>
Start Time Hour: 23, Minute: 0
Stop Time Hour: 1Minute: 0
Pre-expiration event log <disable>
  1. Select OK.

To verify that the schedule was added correctly:

  1. Go to Policy & Objects > Objects > Schedule.
  2. Check that the schedule with the name you used has been added to the list of recurring schedules and that the listed settings are correct.
Configuration in the CLI
  1. Enter the following CLI command:

config firewall schedule onetime edit maintenance_window set start 23:00 2012/12/31 set end 01:00 2013/01/01 next

end

To verify that the schedule was added correctly:

  1. Enter the following CLI command:

config firewall schedule onetime edit <the name of the schedule you wish to verify> show full-configuration

Recurring schedule object

Recurring schedules are in effect repeatedly at specified times of specified days of the week. The Recurring schedule is based on a repeating cycle of the days of the week as opposed to every x days or days of the month. This means that you can configure the schedule to be in effect on Tuesday, Thursday, and Saturday but not every 2 days or on odd numbered days of the month.

If a recurring schedule has a stop time that is earlier than the start time, the schedule will take effect at the start time but end at the stop time on the next day. You can use this technique to create recurring schedules that run from one day to the next.

Configuring a recurring schedule object in the GUI

  1. Go to Policy & Objects > Schedules.
  2. Select Create New. A drop down menu is displayed. Select Schedule.
  3. From the Type options, choose Recurring.
  4. Input a Name for the schedule object.
  5. If you which to add a Color to the icon in the GUI, you can click on the Change link to choose 1 of 32 color options.
  6. From the Days options, choose the day of the week that you would like this schedule to apply to. The schedule will be in effect on the days of the week that have a check mark in the checkbox to the left of the name of the weekday.
  7. If the scheduled time is the whole day, leave the All Day toggle switch enabled. If the schedule is for specific times during the day, disable the All Day toggle switch.
  8. If the All Day option is disabled, choose a Start Time.

The Start Time is composed of two fields, Hour and Minute. Think of setting the time for a digital clock in 24 hour mode. The Hour value can be an integer from 0 and 23. The Minute value can be from 0 to 59. 0 and 0 would be midnight at the start of the day and 23 and 59 would be one minute to midnight at the end of the day. The value can be entered by keyboard or by using the up and down arrows in the field to select the value.

  1. Choose a Stop Time.

Configuration is the same as Start Time.

  1. Press OK.

Because recurring schedules do not work with DENY policies, the strategy when designing a schedule should not be to determine when users cannot access a policy but to build the schedules around when it is possible to access the policy.

Example: Firewall schedule – recurring

The Company wants to allow the use of Facebook by employees, but only during none business hours and the lunch break.

  • The business hours are 9:00 p.m. to 6:00 p.m. l The Lunch break is 12:00 p.m. to 1:00 p.m.
  • The plan is to create a schedule to cover the morning business hours and the afternoon business hours and block access to the Facebook web site during that time.
Configuration in the GUI
  1. Go to Policy & Objects > Objects > Schedule.
  2. Select Create New > Schedule.
  3. Fill out the fields with the following information:
Type Recurring
Name Morning_Business_Hours
Days Monday, Tuesday, Wednesday, Thursday, Friday
Start Time Hour = 9, Minute = 0
Stop Time Hour = 12, Minute = 0
  1. Select OK.
  2. Create a second new schedule.
Type Recurring
Name Morning_Business_Hours
Days Monday, Tuesday, Wednesday, Thursday, Friday
Start Time Hour = 13, Minute = 0
Stop Time Hour = 18, Minute = 0
  1. Select OK.

To verify that the schedule was added correctly:

  1. Go to Policy & Objects > Objects > Schedule.
  2. Check that the schedule with the name you used has been added to the list of recurring schedules and that the listed settings are correct.
Configuration in the CLI
  1. Enter the following CLI command:

config firewall schedule recurring edit Morning_Business_Hours

set day monday tuesday wednesday thursday friday set start 09:00 set end 12:00

end

  1. Enter the following CLI command:

config firewall schedule recurring edit Afternoon_Business_Hours set day monday tuesday wednesday thursday friday set start 13:00 set end 18:00

end

To verify that the schedule was added correctly:

  1. Enter the following CLI command:

config firewall schedule recurring edit <the name of the schedule you wish to verify> show full-configuration

Schedule groups

You can organize multiple firewall schedules into a schedule group to simplify your security policy list. The schedule parameter in the policy configuration does not allow for the entering of multiple schedules into a single policy so if you have a combination of time frames that you want to schedule the policy for then the best approach, rather than making multiple policies is to use a schedule group.

Creating a schedule group object

  1. Go to Policy & Objects > Schedules.
  2. Select Create New. A drop down menu is displayed. Select Schedule Group
  3. Input a Name for the schedule object.
  4. In the Members field, select the “+” to bring forth the panel for selecting entries.
  5. Press OK.

Example

Your Internet policy allows employees to visit Social Media sites from company computers but not during what is considered working hours. The offices are open a few hours before working hours and the doors are not locked until a few hours after official closing so work hours are from 9 to 5 with a lunch break from Noon to 1:00 p.m.

Your approach is to block the traffic between 9 and noon and between 1:00 p.m. and 5:00 p.m. This means you will need two schedules for a single policy and the schedule group handles this for you. Schedule groups can contain both recurring and one-time schedules. Schedule groups cannot contain other schedule groups.

Schedule expiration

The schedule in a security policy enables certain aspects of network traffic to occur for a specific length of time. What it does not do however, is police that time. That is, the policy is active for a given time frame, and as long as the session is open, traffic can continue to flow.

For example, in an office environment, Skype use is allowed between noon and 1pm. During that hour, any Skype traffic continues. As long as that session is open, after the 1pm end time, the Skype conversations can continue, yet new sessions will be blocked. Ideally, the Skype session should close at 1pm.

Using a CLI command you can set the schedule to terminate all sessions when the end time of the schedule is reached. Within the config firewall command enter the command: set schedule-timeout enable

By default, this option is set to disable.

A few further settings are needed to make this work.

config firewall policy edit ID set firewall-session-dirty check-new end

config system settings set firewall-session-dirty check-policy-option end

Firewall-session-dirty setting

The firewall-session-dirty setting has three options

check-all CPU flushes all current sessions and re-evaluates them. [default]
check-new CPU keeps existing sessions and applies policy changes to new sessions only. This reduces CPU load and the possibility of packet loss.
check-policy-option Use the option selected in the firewall-session-dirty field of the firewall policy (check-all or check-new, as above, but per policy).

 

Services

Services

While there are a number of services already configured within FortiOS, the firmware allows for administrators to configure there own. The reasons for doing this usually fall into one or more of the following categories:

  • The service is not common enough to have a standard configuration l The service is not established enough to have a standard configuration l The service has a standard port number but there is a reason to use a different one:
  • Port is already in use by another service l For security reasons, want to avoid standard port

When looking at the list of preconfigured services it may seem like there are a lot, but keep in mind that the theoretical limit for port numbers is 65,535. This gives a fairly good sized range when you are choosing what port to assign a service but there are a few points to keep in mind.

  • Most of the well known ports are in the range 0 – 1023 l Most ports assigned by the Internet Corporation for Assigned Names and Numbers (ICANN) will be in the 1024 –

49151 range l Port numbers between 49,152 and 65,535 are often used for dynamic, private or ephemeral ports.

There are 3 Service objects that can be added and configured:

l Categories l Services l Service Groups

Categories

In order to make sorting through the services easier, there is a field to categorize the services. Because selecting a category is part of the process for creating a new service, the configuration of categories will be explained first.

The services can be sorted into the following groups:

  • General l Web Access l File Access l Email l Network Services l Authentication l Remote Access l Tunneling l VoIP, Messaging and Other Applications l Web Proxy
  • Uncategorized

The categories are for organization purposes so there is not many settings when creating a new one.

Creating a new service category

  1. Go to Policy & Objects > Services.
  2. Select Create New. A drop down menu is displayed. Select Category
  3. Input a Name for the category.
  4. Input any additional information in the Comments
  5. Press OK.

Example

You plan on adding a number of devices such as web cameras that will allow the monitoring of the physical security of your datacenter. A number of non-standard services will have to be created and you would like to keep them grouped together under the heading of “Surveillance”

Example of a new category in the GUI
  1. Go to Policy & Objects > Objects > Services and select Create New > Category. 2. Fill out the fields with the following information
Field   Value
Name   Surveillance
Comments   For DataCenter Surveillance Devices
  1. Select OK.
Example of a New Category in the CLI

Enter the following CLI command:

config firewall service category edit Surveillance set comment “For DataCenter Surveillance Devices” end

To verify that the category was added correctly:

  1. Go to Policy & Objects > Objects > Services. Select the Category Settings icon . A listing of the categories should be displayed.
  2. Enter the following CLI command:

config firewall service category show

This should bring up all of the categories. Check to see that the new one is displayed.

Configuring a new service

Occasionally, the preconfigured list of services will not contain the needed service. There are a few variations in the creation of a service depending upon the protocol type, but the first steps in the creation of the service are common to all the variations.

To create a new service:

  1. Go to Policy & Objects > Services.
  2. Select Create New. A drop down menu is displayed. Select Service
  3. Enter a name in the Name field for the new service
  4. Include any description you would like in the Comments field
  5. In the Service Type field choose between Firewall and Explicit Proxy.
  6. Enable the toggle in the Show in Service List. If you can’t see the service when you need to select it, it serves very little purpose.
  7. For the Category field, choose the appropriate category from the Category drop down menu. If none is chosen, the Uncategorized option will be chosen by default.

Protocol options

This is the section where the configuration options of the service will differ depending on the type of protocol chosen. (The Step numbers will all continue on from the common step sequence).

The protocol options for Firewall service type are: l TCP/UDP/SCTP l ICMP l ICMP6 l IP

The protocol options for Proxy service type are: l ALL l CONNECT

l FTP l HTTP l SOCKS-TCP l SOCKS-UDP

TCP/UDP/SCTP
  1. For the Protocol Type field, choose TCP/UDP/SCTP from the drop down menu
  2. For the Address field, choose IP Range or FQDN (Fully Qualified Domain Name) if there is to be a specific destination for the service. Depending on which type of address is selected, the field value needs to be filled with a FQDN string or an IP address in one of the 3 standard IPv4 address formats: l x.x.x – for a specific address l x.x.x.x/x – for a subnet l x.x.x.x-x.x.x.x – for a range of specific addresses
  3. Configure the Destination Port by:
    • Select from the drop down menu, TCP, UDP or SCTP l Enter the low end to the port range in the field indicated by grayed out Low.
    • Enter the high end of the port range in the field indicated by grayed out High. If there is only a single port in the

range High can be left empty

  • Multiple ports or port ranges can be added by using the “+” at the beginning of the row l Rows can be removed by using the trash can symbol at the end of the row
  1. If required, you can Specify Source Ports for the service by enabling the toggle switch.
    • The Src Port will match up with a Destination Port
    • Src Ports cannot be configured without there being a value for the Destination Port l The same rules for configuring the Destination Ports applies to the Src Ports
  2. Select OK to confirm the configuration

Example

Example settings for a TCP protocol service. In this case, it is for an administrative connection to web servers on the DMZ. The protocol used is HTTPS which would normally use port 443, but that is already in use by another service such as Admin access to the firewall or an SSL-VPN connection.

Field Value
Name Example.com_WebAdmin
Comments Admin connection to Example.com Website
Service Type Firewall
Show in Service List enabled
Category Web Access
Field Value
Protocol Options  
Protocol Type TCP/UDP/SCTP
IP/FQDN <left blank>
Destination Port l  Protocol: TCP l Low: 4300

l  High: <left blank>

Specify Source Ports <disabled>

Creating a new TCP/UDP/SCTP service in the CLI

The following is the creation of the same service using the command line.

config firewall service custom edit Example.com_WebAdmin set comment “Admin connection to Example.com Website” set category Web Access set protocol TCP/UDP/SCTP set tcp-portrange 4300

end

end

ICMP / ICMP6
  1. For the Protocol Type field, choose ICMP or ICMP6 from the drop down menu
  2. In the Type field enter the appropriate type number based on the information found in “ICMP Types and Codes” on page 1 or in “ICMPv6 Types and Codes” on page 1, depending on whether the Protocol Type is ICMP or ICMPv6
  3. In the Code field enter the appropriate code number for the type, if applicable, based on the information found in

“ICMP Types and Codes” on page 1 or in “ICMPv6 Types and Codes” on page 1, depending on whether the Protocol Type is ICMP or ICMPv6

  1. Select OK to confirm the configuration

Example

Example settings for an ICMP.service.In this case it has been set up for some special testing of ICMP packets.

Field Value
Name ICMP test #4
Comments For testing of proprietary network scanner
Service Type Firewall
Field Value
Show in Service List enabled
Category Network Services
Protocol Options  
Protocol Type ICMP
Type 7
Code <left blank>

Creating a new ICMP service in the CLI

The following is the creation of the same service using the command line.

config firewall service custom edit ICMP test4 set comment “For testing of proprietary network scanner” set category Network Services set protocol ICMP set icmptype 7

end

end

IP
  1. For the Protocol Type field, choose IP from the drop down menu
  2. In the Protocol Number field enter the numeric value based on the information found in “Protocol Number” on page 1
  3. Select OK to confirm the configuration

Example

Example settings for an IP.service.In this case it has been set up to communicate via an old protocol called QNX

Field Value
Name QNX
Comments For QNX communications to the Development Lab
Service Type Firewall
Show in Service List enabled
Category Uncategorized
Field Value
Protocol Options  
Protocol Type IP
Protocol Number 106

Creating a new ICMP service in the CLI

The following is the creation of the same service using the command line.

config firewall service custom edit ICMP test4 set comment “For QNX communications to the Development Lab ” set protocol IP set icmptype 106

end

end

In the CLI examples, the fields for Show in Service List, Service Type and in the example for IP, Category were net set because the values that they would have been set to were the default values and were already correctly set.

ALL/CONNECT/FTP/HTTP/SOCKS-TCP/SOCKS-UDP

These options are available only if the Service Type is set to Explicit Proxy.

  1. For the Protocol Type field, choose one of the following from the drop down menu: l ALL l CONNECT l FTP l HTTP l SOCKS-TCP l SOCKS-UDP
  2. For the Address field, choose IP Range or FQDN (Fully Qualified Domain Name) if there is to be a specific destination for the service. Depending on which type of address is selected, the field value needs to be filled with a FQDN string or an IP address in one of the 3 standard IPv4 address formats: l x.x.x – for a specific address l x.x.x.x/x – for a subnet l x.x.x.x-x.x.x.x – for a range of specific addresses
  3. Configure the Destination Port by:
    • Enter the low end to the TCP port range in the field indicated by grayed out Low.
    • Enter the high end of the TCP port range in the field indicated by grayed out High. If there is only a single port

in the range High can be left empty

  • Multiple ports or port ranges can be added by using the “+” at the beginning of the row l Rows can be removed by using the trash can symbol at the end of the row
  1. If required, you can Specify Source Ports for the service by enabling the toggle switch.
    • The Src Port will match up with a Destination Port
    • Src Ports cannot be configured without there being a value for the Destination Port l The same rules for configuring the Destination Ports applies to the Src Ports
  2. Select OK to confirm the configuration

Specific addresses in TCP/UDP/SCTP

In the TCP/UDP/SCTP services it is also possible to set the parameter for a specific IP or Fully Qualified Domain Name address. The IP/FQDN field refers to the destination address of the traffic, not the source. This means for example, that you can set up a custom service that will describe in a policy the TCP traffic over port 80 going to the web site example.com, but you cannot set up a service that describes the TCP traffic over port 80 that is coming from the computer with the address 192.168.29.59.

Service groups

Just like some of the other firewall components, services can also be bundled into groups for ease of administration.

Creating a service group

  1. Go to Policy & Objects > Services.
  2. Select Create New. A drop down menu is displayed. Select Service Group Input a Group Name to describe the services being grouped
  3. Input any additional information in the Comments
  4. Choose a Type of group.The options are Firewall or Explicit Proxy.
  5. Add to the list of Members from the drop down menu. Using the + sign beside the field will allow the addition of multiple services.
  6. Press OK.

Example

Example of a New Service Group:

Field Value
Group Name Authentication Services
Comments Services used in Authentication
Type Firewall

 

Field Value  
Members l l l Kerberos

LDAP

LDAP_UDP

  l RADIUS

Configuring IP pools

Configuring IP pools

An IP pool is essentially one in which the IP address that is assigned to the sending computer is not known until the session is created, therefore at the very least it will have to be a pool of at least 2 potential addresses. A quick example would be an IP pool for users of a VPN. IP pools are based upon the version of IP determined by the interface that they are associated with so as expected there are two types of IP pools that can be configured:

l “Creating a IPv4 pool” on page 243 l “Creating a IPv6 pool” on page 247

Because of the differences in the configuration for the two types of pools, instructions for configuring them will be done separately.

Creating a IPv4 pool

  1. Go to Policy & Objects > IP Pools.
  2. Select Create New.
  3. In the IP Pool Type field choose IPv4 Pool
  4. Enter a name in the Name field for the new service Include any description you would like in the Comments field
  5. In the Type field choose between:

l Overload l One-to-One l Fixed Port Range l Port Block Allocation

At this point the configurations can start to differ based on the type of type of pool.

For more information on the different types of IP pools, check IP Pools in the Concepts section.

Overload

  1. For the External IP Range fields, enter the lowest and highest addresses in the range. If you only want a single address used, enter the same address in both fields.
  2. Enable the ARP Reply field by making sure there is a check in the box
  3. Select OK
Overload example for GUI

In this example, the Sales team needs to connect to an Application Service Provider that does the accounting for the company. As a security measure, the ASP only accepts traffic from a white list of IP addresses. There is 1 public IP address of the company on that list.The Sales team consists of 40 people, so they need to share.The external interface is wan1.

Field Value
IP Pool Type IPv4 Pool
Name Sales_Team
Comments For the Sales team to use to connect to the Accounting ASP
Type Overload (This is the default)
External IP Range 10.23.56.20 – 10.23.56.20
ARP Reply enabled
Overload example for CLI

config firewall ippool edit Sales_Team set comments “For the Sales team to use to connect to the Accounting ASP”

set type overload set startip 10.23.56.20 set endip 10.23.56.20 set arp-reply enable set arp-intf wan1 end

One-to-one

  1. For the External IP Range fields, enter the lowest and highest addresses in the range. If you only want a single address used, enter the same address in both fields.
  2. Enable the ARP Reply field by making sure there is a check in the box.
  3. Select OK
One-to-one example for GUI

In this example, the external IP address of the mail server is part of a range assigned to the company but not the one that is assigned to the Internet facing interface. A VIP has been set up but in order to properly resolve Reverse DNS lookups the mail server always has to use a specific IP address.The external interface is wan1.

Field Value
IP Pool Type IPv4 Pool
Name Mail-Server
Comments So the correct IP address is resolved on Reverse DNS look ups of the mail server.
Type One-to-one
External IP Range 10.23.56.21 – 10.23.56.21
ARP Reply enabled
One-to-one example for CLI

config firewall ippool edit Mail-Server set comments “So the the correct IP address is resolved on reverse DNS look ups of the mail server.”

set type one-to-one set startip 10.23.56.21 set endip 10.23.56.21 set arp-reply enable set arp-intf wan1 end

Fixed port range

  1. For the External IP Range fields, enter the lowest and highest addresses in the range. If you only want a single address used, enter the same address in both fields.
  2. Fort the Internal IP Range fields, enter the lowest and highest addresses in the range.
  3. Enable the ARP Reply field by making sure there is a check in the box
  4. Select OK
Fixed port range example for GUI

In this example, the company has a range of 10 IP address that they want to be used by employees on a specific subnet for NATing.The external interface is wan1.

Field Value
IP Pool Type IPv4 Pool
Name IPPool-3
Comments IP range to be used by outgoing traffic
Type Fixed Port Range
External IP Range 10.23.56.22 – 10.23.56.31
Internal IP Range 192.168.23.1 – 192.168.23.254
ARP Reply enabled
Fixed port range example for CLI

config firewall ippool edit IPPool-3 set comments “So the the correct IP address is resolved on reverse DNS look ups of the mail server.”

set type fixed-port-range set startip 10.23.56.22 set endip 10.23.56.31 set source-startip 192.168.23.1 set source-endip 192.168.23.254 set arp-reply enable set arp-intf wan1 end

Port block allocation

  1. For the External IP Range fields, enter the lowest and highest addresses in the range. If you only want a single address used, enter the same address in both fields.
  2. In the Block Size field, either type in the value or use the up or down arrows to set the value of the block size.
  3. In the Blocks Per User field, either type in the value or use the up or down arrows to set the value for the number of blocks per user.
  4. Enable the ARP Reply field by making sure there is a check in the box
  5. Select OK
Port block allocation timeout

The port block allocation timeout value is configurable. The setting is found in the CLI.

The option pba-timeout has been added to the firewall ip pool configuration. The availability of this option is dependent on the type option being set to port-block-allocation. The timeout value is measured in seconds and is an integer between 3 and 300, with the default being 30.

Syntax:

config firewall ippool

edit <name of PBA pool> set type port-block-allocation set pba-timeout <integer> end

Port block allocation example for GUI

In this example, an small ISP is setting up NATing for its clients, but to be fair it is putting some restrictions on the number of connections each client can have so that no one hogs all of the possible ports and addresses.The external interface is port12.

Field Value
IP Pool Type IPv4 Pool
Name Client-IPPool
Comments IP Pool for clients to access the Internet
Type Port Block Allocation
External IP Range 10.23.75.5 – 10.23.75.200
Block Size 64
Blocks Per User 8
ARP Reply enabled
Port block allocation example for CLI

config firewall ippool edit Client-IPPool set comments “IP Pool for clients to access the Internet”

set type port-block-allocation set startip 10.23.75.5 set endip 10.23.75.200 set block-size 64 set num-blocks-per-user 8 set permit-any-host disable set arp-intf wan1 set arp-reply enableset arp-intf port12

end

Creating a IPv6 pool

  1. Go to Policy & Objects > IP Pools.
  2. Select Create New.
  3. In the IP Pool Type field choose IPv6 Pool
  4. Enter a name in the Name field for the new service
  5. Include any description you would like in the Comments field
  6. For the External IP Range fields, enter the lowest and highest addresses in the range.

IPv6 example for GUI

In this example, there is a similar situation to the One-to-one example earlier.There is a mail server that needs to be resolved to a specific IP address in Reverse DNS look-ups. The difference in this case is the company is an early adopter of IPv6 connectivity to the Internet.

Field Value
IP Pool Type IPv6 Pool
Name Mail-svr-ipv6
Comments Registered IPv6 address for mail server
External IP Range fd2f:50ec:cdea:0663::1025 – fd2f:50ec:cdea:0663::1025

Port block allocation example for CLI

config firewall ippool6 edit Mail-svr-ipv6 set comments “Registered IPv6 address for mail server”

set startip fd2f:50ec:cdea:663::102 set endip fd2f:50ec:cdea:663::1025 end

Creating NAT46 IP pool and multiple (secondary) NAT64 prefixes

Policies that translate between IPv4 and IPv6 can use IPv4 address pools or IPv6 prefixes to be used in the policies, giving more options to the configuration of addresses.

NAT46

For using the ippool in NAT46 policies, first enable the use of ippools and then set the names of the ippool(s).

config firewall policy46 edit 1 set uuid e9c6ca3e-72ea-51e7-554a-1185693d03eb

set srcintf “wan1” set dstintf “internal7” set srcaddr “external-net4” set dstaddr “internal-vip46” set action accept set schedule “always”

 

set service “ALL” set ippool enable set poolname “intit-pool6” end

NAT64

In order to use these options in the NAT64 firewall policies the new settingssecondary-prefix status and secondary-prefix options have to be configured as in the example below.

config system nat64 set nat64-prefix 2001::/96 set secondary-prefix enable config secondary-prefix edit 1 set nat64-prefix 2002::/94

next

edit 2 set nat64-prefix 2003::/95

end end