WAN optimization transparent mode

Leave a reply

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 trans- parent mode and make sure the server network can route traffic as described to sup- port 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 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 Optmization 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

Byte caching

Leave a reply

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, labelling 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.

Protocol optimization and MAPI

Leave a reply

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.

Protocol optimization

Leave a reply

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 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 protocol- specific 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.

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

Leave a reply

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

 

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

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

WAN optimization profiles

Leave a reply

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

end

set status enable

 

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 transparent mode on page 2850.

 

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 start- ing 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 2862.

 

Protocol

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

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 pro- tocol.

 

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 con- figure the security policy to accept SSL-encrypted traffic.

If you enable SSL offloading, you must also use the CLI command con- fig wanopt ssl-server to add an SSL server for each HTTP server that you want to offload SSL encryption/decryption for. For more inform- ation, see Turning on web caching for HTTPS traffic on page 2888.

 

Secure

Tunnelling

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

 

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 des- tination port number matches this port number or port number range will be optimized.

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

Leave a reply

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

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

 

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 explicit-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. SeeWAN optimization transparent mode on page 2850. 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 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 explicit-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 peers

Leave a reply

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.