Web cache configuration

Forwarding URLs to forwarding servers and exempting web sites from web caching

You can go to Network > Explicit Proxy and use the URL match list to forward URL patterns to forwarding servers and create a list of URLs that are exempt from web caching.

Forwarding URLs and URL patterns to forwarding servers

As part of configuring the explicit web proxy you can configure proxy chaining by adding web proxy forwarding servers. See Proxy chaining (web proxy forwarding servers) .

You can then use the URL match list to always forward explicit web proxy traffic destined for configured URLs or URL patterns to one of these forwarding servers. For example, you might want to forward all traffic for a specific country to a proxy server located in that country.

To forward traffic destined for a URL to a forwarding server that you have already added, go to Network > Explicit Proxy and select Create New. Add a name for the URL match entry and enter the URL or URL pattern. You can use wildcards such as * and ? and you can use a numeric IP address. Select Forward to Server and select a web proxy forwarding server from the list.

You can also exempt the URL or URL pattern from web caching.

Use the following command to forward all .ca traffic to a proxy server and all .com traffic to another proxy server.

config web-proxy url-match edit “com” set forward-server “server-commercial” set url-pattern “com”

next edit “ca” set forward-server “server-canada” set url-pattern “ca”

next

edit “www.google.ca” set cache-exemption enable set url-pattern “www.google.ca”

next

end

Exempting web sites from web caching

You may want to exempt some URLs from web caching for a number of reasons. For example, if your users access websites that are not compatible with FortiGate web caching you can add the URLs of these web sites to the web caching exempt list. You can add URLs and numeric IP addresses to the web cache exempt list.

You can also add URLs to the web cache exempt list by going to Network > Explicit Proxy, going to the URL Match List

Web cache configuration                  Forwarding URLs to forwarding servers and exempting web sites from web caching

and selecting Create New. Add a URL pattern to be exempt and select Exempt from Cache.

You can also add URLs and addresses to be exempt from caching using the CLI. Enter the following command to add www.example.com to the web cache exempt list:

config web-proxy url-match set cache-exemption enable set url-pattern www.example.com

end

Exempting specific files from caching

You can exempt files from being cached, so long as you specify its full URL. Enter the following command to add the URL, with the file extension (in this example, .exe), to the web cache exempt list:

config web-proxy url-match edit “exe” set url-pattern “iavs9x.u.avast.com/custom/iavs9x/20160613t1237z/avast_free_ antivirus_setup_online.exe”

set cache-exemption enable

next end

Monitoring web caching performance

The web cache monitor shows the percentage of web cache requests that retrieved content from the cache (hits) and the percentage that did not receive content from the cache (misses). A higher the number of hits usually indicates that the web cache is being more effective at reducing WAN traffic.

The web cache monitor also shows a graph of web traffic on the WAN and LAN. A lower WAN line on the graph indicates the web cache is reducing traffic on the WAN. The web cache monitor also displays the total number of web requests processed by the web cache.

To view the web cache monitor, go to Monitor > Cache Monitor.

Web cache monitor

Example web caching of HTTP and HTTPS Internet content for users on an internal network

This example describes how to configure web caching of HTTP and HTTPS for users on a private network connecting to the Internet.

Network topology and assumptions

This example includes a client network with subnet address 10.31.101.0 connecting to web servers on the

Internet. All of the users on the private network access the Internet though a single general security policy on the FortiGate unit that accepts all sessions connecting to the Internet. Web caching for HTTP and HTTPS traffic is added to this security policy.

Since users on the private network have unrestricted access to the Internet and can be accessing many web servers the webcache-https is set to any and users may see error messages on their web browsers when accessing HTTPS content.

The GUI is less versatile than the CLI so the example instructions for the GUI give settings for one port for each protocol, while the CLI example shows how to use multiple ports.

Web cache configuration      Example web caching of HTTP and HTTPS Internet content for users on an internal network

The example also describes how to configure the security policy to cache HTTP traffic on port 80 and 8080 in the CLI, by adding a proxy options profile that looks for HTTP traffic on TCP ports 80 and 8080. The example also describes how to configure the security policy to cache HTTPS traffic on port 443 and 8443 using the same proxy options profile.

Example web caching topology

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. Add HTTP web caching to the security policy that all users on the private network use to connect to the Internet.
2. Add HTTPS web caching.
3. Add a protocol options profile to look for HTTP traffic on ports 80 and 8080 and HTTPS traffic on ports 443 and 8443 and add this protocol options profile to the security policy.

If you perform any additional actions between procedures, your configuration may have different results.

Configuration steps – web-based manager

Use the following steps to configure the example configuration from the FortiGate web-based manager.

To add HTTP web caching to a security policy

1. Go to Policy & Objects > IPv4 Policyand add a security policy that allows all users on the internal network to access the Internet.

Incoming Interface	Internal
Outgoing Interface	wan1
Source	all
Destination	all
Schedule	always
Service	ALL
Action	ACCEPT

2. Toggle NAT to enabled, and select Use Outgoing Interface Address.
3. Turn on Web cache.
4. Select OK.

Example web caching of HTTP and HTTPS Internet content for users on an internal network      Web cache configuration

To add HTTPS web caching

1. From the CLI enter the following command to add HTTPS web caching to the policy.

Assume the index number of the policy is 5.

config firewall policy edit 5 set webcache-https any

end

To cache HTTP traffic on port 80 and HTTPS on 8443

1. Go to Network > Explicit Proxy and edit the Explicit Proxy options profile. 2. Under Explicit Web Proxy , l For the HTTP port, enter 80.

l For HTTPS port, select Specify and enter 8443 in the field.

3. Click on Apply.

Configuration steps – CLI

Use the following steps to configure the example configuration from the FortiGate CLI.

To add HTTP and HTTPS web caching to a security policy

1. Enter the following command to add a security policy that allows all users on the internal network to access the Internet and that includes web caching of HTTP and HTTPS traffic.

config firewall policy edit 0 set srcintf internal set srcaddr all set dstintf wan1 set distinf all set schedule always set service ANY set action accept set nat enable set webcache enable set webcache-https any

end

To cache HTTP traffic on port 80 and 8080 and HTTPS traffic on ports 443 and 8443

1. Enter the following command to edit the default proxy options profile to configure it to look for HTTP traffic on ports 80 and 8080:

config firewall profile-protocol-options edit default config http set status enable set ports 80 8080

Web cache Example reverse proxy web caching and SSL offloading for an Internet web server using a static configuration          one-to-one virtual IP

end

2. Enter the following command to edit the certification-inspection SSL SSH options profile to configure it to look for HTTPS traffic on ports 443 and 8443:

config firewall ssl-ssh-profile edit certificate-inspection config https set status certificate-inspection

set ports 443 8443 end

3. Enter the following command to add the default proxy options profile and the certificate-inspection SSL SSH profile to the firewall policy.

config firewall policy edit 5 set utm-status enable set profile-protocol-options default set ssl-ssh-profile certificate-inspection end

Example reverse proxy web caching and SSL offloading for an Internet web server using a static one-to-one virtual IP

This section describes configuring SSL offloading for a reverse proxy web caching configuration using a static one-to-one firewall virtual IP (VIP). While the static one-to-one configuration described in this example is valid, its also common to change the destination port of the unencrypted HTTPS traffic to a commonly used HTTP port such as 8080 using a port forwarding virtual IP.

Network topology and assumptions

In this configuration, clients on the Internet use HTTP and HTTPS to browse to a web server that is behind a FortiGate unit. A policy added to the FortiGate unit forwards the HTTP traffic to the web server. The policy also offloads HTTPS decryption and encryption from the web server so the web server only sees HTTP traffic.

The FortiGate unit also caches HTTP and HTTPS pages from the web server so when users access cached pages the web server does not see the traffic. Replies to HTTPS sessions are encrypted by the FortiGate unit before returning to the clients.

In this configuration, the FortiGate unit is operating as a web cache in reverse proxy mode. Reverse proxy caches can be placed directly in front of a web server. Web caching on the FortiGate unit reduces the number of requests that the web server must handle, therefore leaving it free to process new requests that it has not serviced before.

Using a reverse proxy configuration:

l avoids the capital expense of additional web servers by increasing the capacity of existing servers l serves more requests for static content from web servers l serves more requests for dynamic content from web servers l reduces operating expenses including the cost of bandwidth required to serve content l accelerates the response time of web servers and of page download times to end users.

Example reverse proxy web caching and SSL offloading for an Internet web server using a static one-to-one virtual IP

Web cache configuration

When planning a reverse proxy implementation, the web server’s content should be written so that it is “cache aware” to take full advantage of the reverse proxy cache.

In reverse proxy mode, the FortiGate unit functions more like a web server for clients on the Internet. Replicated content is delivered from the proxy cache to the external client without exposing the web server or the private network residing safely behind the firewall.

In this example, the site URL translates to IP address 192.168.10.1, which is the port2 IP address of the FortiGate unit. The port2 interface is connected to the Internet.

This example assumes that all HTTP traffic uses port 80 and all HTTPS traffic uses port 443.

The FortiGate unit includes the web server CA and an SSL server configuration for IP address 172.10.20.30 and port to 443. The name of the file containing the CA is Rev_Proxy_Cert_1.crt.

The destination address of incoming HTTP and HTTPS sessions is translated to the IP address of the web server using a static one-to-one virtual IP that performs destination address translation (DNAT) for the HTTP packets. The DNAT translates the destination address of the packets from 192.168.10.1 to 172.10.20.30 but does not change the destination port number.

When the SSL server on the FortiGate unit decrypts the HTTPS packets their destination port is changed to port 80.

Reverse proxy web caching and SSL offloading for an Internet web server using static one-to-one virtual IPs

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. Configure the FortiGate unit as a reverse proxy web cache server.
2. Configure the FortiGate unit for SSL offloading of HTTPS traffic.
3. Add an SSL server to offload SSL encryption and decryption for the web server.

Also note that if you perform any additional actions between procedures, your configuration may have different results.

Web cache configuration

Example reverse proxy web caching and SSL offloading for an Internet web server using a static one-to-one virtual IP

Configuration steps – web-based manager

To configure the FortiGate unit as a reverse proxy web cache server

1. Go to Policy & Objects > Virtual IPsand select Create New to add a static NAT virtual IP that translates destination IP addresses from 192.168.10.1 to 172.10.20.30 (and does not translate destination ports):

VIP Type	IPv4
Name	Reverse_proxy_VIP
Interface	port2
Type	Static NAT
Optional Filters	Do not select.
External IP Address/Range	192.168.10.1
Mapped IP Address/Range	172.10.20.30
Port Forwarding	Do not select.

2. Select OK.
3. Go to Policy & Objects > IPv4 Policy and select Create New to add a port2 to port1 security policy that accepts HTTP and HTTPS traffic from the Internet.

Do not select security profiles. Set the destination address to the virtual IP. You do not have to enable NAT.

Incoming Interface	port2
Outgoing Interface	port1
Source	all
Destination	Reverse_proxy_VIP
Schedule	always
Service	HTTP HTTPS
Action	ACCEPT

4. Turn on Web Cache.
5. Select OK.
6. From the CLI enter the following command to add HTTPS web caching to the security policy

Assume the index number of the policy is 5.

config firewall policy edit 5 set webcache-https ssl-server

Example reverse proxy web caching and SSL offloading for an Internet web server using a static Web cache one-to-one virtual IP         configuration

end

To configure the FortiGate unit to offload SSL encryption and cache HTTPS content

1. Go to System > Certificates and select Import to import the web server’s CA.

For Type, select Local Certificate. Select the Browse button to locate the file (example file name: Rev_Proxy_

Cert_1.crt).

The certificate key size must be 1024 or 2048 bits. 4096-bit keys are not supported.

2. Select OK to import the certificate.
3. From the CLI, enter the following command to add the SSL server and to add the server’s certificate to the SSL server.

The SSL server ip must match the destination address of the SSL traffic after being translated by the virtual IP (172.10.20.30) and the SSL server port must match the destination port of the SSL traffic (443). The SSL server operates in half mode since it performs a single-step conversion (HTTPS to HTTP or HTTP to HTTPS).

config firewall ssl-server edit rev_proxy_server set ip 172.10.20.30 set port 443 set ssl-mode half set ssl-cert Rev_Proxy_Cert_1 end

Configuration steps – CLI

To configure the FortiGate unit as a reverse proxy web cache server

1. Enter the following command to add a static NAT virtual IP that translates destination IP addresses from 192.168.10.1 to 172.10.20.30 (and does not translate destination ports):

config firewall vip edit Reverse_proxy_VIP set extintf port2 set type static-nat set extip 192.168.10.1 set mappedip 172.10.20.30

end

2. Enter the following command to add a port2 to port1 security policy that accepts HTTP and HTTPS traffic from the Internet. Enable web caching and HTTPS web caching.

Do not select security profiles. Set the destination address to the virtual IP. You do not have to enable NAT.

config firewall policy edit 0 set srcintf port2 set srcaddr all set dstintf port1 set dstaddr Reverse_proxy_VIP set schedule always set service HTTP HTTPS set action accept

 

set webcache enable set webcache-https ssl-server

end

To add an SSL server to offload SSL encryption and decryption for the web server

1. Place a copy of the web server’s CA (file name Rev_Proxy_Cert_1.crt) in the root folder of a TFTP server.
2. Enter the following command to import the web server’s CA from a TFTP server. The IP address of the TFTP server is 10.31.101.30:

execute vpn certificate local import tftp Rev_Proxy_Cert_1.crt 10.31.101.30 The certificate key size must be 1024 or 2048 bits. 4096-bit keys are not supported.

3. From the CLI, enter the following command to add the SSL server.

The SSL server ip must match the destination address of the SSL traffic after being translated by the virtual IP (172.10.20.30) and the SSL server port must match the destination port of the SSL traffic (443). The SSL server operates in half mode since it performs a single-step conversion (HTTPS to HTTP or HTTP to HTTPS).

config firewall ssl-server edit rev_proxy_server set ip 172.10.20.30 set port 443 set ssl-mode half set ssl-cert Rev_Proxy_Cert_1

end

4. Configure other ssl-server settings that you may require for your configuration.

Using a FortiCache as a cache service

Some FortiGate devices don’t have sufficient memory or disk space to run a cache service. This feature allows a FortiGate to connect to a FortiCache that has a higher cache capability than most FortiGates.

Syntax:

config wanopt remote-storage set status {enable|disable} set local-cache-id <name ID for connection> set remote-cache-id <ID of the remote device> set remote-cache-ip <IP address of the remote device> end

Option	Description
status	Enable or disable whether the FortiGate uses a remote caching device as web-cache storage. If disabled, uses local disk(s) as web storage.
localcache-id	ID that this device uses to connect to the remote caching device

 

Option	Description
remotecache-id	ID of the remote caching device that this FortiGate connects to
remotecache-ip	IP address of the remote caching device that this FortiGate connects to.

 

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

Web cache concepts

FortiGate web caching is a form of object caching that accelerates web applications and web servers by reducing bandwidth usage, server load, and perceived latency. Web caching supports caching of HTTP 1.0 and HTTP 1.1 web sites. See RFC 2616 for information about web caching for HTTP 1.1.

Web caching supports caching of Flash content over HTTP but does not cache audio and video streams including Flash videos and streaming content that use native streaming protocols such as RTMP.

The first time a file is received by web caching it is cached in the format it is received in, whether it be compressed or uncompressed. When the same file is requested by a client but in a different compression format, the cached file is converted to the new compressed format before being sent to the client.

There are three significant advantages to using web caching to improve HTTP and WAN performance:

• reduced bandwidth consumption because fewer requests and responses go over the WAN or Internet. l reduced web server load because there are fewer requests for web servers to handle.
• reduced latency because responses for cached requests are available from a local FortiGate unit instead of from across the WAN or Internet.

You can use web caching to cache any web traffic that passes through the FortiGate unit, including web pages from web servers on a LAN, WAN or on the Internet. You apply web caching by enabling the web caching option in any security policy. When enabled in a security policy, web caching is applied to all HTTP sessions accepted by the security policy. If the security policy is an explicit web proxy security policy, the FortiGate unit caches explicit web proxy sessions.

Turning on web caching for HTTP and HTTPS traffic

Web caching can be applied to any HTTP or HTTPS traffic by enabling web caching in a security policy that accepts the traffic. This includes IPv4, IPv6, WAN optimization and explicit web proxy traffic. Web caching caches all HTTP traffic accepted by a policy on TCP port 80.

You can add web caching to a policy to:

• Cache Internet HTTP traffic for users on an internal network to reduce Internet bandwidth use. Do this by selecting the web cache option for security policies that allow users on the internal network to browse web sites on the

Internet.

• Reduce the load on a public facing web server by caching objects on the FortiGate unit. This is a reverse proxy with web caching configuration. Do this by selecting the web cache option for a security policy that allows users on the Internet to connect to the web server.
• Cache outgoing explicit web proxy traffic when the explicit proxy is used to proxy users in an internal network who are connecting to the web servers on the Internet. Do this by selecting the web cache option for explicit web proxy security policies that allow users on the internal network to browse web sites on the Internet.
• Combine web caching with WAN optimization. You can enable web caching in any WAN optimization security policy. This includes manual, active, and passive WAN optimization policies and WAN optimization tunnel policies.

Turning on web caching for HTTPS traffic

You can enable web caching on both the client-side and the server-side FortiGate units or on just one or the other. For optimum performance you can enable web caching on both the client-side and server-side FortiGate units. In this way only uncached content is transmitted through the WAN optimization tunnel. All cached content is access locally by clients from the client side FortiGate unit.

One important use for web caching is to cache software updates (for example, Windows Updates or iOS updates. When updates occur a large number of users may all be trying to download these updates at the same time. Caching these updates will be a major performance improvement and also have a potentially large impact on reducing Internet bandwidth use. You may want to adjust the maximum cache object size to make sure these updates are cached. See Turning on web caching for HTTP and HTTPS traffic on page 325.

Turning on web caching for HTTPS traffic

Web caching can also cache the content of HTTPS traffic on TCP port 443. With HTTPS web caching, the FortiGate unit receives the HTTPS traffic on behalf of the client, opens up the encrypted traffic and extracts content to be cached. Then FortiGate unit re-encrypts the traffic and sends it on to its intended recipient. It is very similar to a man-in-the-middle attack.

You enable HTTPS web caching from the CLI in a security policy or an explicit proxy policy that accepts the traffic to be cached using webcache-https. For a firewall policy:

config firewall policy edit 0 .

. . set webcache enable set webcache-https enable .

.

.

end

For an explicit web proxy policy:

config firewall proxy-policy edit 0 set proxy explicit-web .

. . set webcache enable set webcache-https enable .

.

. end

The webcache-https field is available only if webcache is enabled.

Web caching for HTTPS traffic is not supported if WAN optimization or FTP proxy is enabled: i.e., if srcintf is ftp-proxy or wanopt.

Turning on web caching for HTTPS traffic

The any setting causes the FortiGate unit to re-encrypt the traffic with the FortiGate unit’s certificate rather than the original certificate. This configuration can cause errors for HTTPS clients because the name on the certificate does not match the name on the web site.

You can stop these errors from happening by configuring HTTPS web caching to use the web server’s certificate by setting webcache-https to ssl-server. This option is available for both firewall policies and explicit web proxy policies.

config firewall policy edit 0 .

. . set webcache enable set webcache-https enable .

.

. end

The ssl-server option causes the FortiGate unit to re-encrypt the traffic with a certificate that you imported into the FortiGate unit. You can add certificates using the following command:

config firewall ssl-server edit corporate-server set ip <Web-Server-IP> set port 443 set ssl-mode { full | half} set ssl-cert <Web-Server-Cert>

end Where:

Web-Server-IP is the web server’s IP address.

Web-Server-Cert is a web server certificate imported into the FortiGate unit.

The SSL server configuration also determines whether the SSL server is operating in half or full mode and the port used for the HTTPS traffic.

You can add multiple SSL server certificates in this way. When web caching processing an SSL stream if it can find a certificate that matches the web server IP address and port of one of the added SSL servers; that certificate is used to encrypt the SSL traffic before sending it to the client. As a result the client does not generate SSL certificate errors.

Web caching uses the FortiGate unit’s FortiASIC to accelerate SSL decryption/encryption performance.

Full mode SSL server configuration

The ssl-mode option determines whether the SSL server operates in half or full mode. In full mode the FortiGate unit performs both decryption and encryption of the HTTPS traffic. The full mode sequence is shown below.

Turning on web caching for HTTPS traffic

Full mode SSL server configuration

In full mode the FortiGate unit is acting as a man in the middle, decrypting and encrypting the traffic. So both the client and the web server see encrypted packets.

Usually the port of the encrypted HTTPS traffic is always 443. However, in the SSL server configuration you can set the port used for HTTPS traffic. This port is not altered by the SSL Server. So for example, if the SSL Server receives HTTPS traffic on port 443, the re-encrypted traffic forwarded to the FortiGate unit to the server or client will still use port 443.

Half mode SSL server configuration

In half mode, the FortiGate unit only performs one encryption or decryption action. If HTTP packets are received, the half mode SSL server encrypts them and converts them to HTTPS packets. If HTTPS packets are received, the SSL server decrypts them and converts them to HTTP packets.

Half mode SSL server configuration

In half mode, the FortiGate unit is acting like an SSL accelerator, offloading HTTPS decryption from the web server to the FortiGate unit. Since FortiGate units can accelerate SSL processing, the end result could be improved web site performance.

Usually the port of the encrypted traffic is always 443. However, in the SSL server configuration you can set the port used for HTTPS traffic. No matter what port is used for the HTTPS traffic, the decrypted HTTP traffic uses port 80.

Changing the ports on which to look for HTTP and HTTPS traffic to cache

Changing the ports on which to look for HTTP and HTTPS traffic to cache

By default FortiOS assumes HTTP traffic uses TCP port 80 and HTTPS traffic uses port 443. So web caching caches all HTTP traffic accepted by a policy on TCP port 80 and all HTTPS traffic on TCP port 443. If you want to cache HTTP or HTTPS traffic on other ports, you can enable security profiles for the security policy and configure a proxy options profile to that looks for HTTP and HTTPS traffic on other TCP ports. To configure a proxy options profile go to Network > Explicit Proxy.

Setting the HTTP port to Any in a proxy options profile is not compatible with web caching. If you set the HTTP port to any, web caching only caches HTTP traffic on port 80.

Web caching and HA

You can configure web caching on a FortiGate HA cluster. The recommended best practice HA configuration for web caching is active-passive mode. When the cluster is operating, all web caching sessions are processed by the primary unit only. Even if the cluster is operating in active-active mode, HA does not load-balance web caching sessions.

In a cluster, only the primary unit stores the web cache database. The databases is not synchronized to the subordinate units. So, after a failover, the new primary unit must build its web cache.

Web caching and memory usage

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

When web caching is enabled you will see a reduction in available memory. The reduction increases when more web caching sessions are being processed. If you are thinking of enabling web caching 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 web caching. See get test {wad | wccpd} <test_ level> on page 1 for more information.

Changing web cache settings

In most cases, the default settings for the WAN optimization web cache are acceptable. However, you may want to change them to improve performance or optimize the cache for your configuration. To change these settings, go to WAN Opt. & Cache > Settings.

From the FortiGate CLI, you can use the config wanopt webcache command to change these WAN optimization web cache settings.

Changing web cache settings

Always revalidate

Select to always revalidate requested cached objects with content on the server before serving them to the client.

Max cache object size

Set the maximum size of objects (files) that are cached. The default size is 512000 KB and the range is 1 to 4294967 KB. This setting determines the maximum object size to store in the web cache. Objects that are larger than this size are still delivered to the client but are not stored in the FortiGate web cache.

For most web traffic the default maximum cache object size is recommended. However, since web caching can also cache larger objects such as Windows updates, Mac OS updates, iOS updates or other updates delivered using HTTP you might want to increase the object size to make sure these updates are cached. Caching these updates can save a lot of Internet bandwidth and improve performance when major updates are released by these vendors.

Negative response duration

Set how long in minutes that the FortiGate unit caches error responses from web servers. If error responses are cached, then subsequent requests to the web cache from users will receive the error responses regardless of the actual object status.

The default is 0, meaning error responses are not cached. The content server might send a client error code (4xx HTTP response) or a server error code (5xx HTTP response) as a response to some requests. If the web cache is configured to cache these negative responses, it returns that response in subsequent requests for that page or image for the specified number of minutes.

Fresh factor

Set the fresh factor as a percentage. The default is 100, and the range is 1 to 100%. For cached objects that do not have an expiry time, the web cache periodically checks the server to see if the objects have expired. The higher the Fresh Factor the less often the checks occur.

For example, if you set the Max TTL value and Default TTL to 7200 minutes (5 days) and set the Fresh Factor to 20, the web cache check the cached objects 5 times before they expire, but if you set the Fresh Factor to 100, the web cache will check once.

Max TTL

The maximum amount of time (Time to Live) an object can stay in the web cache without the cache checking to see if it has expired on the server. The default is 7200 minutes (120 hours or 5 days) and the range is 1 to 5256000 minutes (5256000 minutes in a year).

Changing web cache settings

Min TTL

The minimum amount of time an object can stay in the web cache before the web cache checks to see if it has expired on the server. The default is 5 minutes and the range is 1 to 5256000 minutes (5256000 minutes in a year).

Default TTL

The default expiry time for objects that do not have an expiry time set by the web server. The default expiry time is 1440 minutes (24 hours) and the range is 1 to 5256000 minutes (5256000 minutes in a year).

Proxy FQDN

The fully qualified domain name (FQDN) for the proxy server. This is the domain name to enter into browsers to access the proxy server. This field is for information only can be changed from the explicit web proxy configuration.

Max HTTP request length

The maximum length of an HTTP request that can be cached. Larger requests will be rejected. This field is for information only can be changed from the explicit web proxy configuration.

Max HTTP message length

The maximum length of an HTTP message that can be cached. Larger messages will be rejected. This field is for information only can be changed from the explicit web proxy configuration.

Ignore

Select the following options to ignore some web caching features.

If-modified-since

By default, if the time specified by the if-modified-since (IMS) header in the client’s conditional request is greater than the last modified time of the object in the cache, it is a strong indication that the copy in the cache is stale. If so, HTTP does a conditional GET to the Overlay Caching Scheme (OCS), based on the last modified time of the cached object. Enable ignoring if-modified-since to override this behavior.

HTTP 1.1 conditionals

HTTP 1.1 provides additional controls to the client over the behavior of caches toward stale objects. Depending on various cache-control headers, the FortiGate unit can be forced to consult the OCS before serving the object from the cache. For more information about the behavior of cache-control header values, see RFC 2616.Enable ignoring HTTP 1.1 Conditionals to override this behavior.

Changing web cache settings

Pragma-no-cache

Typically, if a client sends an HTTP GET request with a pragma no-cache (PNC) or cache-control no-cache header, a cache must consult the OCS before serving the content. This means that the FortiGate unit always re-fetches the entire object from the OCS, even if the cached copy of the object is fresh. Because of this behavior, PNC requests can degrade performance and increase server-side bandwidth utilization. However, if you enable ignoring Pragma-no-cache, then the PNC header from the client request is ignored. The FortiGate unit treats the request as if the PNC header is not present.

IE Reload

Some versions of Internet Explorer issue Accept / header instead of Pragma no-cache header when you select Refresh. When an Accept header has only the / value, the FortiGate unit treats it as a PNC header if it is a type-N object. Enable ignoring IE reload to cause the FortiGate unit to ignore the PNC interpretation of the Accept / header.

Cache expired objects

Applies only to type-1 objects. When this option is selected, expired type-1 objects are cached (if all other conditions make the object cacheable).

Revalidated pragma-no-cache

The pragma-no-cache (PNC) header in a client’s request can affect how efficiently the FortiGate unit uses bandwidth. If you do not want to completely ignore PNC in client requests (which you can do by selecting to ignore Pragma-no-cache, above), you can nonetheless lower the impact on bandwidth usage by selecting Revalidate Pragma-no-cache.

When you select Revalidate Pragma-no-cache, a client’s non-conditional PNC-GET request results in a conditional GET request sent to the OCS if the object is already in the cache. This gives the OCS a chance to return the 304 Not Modified response, which consumes less server-side bandwidth, because the OCS has not been forced to otherwise return full content.

By default, Revalidate Pragma-no-cache is disabled and is not affected by changes in the top-level profile.

Most download managers make byte-range requests with a PNC header. To serve such requests from the cache, you should also configure byte-range support when you configure the Revalidate pragma-no-cache option.

 

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

Peers and authentication groups

All communication between WAN optimization peers begins with one WAN optimization peer (or client-side FortiGate unit) sending a WAN optimization tunnel request to another peer (or server-side FortiGate unit). During this process, the WAN optimization peers identify and optionally authenticate each other.

Basic WAN optimization peer requirements

WAN optimization requires the following configuration on each peer. For information about configuring local and peer host IDs, see Basic WAN optimization peer requirements on page 319.

• The peer must have a unique host ID.
• Unless authentication groups are used, peers authenticate each other using host ID values. Do not leave the local host ID at its default value.
• The peer must know the host IDs and IP addresses of all of the other peers that it can start WAN optimization tunnels with. This does not apply if you use authentication groups that accept all peers.
• All peers must have the same local certificate installed on their FortiGate units if the units authenticate by local certificate. Similarly, if the units authenticate by pre-shared key (password), administrators must know the password. The type of authentication is selected in the authentication group. This applies only if you use authentication groups.

Accepting any peers

Strictly speaking, you do not need to add peers. Instead you can configure authentication groups that accept any peer. However, for this to work, both peers must have the same authentication group (with the same name) and both peers must have the same certificate or pre-shared key.

Accepting any peer is useful if you have many peers or if peer IP addresses change. For example, you could have FortiGate units with dynamic external IP addresses (using DHCP or PPPoE). For most other situations, this method is not recommended and is not a best practice as it is less secure than accepting defined peers or a single peer. For more information, see Basic WAN optimization peer requirements on page 319.

How FortiGate units process tunnel requests for peer authentication

When a client-side FortiGate unit attempts to start a WAN optimization tunnel with a peer server-side FortiGate unit, the tunnel request includes the following information:

• the client-side local host ID l the name of an authentication group, if included in the rule that initiates the tunnel l if an authentication group is used, the authentication method it specifies: pre-shared key or certificate l the type of tunnel (secure or not).

Configuring peers

For information about configuring the local host ID, peers and authentication groups, see How FortiGate units process tunnel requests for peer authentication on page 319 and How FortiGate units process tunnel requests for peer authentication on page 319.

The authentication group is optional unless the tunnel is a secure tunnel. For more information, see How FortiGate units process tunnel requests for peer authentication on page 319.

If the tunnel request includes an authentication group, the authentication will be based on the settings of this group as follows:

• The server-side FortiGate unit searches its own configuration for the name of the authentication group in the tunnel request. If no match is found, the authentication fails.
• If a match is found, the server-side FortiGate unit compares the authentication method in the client and server authentication groups. If the methods do not match, the authentication fails.
• If the authentication methods match, the server-side FortiGate unit tests the peer acceptance settings in its copy of the authentication group.
• If the setting is Accept Any Peer, the authentication is successful.
• If the setting is Specify Peer, the server-side FortiGate unit compares the client-side local host ID in the tunnel request with the peer name in the server-side authentication group. If the names match, authentication is successful. If a match is not found, authentication fails.
• If the setting is Accept Defined Peers, the server-side FortiGate unit compares the client-side local host ID in the tunnel request with the server-side peer list. If a match is found, authentication is successful. If a match is not found, authentication fails.

If the tunnel request does not include an authentication group, authentication will be based on the client-side local host ID in the tunnel request. The server-side FortiGate unit searches its peer list to match the client-side local host ID in the tunnel request. If a match is found, authentication is successful. If a match is not found, authentication fails.

If the server-side FortiGate unit successfully authenticates the tunnel request, the server-side FortiGate unit sends back a tunnel setup response message. This message includes the server-side local host ID and the authentication group that matches the one in the tunnel request.

The client-side FortiGate unit then performs the same authentication procedure as the server-side FortiGate unit did. If both sides succeed, tunnel setup continues.

Configuring peers

When you configure peers, you first need to add the local host ID that identifies the FortiGate unit for WAN optimization and then add the peer host ID and IP address of each FortiGate unit with which a FortiGate unit can create WAN optimization tunnels.

To configure WAN optimization peers – web-based manager:

1. Go to WAN Opt. & Cache > Peers.
2. For Local Host ID, enter the local host ID of this FortiGate unit and select Apply. If you add this FortiGate unit as a peer to another FortiGate unit, use this ID as its peer host ID.

The local or host ID can contain up to 25 characters and can include spaces.

3. Select Create New to add a new peer.

Configuring authentication groups                                                                             Peers and authentication groups

4. For Peer Host ID, enter the peer host ID of the peer FortiGate unit. This is the local host ID added to the peer FortiGate unit.
5. For IP Address, add the IP address of the peer FortiGate unit. This is the source IP address of tunnel requests sent by the peer, usually the IP address of the FortiGate interface connected to the WAN.
6. Select OK.

To configure WAN optimization peers – CLI:

In this example, the local host ID is named HQ_Peer and has an IP address of 172.20.120.100. Three peers are added, but you can add any number of peers that are on the WAN.

1. Enter the following command to set the local host ID to HQ_Peer. config wanopt settings set host-id HQ_peer

end

2. Enter the following commands to add three peers.

config wanopt peer edit Wan_opt_peer_1 set ip 172.20.120.100

next

edit Wan_opt_peer_2 set ip 172.30.120.100

next

edit Wan_opt_peer_3 set ip 172.40.120.100 end

Configuring authentication groups

You need to add authentication groups to support authentication and secure tunneling between WAN optimization peers.

To perform authentication, WAN optimization peers use a certificate or a pre-shared key added to an authentication group so they can identify each other before forming a WAN optimization tunnel. Both peers must have an authentication group with the same name and settings. You add the authentication group to a peer-topeer or active rule on the client-side FortiGate unit. When the server-side FortiGate unit receives a tunnel start request from the client-side FortiGate unit that includes an authentication group, the server-side FortiGate unit finds an authentication group in its configuration with the same name. If both authentication groups have the same certificate or pre-shared key, the peers can authenticate and set up the tunnel.

Authentication groups are also required for secure tunneling.

To add authentication groups, go to WAN Opt. & Cache > Authentication Groups.

To add an authentication group – web-based manager:

Use the following steps to add any kind of authentication group. It is assumed that if you are using a local certificate to authenticate, it is already added to the FortiGate unit

1. Go to WAN Opt. & Cache > Authentication Groups.
2. Select Create New.

Configuring authentication groups

3. Add a Name for the authentication group.

You will select this name when you add the authentication group to a WAN optimization rule.

4. Select the Authentication Method.

Select Certificate if you want to use a certificate to authenticate and encrypt WAN optimization tunnels. You must select a local certificate that has been added to this FortiGate unit. (To add a local certificate, go to System > Certificates.) Other FortiGate units that participate in WAN optimization tunnels with this FortiGate unit must have an authentication group with the same name and certificate.

Select Pre-shared key if you want to use a pre-shared key or password to authenticate and encrypt WAN optimization tunnels. You must add the Password (or pre-shared key) used by the authentication group. Other FortiGate units that participate in WAN optimization tunnels with this FortiGate unit must have an authentication group with the same name and password. The password must contain at least 6 printable characters and should be known only by network administrators. For optimum protection against currently known attacks, the key should consist of a minimum of 16 randomly chosen alphanumeric characters.

5. Configure Peer Acceptance for the authentication group.

Select Accept Any Peer if you do not know the peer host IDs or IP addresses of the peers that will use this authentication group. This setting is most often used with FortiGate units that do not have static IP addresses, for example units that use DHCP.

Select Accept Defined Peers if you want to authenticate with peers added to the peer list only.

Select Specify Peer and select one of the peers added to the peer list to authenticate with the selected peer only.

6. Select OK.
7. Add the authentication group to a WAN optimization rule to apply the authentication settings in the authentication group to the rule.

To add an authentication group that uses a certificate- CLI:

Enter the following command to add an authentication group that uses a certificate and can authenticate all peers added to the FortiGate unit configuration.

In this example, the authentication group is named auth_grp_1 and uses a certificate named Example_ Cert.

config wanopt auth-group edit auth_grp_1 set auth-method cert set cert Example_Cert set peer-accept defined

end

To add an authentication group that uses a pre-shared key – CLI:

Enter the following command to add an authentication group that uses a pre-shared key and can authenticate only the peer added to the authentication group.

Secure tunneling                                                                                                     Peers and authentication groups

In this example, the authentication group is named auth_peer, the peer that the group can authenticate is named Server_net, and the authentication group uses 123456 as the pre-shared key. In practice you should use a more secure pre-shared key.

config wanopt auth-group edit auth_peer set auth-method psk set psk 123456 set peer-accept one set peer Server_net

end

To add an authentication group that accepts WAN optimization connections from any peer – web-based manager

Add an authentication group that accepts any peer for situations where you do not have the Peer Host IDs or IP

Addresses of the peers that you want to perform WAN optimization with. This setting is most often used for WAN optimization with FortiGate units that do not have static IP addresses, for example units that use DHCP. An authentication group that accepts any peer is less secure than an authentication group that accepts defined peers or a single peer.

The example below sets the authentication method to Pre-shared key. You must add the same password to all FortiGate units using this authentication group.

1. Go to WAN Opt. & Cache > Authentication Groups.
2. Select Create New to add a new authentication group.
3. Configure the authentication group:

Name	Specify any name.
Authentication Method	Pre-shared key
Password	Enter a pre-shared key.
Peer Acceptance	Accept Any Peer

To add an authentication group that accepts WAN optimization connections from any peer – CLI:

In this example, the authentication group is named auth_grp_1. It uses a certificate named WAN_Cert and accepts any peer.

config wanopt auth-group edit auth_grp_1 set auth-method cert set cert WAN_Cert set peer-accept any

end

Secure tunneling

You can configure WAN optimization rules to use AES-128bit-CBC SSL to encrypt the traffic in the WAN optimization tunnel. WAN optimization uses FortiASIC acceleration to accelerate SSL decryption and encryption Monitoring WAN optimization peer performance

of the secure tunnel. Peer-to-peer secure tunnels use the same TCP port as non-secure peer-to-peer tunnels (TCP port 7810).

To use secure tunneling, you must select Enable Secure Tunnel in a WAN optimization rule and add an authentication group. The authentication group specifies the certificate or pre-shared key used to set up the secure tunnel. The Peer Acceptance setting of the authentication group does not affect secure tunneling.

The FortiGate units at each end of the secure tunnel must have the same authentication group with the same name and the same configuration, including the same pre-shared key or certificate. To use certificates you must install the same certificate on both FortiGate units.

For active-passive WAN optimization you can select Enable Secure Tunnel only in the active rule. In peer-topeer WAN optimization you select Enable Secure Tunnel in the WAN optimization rule on both FortiGate units. For information about active-passive and peer-to-peer WAN optimization, see Manual (peer-to-peer) and activepassive WAN optimization on page 1

For a secure tunneling configuration example, see Example: Adding secure tunneling to an active-passive WAN optimization configuration on page 1.

Monitoring WAN optimization peer performance

The WAN optimization peer monitor lists all of the WAN optimization peers that a FortiGate unit can perform WAN optimization with. These include peers manually added to the configuration as well as discovered peers.

The monitor lists each peer’s name, IP address, and peer type. The peer type indicates whether the peer was manually added or discovered. To show WAN optimization performance, for each peer the monitor lists the percent of traffic reduced by the peer in client-side WAN optimization configurations and in server-side configurations (also called gateway configurations).

To view the peer monitor, go to WAN Opt. & Cache > Peer Monitor.

 

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

WAN optimization configuration summary

This section includes a client-side and a server-side WAN Optimization configuration summary.:

Client-side configuration summary

WAN optimization profile

Enter the following command to view WAN optimization profile CLI options:

tree wanopt profile — [profile] –*name (36)

|- transparent

|- comments

|- auth-group (36)

|- <http> — status

|- secure-tunnel

|- byte-caching

|- prefer-chunking

|- tunnel-sharing |- log-traffic

|- port (1,65535)

|- ssl

|- ssl-port (1,65535)

|- unknown-http-version

+- tunnel-non-http

|- <cifs> — status

|- secure-tunnel

|- byte-caching

|- prefer-chunking

|- tunnel-sharing |- log-traffic

+- port (1,65535)

WAN optimization configuration summary

|- <mapi> — status

|- secure-tunnel

|- byte-caching

|- tunnel-sharing |- log-traffic

+- port (1,65535)

|- <ftp> — status

|- secure-tunnel

|- byte-caching

|- prefer-chunking

|- tunnel-sharing |- log-traffic

+- port (1,65535)

+- <tcp> — status

|- secure-tunnel

|- byte-caching

|- byte-caching-opt

|- tunnel-sharing

|- log-traffic

|- port

|- ssl

+- ssl-port (1,65535)

Local host ID and peer settings

config wanopt settings set host-id client

end config wanopt peer edit server set ip 10.10.2.82

end

Security policies

Two client-side WAN optimization security policy configurations are possible. One for active-passive WAN optimization and one for manual WAN optimization.

Active/passive mode on the client-side

config firewall policy edit 2 set srcintf internal set dstintf wan1 set srcaddr all set dstaddr all set action accept set schedule always set service ALL

set wanopt enable <<< enable WAN optimization set wanopt-detection active <<< set the mode to active/passive set wanopt-profile “default” <<< select the wanopt profile

next end

Manual mode on the client-side

config firewall policy edit 2 set srcintf internal set dstintf wan1 set srcaddr all set dstaddr all set action accept set schedule always set service ALL

set wanopt enable <<< enable WAN optimization set wanopt-detection off <<< sets the mode to manual set wanopt-profile “default” <<< select the wanopt profile

set wanopt-peer “server” <<< set the only peer to do wanopt

                                                                    with

(required for manual mode) next

end

server-side configuration summary

Local host ID and peer settings

config wanopt settings set host-id server

end config wanopt peer edit client set ip 10.10.2.81

end

Security policies

Two server-side WAN optimization security policy configurations are possible. One for active-passive WAN optimization and one for manual WAN optimization.

Active/passive mode on server-side

config firewall policy edit 2 <<< the passive mode policy set srcintf wan1 set dstintf internal set srcaddr all set dstaddr all set action accept set schedule always set service ALL set wanopt enable set wanopt-detection passive set wanopt-passive-opt transparent

end

config firewall proxy-policy edit 3 <<< policy that accepts wanopt tunnel connections from the      server set proxy wanopt <<< wanopt proxy type

set dstintf internal

WANopt storage

set srcaddr all set dstaddr server-subnet set action accept set schedule always set service ALL

next

end

Manual mode on server-side

config firewall proxy-policy edit 3 <<< policy that accepts wanopt tunnel connections from the client set proxy wanopt <<< wanopt proxy type

set dstintf internal set srcaddr all set dstaddr server-subnet set action accept set schedule always set service ALL

next

end

WANopt storage

The config wanopt storage option has been combined with config system storage.

Setting the disk-usage mode is no longer in config system global. It is set through config system storage.

Syntax:

config system storage edit <name-string> set status enable set media-status set order set partition set device set size set usage set wanopt-mode

Option	Description
status	Enable/disable storage
mediastatus	Enable/disable the physical status of current media
order	Set storage order

WANopt cache service

Option	Description
partition	Label of underlying partition Example: “MIXEDXXXE2946380”
device	Partition device. Example: “/dev/vdb1”
size	Partition size. Example: 8616
usage	Use hard disk for logging and WAN Optimization.
wanoptmode	WAN Optimization mode l mix – default, recommended l wanopt – recommended if only wanopt feature is enabled l webcache – recommended if only webcache feature is enabled If only one of the two features is being used, using the applicable recommended mode will give a higher cache capacity and improve performance.

WANopt cache service

The config wanopt cache-service command is used to configure cache-service clusters between multiple FortiGates. The result is that the cache-service daemons of the different FortiGates can collaborate together for serving web cache entries.

To configure the wanopt cache-service

config wanopt cache-service set prefer-scenario set collaboration set device-id set acceptable-connections config dst-peer edit <dst-peer-name> set auth-type set encode-type set priority set ip config src-peer edit <src-peer> set auth-type set encode-type set priority set ip

Video caching

Option	Description
prefer-scenario	Set the preferred cache behavior to the appropriate balance between latency and hit ratio Options: l balance – Balance between speed and cache hit ratio. l prefer-speed – Prefer response speed at the expense of increased cache bypasses. l prefer-cache – Prefer improving hit-ratio through increasing latency tolerance.
collaboration	enable/disable cache collaboration between cache-service clusters
device-id	Set identifier for this cache device
acceptable-connections	Set strategy when accepting cache collaboration connection Options: l any – The cache-service can accept any cache collaboration connection. l peers – The cache-service will only accept connections that are already in src-peers.
auth-type	Set authentication type for this peer Value is integer from 0 to 255
encode-type	Set encode type for this peer Value is integer from 0 to 255
priority	Set priority for this peer Value is integer from 0 to 255. Default = 1
ip	Set cluster IP address of this peer

Video caching

This config wanopt content-delivery-network-rule command configures web-caching including the video-cache matching rules.

To configure the wanopt content-delivery-network-rule

config wanopt content-delivery-network-rule edit <content_rule_name> set comment set status

Video caching

set host-domain-name-suffix set category set request-cache-control set response-cache-control set response-expires set text-response-vcache set updateserver config rules

edit <rule_name> set match-mode set skip-rule-mode config match-entries edit <integer> set target set pattern

config skip-entries

set target set pattern

config content id set target set start-str set start-skip set start-direction set end-str set end-skip set end-direction set range-str

Option	Description
comment	Comment about this rule
status	Enable/disable WAN optimization content delivery network rules
host-domain-namesuffix	Suffix portion of the fully qualified domain name (eg. fortinet.com in “www.fortinet.com”)
category	Content delivery network rule category
request-cachecontrol	Enable/disable HTTP request cache control
response-cachecontrol	Enable/disable HTTP response cache control
response-expires	Enable/disable HTTP response cache expires
updateserver	Enable/disable update server
match-mode	Match criteria for collecting content ID
skip-rule-mode	Skip mode when evaluating skip rules

Best practices

Option	Description
target	Option in HTTP header or URL parameter to match
pattern	Pattern string for matching target (Referrer or URL pattern, eg. “a”, “a*c”, “*a*”, “a*c*e”, and “*”)
start-str	String from which to start search
start-skip	Number of characters in URL to skip after start-str has been matched
start-direction	Search direction from start-str match
end-str	String from which to end search
end-skip	Number of characters in URL to skip after end-str has been matched
end-direction	Search direction from end-str match
range-str	Name of content ID within the start string and end string

Best practices

This is a short list of WAN optimization and explicit proxy best practices.

• WAN optimization tunnel sharing is recommended for similar types of WAN optimization traffic. However, tunnel sharing for different types of traffic is not recommended. For example, aggressive and non-aggressive protocols should not share the same tunnel. See Best practices on page 297.
• Active-passive HA is the recommended HA configuration for WAN optimization. See Best practices on page 297.
• Configure WAN optimization authentication with specific peers. Accepting any peer is not recommended as this can be less secure. See Accepting any peers on page 1.
• Set the explicit proxy Default Firewall Policy Action to Deny. This means that a security policy is required to use the explicit web proxy. See General explicit web proxy configuration steps on page 1.
• Set the explicit FTP proxy Default Firewall Policy Action to Deny. This means that a security policy is required to use the explicit FTP proxy. See General explicit FTP proxy configuration steps on page 1.
• Do not enable the explicit web or FTP proxy on an interface connected to the Internet. This is a security risk because anyone on the Internet who finds the proxy could use it to hide their source address. If you must enable the proxy on such an interface make sure authentication is required to use the proxy. See General explicit web proxy configuration steps on page 1.

Example basic manual (peer-to-peer) WAN optimization configuration

In a manual (peer to peer) configuration the WAN optimization tunnel can be set up between one client-side FortiGate unit and one server-side FortiGate unit. The peer ID of the server-side FortiGate unit is added to the client-side WAN optimization policy. When the client-side FortiGate unit initiates a tunnel with the server-side FortiGate unit, the packets that initiate the tunnel include information that allows the server-side FortiGate unit to determine that it is a manual tunnel request. The server-side FortiGate unit does not require a WAN optimization profile; you just need to add the client peer host ID and IP address to the server-side FortiGate unit peer list and from the CLI an explicit proxy policy to accept WAN optimization tunnel connections.

In a manual WAN optimization configuration, you create a manual WAN optimization security policy on the clientside FortiGate unit. To do this you must use the CLI to set wanopt-detection to off and to add the peer host ID of the server-side FortiGate unit to the WAN optimization security policy.

Network topology and assumptions

This example configuration includes a client-side FortiGate unit called Client-Fgt with a WAN IP address of 172.20.34.12. This unit is in front of a network with IP address 172.20.120.0. The server-side FortiGate unit is called Server_Fgt with a WAN IP address of 192.168.30.12. This unit is in front of a web server network with IP address 192.168.10.0.

This example customizes the default WAN optimization profile on the client-side FortiGate unit and adds it to the WAN optimization policy. You can also create a new WAN optimization profile.

Example manual (peer-to-peer) topology

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. Configure the client-side FortiGate unit:

l Add peers. l Configure the default WAN optimization profile to optimize HTTP traffic. l Add a manual WAN optimization security policy.

2. Configure the server-side FortiGate unit: l Add peers. l Add a WAN optimization tunnel policy.

Configuring basic peer-to-peer WAN optimization – web-based manager

Use the following steps to configure the example configuration from the web-based manager.

To configure the client-side FortiGate unit

1. Go to WAN Opt. & Cache > Peersand enter a Local Host ID for the client-side FortiGate unit:

Local Host ID

Client-Fgt

2. Select Apply.
3. Select Create New and add the server-side FortiGate unit Peer Host ID and IP Address for the server-side FortiGate:

Peer Host ID	Server-Fgt
IP Address	192.168.30.12

4. Select OK.
5. Go to Policy & Objects > Addresses and select Create New to add a firewall address for the client network.

Category	Address
Name	Client-Net
Type	Subnet
Subnet / IP Range	172.20.120.0/24
Interface	port1

6. Select Create New to add a firewall address for the web server network.

Category	Address
Name	Web-Server-Net
Type	Subnet
Subnet / IP Range	192.168.10.0/24
Interface	port2

7. Go to WAN Opt. & Cache > Profiles and edit the default profile.
8. Select Transparent Mode.
9. Under Protocol, select HTTP and for HTTP select Byte Caching. Leave the HTTP Port set to 80.
10. Select Apply to save your changes.
11. Go to Policy & Objects > IPv4 Policy and add a WAN optimization security policy to the client-side FortiGate unit that accepts traffic to be optimized:

Incoming Interface	port1
Source Address	all
Outgoing Interface	port2
Destination Address	all
Schedule	always
Service	ALL
Action	ACCEPT

12. Select Enable WAN Optimization and configure the following settings:

Enable WAN Optimization	active
Profile	default

13. Select OK.
14. Edit the policy from the CLI to turn off wanopt-detection, add the peer ID of the server-side FortiGate unit, and the default WAN optimization profile. The following example assumes the ID of the policy is 5:

config firewall policy edit 5 set wanopt-detection off set wanopt-peer Server-Fgt set wanopt-profile default

end

When you set the detection mode to off the policy becomes a manual mode WAN optimization policy. On the web-based manager the WAN optimization part of the policy changes to the following:

Enable WAN Optimization

Manual (Profile: default, Peer: Peer-Fgt-2)

To configure the server-side FortiGate unit

1. Go to WAN Opt. & Cache > Peersand enter a Local Host ID for the server-side FortiGate unit:

Local Host ID

Server-Fgt

2. Select Apply.
3. Select Create New and add a Peer Host ID and the IP Address for the client-side FortiGate unit:

Peer Host ID	Client-Fgt
IP Address	172.20.34.12

4. Select OK.
5. Enter the following CLI command to add an explicit proxy policy to accept WAN optimization tunnel connections. configure firewall proxy-policy edit 0 set proxy wanopt set dstintf port1 set srcaddr all set dstaddr all

set action accept set schedule always set service ALL

next

end

Configuring basic peer-to-peer WAN optimization – CLI

Use the following steps to configure the example WAN optimization configuration from the client-side and serverside FortiGate unit CLI.

To configure the client-side FortiGate unit

1. Add the Local Host ID to the client-side FortiGate configuration: config wanopt settings set host-id Client-Fgt

end

2. Add the server-side Local Host ID to the client-side peer list:

config wanopt peer edit Server-Fgt set ip 192.168.30.12

end

3. Add a firewall address for the client network. config firewall address edit Client-Net set type ipmask set subnet 172.20.120.0 255.255.255.0 set associated-interface port1

end

4. Add a firewall address for the web server network. config firewall address edit Web-Server-Net set type ipmask set subnet 192.168.10.0 255.255.255.0 set associated-interface port2

end

5. Edit the default WAN optimization profile, select transparent mode, enable HTTP WAN optimization and enable byte caching for HTTP. Leave the HTTP Port set to 80.

config wanopt profile edit default set transparent enable config http set status enable set byte-caching enable

end

end

6. Add a WAN optimization security policy to the client-side FortiGate unit to accept the traffic to be optimized: config firewall policy edit 0

set srcintf port1 set dstintf port2 set srcaddr all set dstaddr all set action accept set service ALL set schedule always set wanopt enable set wanopt-profile default set wanopt-detection off set wanopt-peer Server-Fgt

end

To configure the server-side FortiGate unit

1. Add the Local Host ID to the server-side FortiGate configuration:

config wanopt settings set host-id Server-Fgt

end

2. Add the client-side Local Host ID to the server-side peer list:

config wanopt peer edit Client-Fgt set ip 192.168.30.12

end

3. Add a WAN optimization tunnel explicit proxy policy. configure firewall proxy-policy edit 0 set proxy wanopt set dstintf port1 set srcaddr all set dstaddr all set action accept set schedule always set service ALL

next

end

Testing and troubleshooting the configuration

To test the configuration attempt to start a web browsing session between the client network and the web server network. For example, from a PC on the client network browse to the IP address of a web server on the web server network, for example http://192.168.10.100. Even though this address is not on the client network you should be able to connect to this web server over the WAN optimization tunnel.

If you can connect, check WAN optimization monitoring. If WAN optimization has been forwarding the traffic the WAN optimization monitor should show the protocol that has been optimized (in this case HTTP) and the reduction rate in WAN bandwidth usage.

If you can’t connect you can try the following to diagnose the problem:

• Review your configuration and make sure all details such as address ranges, peer names, and IP addresses are correct.
• Confirm that the security policy on the client-side FortiGate unit is accepting traffic for the 192.168.10.0 network. You can do this by checking the policy monitor (Monitor > Firewall User Monitor). Look for sessions that use the policy ID of this policy.
• Check routing on the FortiGate units and on the client and web server networks to make sure packets can be forwarded as required. The FortiGate units must be able to communicate with each other, routing on the client network must allow packets destined for the web server network to be received by the client-side FortiGate unit, and packets from the server-side FortiGate unit must be able to reach the web servers.

You can use the following get and diagnose commands to display information about how WAN optimization is operating.

Enter the following command to list all of the running WAN optimization tunnels and display information about each one. The command output for the client-side FortiGate unit shows 10 tunnels all created by peer-to-peer WAN optimization rules (auto-detect 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=192.168.30.12

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=192.168.30.12

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=192.168.30.12

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=192.168.30.12

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=192.168.30.12

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=192.168.30.12

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=192.168.30.12

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=192.168.30.12

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

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

peer name=Web-servers id=1 ip=192.168.30.12

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=192.168.30.12

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

Tunnels total=10 manual=10 auto=0

Example active-passive WAN optimization

In active-passive WAN optimization you add an active WAN optimization policy to the client-side FortiGate unit and you add a WAN optimization tunnel policy and a passive WAN optimization policy to the server-side FortiGate unit.

The active policy accepts the traffic to be optimized and sends it down the WAN optimization tunnel to the serverside FortiGate unit. The active policy can also apply security profiles and other features to traffic before it exits the client-side FortiGate unit.

A tunnel explicit proxy policy on the sever-side FortiGate unit allows the server-side FortiGate unit to form a WAN optimization tunnel with the client-side FortiGate unit. The passive WAN optimization policy is required because of the active policy on the client-side FortiGate unit. You can also use the passive policy to apply WAN optimization transparent mode and features such as security profiles, logging, traffic shaping and web caching to the traffic before it exits the server-side FortiGate unit.

Network topology and assumptions

On the client-side FortiGate unit this example configuration includes a WAN optimization profile that optimizes CIFS, HTTP, and FTP traffic and an active WAN optimization policy. The active policy also applies virus scanning to the WAN optimization traffic.

On the server-side FortiGate unit, the passive policy applies application control to the WAN optimization traffic.

In this example, WAN optimization transparent mode is selected in the WAN optimization profile and the passive WAN optimization policy accepts this transparent mode setting. This means that the optimized packets maintain their original source and destination addresses. As a result, routing on the client network must be configured to route packets for the server network to the client-side FortiGate unit. Also the routing configuration on the server network must be able to route packets for the client network to the server-side FortiGate unit.

Example active-passive WAN optimization topology

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. Configure the client-side FortiGate unit:
   • Add peers. l Add a WAN optimization profile to optimize CIFS, FTP, and HTTP traffic. l Add firewall addresses for the client and web server networks. l Add an active WAN optimization policy.
2. Configure the server-side FortiGate unit by:
   • Add peers. l Add firewall addresses for the client and web server networks. l Add a passive WAN optimization policy. l Add a WAN optimization tunnel policy.

Configuring basic active-passive WAN optimization – web-based manager

Use the following steps to configure the example WAN optimization configuration from the client-side and serverside FortiGate unit web-based manager.

To configure the client-side FortiGate unit

1. Go to WAN Opt. & Cache > Peersand enter a Local Host ID for the client-side FortiGate unit:

Local Host ID

Client-Fgt

2. Select Apply.
3. Select Create New and add a Peer Host ID and the IP Address for the server-side FortiGate unit:

Peer Host ID	Server-Fgt
IP Address	192.168.20.1

4. Select OK.
5. Go to WAN Opt. & Cache > Profilesand select Create New to add a WAN optimization profile to optimize CIFS, HTTP, and FTP traffic:

Name	Custom-wan-opt-pro
Transparent Mode	Select

6. Select the CIFS protocol, select Byte Caching and set the Port to 445.
7. Select the FTP protocol, select Byte Caching and set the Port to 21.
8. Select the HTTP protocol, select Byte Caching and set the Port to 80.
9. Select OK.
10. Go to Policy & Objects > Addresses and select Create New to add an address for the client network.

Category	Address
Address Name	Client-Net
Type	IP Range
Subnet / IP Range	172.20.120.100-172.20.120.200
Interface	port1

11. Select Create New to add an address for the web server network.

Category	Address
Address Name	Web-Server-Net
Type	Subnet
Subnet / IP Range	192.168.10.0/24
Interface	port2

12. Go to Policy & Objects > IPv4 Policy and select Create New to add an active WAN optimization security policy:

Incoming Interface	port1
Source Address	Client-Net
Outgoing Interface	port2
Destination Address	Web-Server-Net
Schedule	always
Service	HTTP FTP SMB
Action	ACCEPT

13. Turn on WAN Optimization and configure the following settings:

WAN Optimization	active
Profile	Custom-wan-opt-pro

14. Turn on Antivirus and select the default antivirus profile.
15. Select OK.

To configure the server-side FortiGate unit

1. Go to WAN Opt. & Cache > Peersand enter a Local Host ID for the server-side FortiGate unit:

Local Host ID

Server-Fgt

2. Select Apply.
3. Select Create New and add a Peer Host ID and the IP Address for the client-side FortiGate unit:

Peer Host ID	Client-Fgt
IP Address	172.30.120.1

4. Select OK.
5. Go to Policy & Objects > Addresses and select Create New to add an address for the client network.

Category	Address
Address Name	Client-Net
Type	IP Range
Subnet / IP Range	172.20.120.100-172.20.120.200
Interface	port1

6. Select Create New to add a firewall address for the web server network.

Category	Address
Address Name	Web-Server-Net
Type	Subnet
Subnet / IP Range	192.168.10.0/24
Interface	port2

7. Select OK.
8. Select Policy & Objects > IPv4 Policy and select Create New to add a passive WAN optimization policy that applies application control.

Incoming Interface	port2
Source Address	Client-Net
Outgoing Interface	port1
Destination Address	Web-Server-Net
Schedule	always
Service	ALL
Action	ACCEPT

9. Turn on WAN Optimization and configure the following settings:

WAN Optimization	passive
Passive Option	default

10. Select OK.
11. From the CLI enter the following command to add a WAN optimization tunnel explicit proxy policy. configure firewall proxy-policy edit 0 set proxy wanopt set dstintf port1 set srcaddr all set dstaddr all set action accept set schedule always set service ALL

next

end

Configuring basic active-passive WAN optimization – CLI

Use the following steps to configure the example WAN optimization configuration from the client-side and serverside FortiGate unit CLI.

To configure the client-side FortiGate unit

1. Add the Local Host ID to the client-side FortiGate configuration: config wanopt settings set host-id Client-Fgt

end

2. Add the server-side Local Host ID to the client-side peer list:

config wanopt peer edit Server-Fgt set ip 192.168.20.1 end

3. Add a WAN optimization profile to optimize CIFS, HTTP, and FTP traffic.

config wanopt profile

edit Custom-wan-opt-pro config cifs

set status enable set byte-caching enable set port 445

end config http

set status enable set byte-caching enable

set port 80 end config ftp

set status enable set byte-caching enable

set port 21 end

end

4. Add a firewall address for the client network.

config firewall address edit Client-Net

set type iprange set start-ip 172.20.120.100 set end-ip 172.20.120.200 set associated-interface port1

end

5. Add a firewall address for the web server network.

config firewall address edit Web-Server-Net

set type ipmask set subnet 192.168.10.0 255.255.255.0 set associated-interface port2

end

6. Add an active WAN optimization security policy that applies virus scanning:

config firewall policy edit 0

set srcintf port1 set dstintf port2 set srcaddr Client-net set dstaddr Web-Server-Net set action accept set service HTTP FTP SMB set schedule always set wanopt enable set wanopt-detection active set wanopt-profile Custom-wan-opt-pro

end

To configure the server-side FortiGate unit

1. Add the Local Host ID to the server-side FortiGate configuration:

config wanopt settings

set host-id Server-Fgt end

2. Add the client-side Local Host ID to the server-side peer list:

config wanopt peer edit Client-Fgt set ip 172.20.120.1

end

3. Add a firewall address for the client network.

config firewall address edit Client-Net set type iprange set start-ip 172.20.120.100 set end-ip 172.20.120.200 set associated-interface port1

end

4. Add a firewall address for the web server network.

config firewall address edit Web-Server-Net set type ipmask set subnet 192.168.10.0 255.255.255.0 set associated-interface port2

end

5. Add a passive WAN optimization policy.

config firewall policy edit 0 set srcintf port1 set dstintf port2 set srcaddr Client-Net set dstaddr Web-Server-Net set action accept set service ALL set schedule always set wanopt enable set wanopt-detection passive set wanopt-passive-opt default

end

6. Add a WAN optimization tunnel explicit proxy policy. configure firewall proxy-policy edit 0 set proxy wanopt set dstintf port1 set srcaddr all set dstaddr all set action accept set schedule always set service ALL

next

end

Testing and troubleshooting the configuration

To test the configuration attempt to start a web browsing session between the client network and the web server network. For example, from a PC on the client network browse to the IP address of a web server on the web server network, for example http://192.168.10.100. Even though this address is not on the client network you should be able to connect to this web server over the WAN optimization tunnel.

If you can connect, check WAN optimization monitoring. If WAN optimization has been forwarding the traffic the WAN optimization monitor should show the protocol that has been optimized (in this case HTTP) and the reduction rate in WAN bandwidth usage.

If you can’t connect you can try the following to diagnose the problem:

• Review your configuration and make sure all details such as address ranges, peer names, and IP addresses are correct.
• Confirm that the security policy on the Client-Side FortiGate unit is accepting traffic for the 192.168.10.0 network and that this security policy does not include security profiles. You can do this by checking the FortiGate session table from the dashboard. Look for sessions that use the policy ID of this policy.
• Check routing on the FortiGate units and on the client and web server networks to make sure packets can be forwarded as required. The FortiGate units must be able to communicate with each other, routing on the client network must allow packets destined for the web server network to be received by the client-side FortiGate unit, and packets from the server-side FortiGate unit must be able to reach the web servers etc.

You can use the following get and diagnose commands to display information about how WAN optimization is operating

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

diagnose wad tunnel list

Tunnel: id=139 type=auto vd=0 shared=no uses=0 state=1 peer name= id=0 ip=unknown SSL-secured-tunnel=no auth-grp=test bytes_in=744 bytes_out=76

Tunnel: id=141 type=auto vd=0 shared=no uses=0 state=1 peer name= id=0 ip=unknown SSL-secured-tunnel=no auth-grp=test bytes_in=727 bytes_out=76

Tunnel: id=142 type=auto vd=0 shared=no uses=0 state=1 peer name= id=0 ip=unknown SSL-secured-tunnel=no auth-grp=test bytes_in=727 bytes_out=76

Tunnels total=3 manual=0 auto=3

Example adding secure tunneling to an active-passive WAN optimization configuration

This example shows how to configure two FortiGate units for active-passive WAN optimization with secure tunneling. The same authentication group is added to both FortiGate units. The authentication group includes a password (or pre-shared key) and has Peer Acceptance set to Accept any Peer. An active policy is added to the client-side FortiGate unit and a passive policy to the server-side FortiGate unit. The active policy includes a profile that performs secure tunneling, optimizes HTTP traffic, and uses transparent mode and byte caching.

The authentication group is named Auth-Secure-Tunnel and the password for the pre-shared key is 2345678. The topology for this example is shown below. This example includes web-based manager configuration steps followed by equivalent CLI configuration steps. For information about secure tunneling, see Secure tunneling on page 1.

Network topology and assumptions

This example configuration includes a client-side FortiGate unit called Client-net with a WAN IP address of 172.30.120.1.This unit is in front of a network with IP address 172.20.120.0. The server-side FortiGate unit is called Web-servers and has a WAN IP address of 192.168.20.1. This unit is in front of a web server network with IP address 192.168.10.0.

Example active-passive WAN optimization and secure tunneling topology

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. Configure the client-side FortiGate unit:
   • Add peers. l Add an authentication group. l Add an active WAN optimization policy.
2. Configure the server-side FortiGate unit. l Add peers.
   • Add the same authentication group l Add a passive WAN optimization policy that applies application control. l Add a WAN optimization tunnel policy.

Also note that if you perform any additional actions between procedures, your configuration may have different results.

Configuring WAN optimization with secure tunneling – web-based manager

Use the following steps to configure the example WAN optimization configuration from the client-side and serverside FortiGate unit web-based manager. (CLI steps follow.)

To configure the client-side FortiGate unit

1. Go to WAN Opt. & Cache > Peersand enter a Local Host ID for the client-side FortiGate unit:

Local Host ID

Client-Fgt

2. Select Apply to save your setting.
3. Select Create New and add a Peer Host ID and the IP Address for the server-side FortiGate unit:

Peer Host ID	Server-Fgt
IP Address	192.168.20.1

4. Select OK.
5. Go to WAN Opt. & Cache > Authentication Groups and select Create New to add the authentication group to be used for secure tunneling:

Name	Auth-Secure-Tunnel
Authentication Method	Pre-shared key
Password	2345678
Peer Acceptance	Accept Any Peer

6. Select OK.
7. Go to WAN Opt. & Cache > Profiles and select Create New to add a WAN optimization profile that enables secure tunneling and includes the authentication group:

Name	Secure-wan-op-pro
Transparent Mode	Select
Authentication Group	Auth-Secure-tunnel

8. Select the HTTP protocol, select Secure Tunneling and Byte Caching and set the Port to 80.
9. Select OK.
10. Go to Policy & Objects > Addresses and select Create New to add a firewall address for the client network.

	Category		Address
	Name		Client-Net
Type		Subnet
Subnet / IP Range		172.20.120.0/24
Interface		port1

11. Select Create New to add a firewall address for the web server network.

Category	Address
Address Name	Web-Server-Net
Type	Subnet
Subnet / IP Range	192.168.10.0/24
Interface	port2

12. Go to Policy & Objects > IPv4 Policy and select Create New to add an active WAN optimization security policy:

Incoming Interface	port1
Source Address	Client-Net
Outgoing Interface	port2
Destination Address	Web-Server-Net
Schedule	always
Service	HTTP
Action	ACCEPT

13. Turn on WAN Optimization and configure the following settings:

WAN Optimization	active
Profile	Secure-wan-opt-pro

14. Select OK.

To configure the server-side FortiGate unit

1. Go to WAN Opt. & Cache > Peersand enter a Local Host ID for the server-side FortiGate unit:

Local Host ID

Server-Fgt

2. Select Apply to save your setting.
3. Select Create New and add a Peer Host ID and the IP Address for the client-side FortiGate unit:

Peer Host ID	Client-Fgt
IP Address	172.30.120.1

4. Select OK.
5. Go to WAN Opt. & Cache > Authentication Groups and select Create New and add an authentication group to be used for secure tunneling:

Name	Auth-Secure-Tunnel
Authentication Method	Pre-shared key
Password	2345678
Peer Acceptance	Accept Any Peer

6. Select OK.
7. Go to Policy & Objects > Addresses and select Create New to add a firewall address for the client network.

Category	Address
Name	Client-Net
Type	Subnet
Subnet / IP Range	172.20.120.0/24
Interface	port1

8. Select Create New to add a firewall address for the web server network.

Category	Address
Address Name	Web-Server-Net
Type	Subnet
Subnet / IP Range	192.168.10.0/24
Interface	port2

9. Select OK.
10. Select Create New to add a passive WAN optimization policy that applies application control.

Incoming Interface		port2
Source Address		Client-Net
Outgoing Interface		port1
Destination Address		Web-Server-Net
	Schedule		always
	Service		ALL
	Action		ACCEPT

11. Turn on WAN Optimization and configure the following settings:

WAN Optimization	passive
Passive Option	default

12. Select OK.
13. From the CLI enter the following command to add a WAN optimization tunnel explicit proxy policy. configure firewall proxy-policy edit 0 set proxy wanopt set dstintf port1 set srcaddr all set dstaddr all set action accept set schedule always set service ALL

next

end

Configuring WAN optimization with secure tunneling – CLI

Use the following steps to configure the example WAN optimization configuration from the client-side and serverside FortiGate unit CLI.

To the client-side FortiGate unit

1. Add the Local Host ID to the client-side FortiGate configuration:

config wanopt settings set host-id Client-Fgt

end

2. Add the server-side Local Host ID to the client-side peer list:

config wanopt peer edit Server-Fgt set ip 192.168.20.1

end

3. Add a new authentication group to be used for secure tunneling:

config wanopt auth-group edit Auth-Secure-Tunnel set auth-method psk set psk 2345678

end

Leave peer-accept at its default value.

4. Add a WAN optimization profile that enables secure tunneling and includes the authentication group, enables HTTP protocol optimization, and enables secure tunneling and byte caching for HTTP traffic:

config wanopt profile edit Secure-wan-op-pro set auth-group Auth-Secure-Tunnel config http set status enable set secure-tunnel enable set byte-caching enable set port 80 end

end

5. Add a firewall address for the client network.

config firewall address edit Client-Net set type ipmask set subnet 172.20.120.0 255.255.255.0 set associated-interface port1

end

6. Add a firewall address for the web server network.

config firewall address edit Web-Server-Net set type ipmask set subnet 192.168.10.0 255.255.255.0 set associated-interface port2

end

7. Add an active WAN optimization security policy that includes the WAN optimization profile that enables secure tunneling and that applies virus scanning:

config firewall policy edit 0 set srcintf port1 set dstintf port2 set srcaddr Client-Net set dstaddr Web-Server-Net set action accept set service HTTP set schedule always set wanopt enable set wanopt-detection active set wanopt-profile Secure-wan-opt-pro

end

To configure the server-side FortiGate unit

1. Add the Local Host ID to the server-side FortiGate configuration:

config wanopt settings set host-id Server-Fgt

end

2. Add the client-side Local Host ID to the server-side peer list:

config wanopt peer edit Client-Fgt set ip 172.20.120.1 end

3. Add an authentication group to be used for secure tunneling:

config wanopt auth-group edit Auth-Secure-Tunnel

set auth-method psk set psk 2345678

end

Leave peer-accept at its default value.

4. Add a firewall address for the client network. config firewall address edit Client-Net

set type ipmask set subnet 172.20.120.0 255.255.255.0 set associated-interface port1

end

5. Add a firewall address for the web server network. config firewall address edit Web-Server-Net

set type ipmask set subnet 192.168.10.0 255.255.255.0 set associated-interface port2

end

6. Add a passive WAN optimization policy.

config firewall policy edit 0

set srcintf port1 set dstintf port2 set srcaddr Client-Net set dstaddr Web-Server-Net set action accept set service ALL set schedule always set wanopt enable set wanopt-detection passive set wanopt-passive-opt default

end

7. Add a WAN optimization tunnel explicit proxy policy.

configure firewall proxy-policy

edit 0

set proxy wanopt set dstintf port1 set srcaddr all set dstaddr all set action accept set schedule always set service ALL

next end

 

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

Monitoring WAN optimization performance

Using WAN optimization monitoring, you can confirm that a FortiGate unit is optimizing traffic and view estimates of the amount of bandwidth saved. The WAN optimization monitor presents collected log information in a graphical format to show network traffic summary and bandwidth optimization information.

To view the WAN optimization monitor, go to Monitor > WAN Opt. Monitor.

WAN optimization monitor

Traffic summary

The traffic summary shows how WAN optimization is reducing the amount of traffic on the WAN for each WAN optimization protocol by showing the traffic reduction rate as a percentage of the total traffic. The traffic summary also shows the amount of WAN and LAN traffic. If WAN optimization is being effective the amount of WAN traffic should be lower than the amount of LAN traffic.

You can use the refresh icon to update the traffic summary display at any time. You can also set the amount of time for which the traffic summary shows data. The time period can vary from the last 10 minutes to the last month.

Bandwidth optimization

This section shows network bandwidth optimization per time period. A line or column chart compares an application’s pre-optimized size (LAN data) with its optimized size (WAN data). You can select the chart type, the monitoring time period, and the protocol for which to display data. If WAN optimization is being effective the WAN bandwidth should be lower than the LAN bandwidth.

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

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.

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

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.

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

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.

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