Fortigate Wanopt Cache Proxy 40 Mr3

WAN Optimization, Web Cache, Explicit Proxy, and WCCP
FortiOS Handbook v3 for FortiOS 4.0 MR3
FortiOS Handbook WAN Optimization, Web Cache, Explicit Proxy, and WCCP v3 13 January 2012 01-433-96996-20120113 Copyright 2012 Fortinet, Inc. All rights reserved. Fortinet, FortiGate, and FortGuard, are registered trademarks of Fortinet, Inc., and other Fortinet names herein may also be trademarks of Fortinet. All other product or company names may be trademarks of their respective owners. Performance metrics contained herein were attained in internal lab tests under ideal conditions, and performance may vary. Network variables, different network environments and other conditions may affect performance results. Nothing herein represents any binding commitment by Fortinet, and Fortinet disclaims all warranties, whether express or implied, except to the extent Fortinet enters a binding written contract, signed by Fortinets General Counsel, with a purchaser that expressly warrants that the identified product will perform according to the performance metrics herein. For absolute clarity, any such warranty will be limited to performance in the same ideal conditions as in Fortinets internal lab tests. Fortinet disclaims in full any guarantees. Fortinet reserves the right to change, modify, transfer, or otherwise revise this publication without notice, and the most current version of the publication shall be applicable.
Visit these links for more information and documentation for your Fortinet products: Fortinet Knowledge Base - http://kb.fortinet.com Technical Documentation - http://docs.fortinet.com Training Services - http://campus.training.fortinet.com Technical Support - http://support.fortinet.com You can report errors or omissions in this or any Fortinet technical document to techdoc@fortinet.com.
FortiOS Handbook
Contents
WAN optimization, web cache, explicit proxy, and WCCP concepts
WAN optimization topologies . . . . . . . . . . . . . . . . . Basic WAN optimization topologies . . . . . . . . . . . . Out-of-path topology. . . . . . . . . . . . . . . . . . . . Topology for multiple networks . . . . . . . . . . . . . . WAN optimization with web caching. . . . . . . . . . . . WAN optimization and web caching with FortiClient peers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
11
12 12 13 15 16 17 18 19 20 22 23 24 24 25 25 25 26 27 27 28 28 28 29 29 29 30
Explicit Web proxy topologies . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Explicit FTP proxy topologies . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Web caching topologies . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . WCCP topologies. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . WAN optimization client/server architecture . . . . . . . WAN optimization peers . . . . . . . . . . . . . . . Peer-to-peer and active-passive WAN optimization . WAN optimization and the FortiClient application . . Operating modes and VDOMs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
WAN optimization tunnels . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Tunnel sharing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Protocol optimization . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Byte caching . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . WAN optimization and HA . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . WAN optimization, web caching and memory usage . . . . . . . . . . . . . . . . . Monitoring WAN optimization performance . . . . . . . . . . . . . . . . . . . . . . Traffic Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Bandwidth Optimization . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Configuring WAN optimization traffic usage logs . . . . . . . . . . . . . . . . . . . Best practices . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
WAN optimization and Web cache storage

Formatting the hard disk . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Configuring WAN optimization and Web cache storage . . . . . . . . . . . . . . . . Changing the amount of space allocated for WAN optimization and Web cache storage . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Adjusting the relative amount of disk space available for byte caching and web caching . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
31
31 32 32 32
FortiOS Handbook v3: WAN Optimization, Web Cache, Explicit Proxy, and WCCP 01-433-96996-20120113 http://docs.fortinet.com/
Contents
WAN optimization peers and authentication groups

Basic WAN optimization peer requirements . . . . . . . . . . . . . . . . . . . . . . Accepting any peers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . How FortiGate units process tunnel requests for peer authentication . . . . . . . . . Configuring peers. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Configuring authentication groups . . . . . . . . . . . . . . . . . . . . . . . . . . . Secure tunneling . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Monitoring WAN optimization peer performance . . . . . . . . . . . . . . . . . . .
35
35 35 36 37 38 40 41
Configuring WAN optimization rules

WAN optimization rules, security policies, and UTM protection . . . . . . . . . . . . WAN optimization transparent mode. . . . . . . . . . . . . . . . . . . . . . . . . . WAN optimization rule list . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . How list order affects rule matching . . . . . . . . . . . . . . . . . . . . . . . . Moving a rule to a different position in the rule list. . . . . . . . . . . . . . . . . WAN optimization address formats . . . . . . . . . . . . . . . . . . . . . . . . . . Configuring WAN optimization rules . . . . . . . . . . . . . . . . . . . . . . . . . . Processing non-HTTP sessions accepted by an HTTP rule . . . . . . . . . . . . Processing unknown HTTP sessions . . . . . . . . . . . . . . . . . . . . . . .
43
43 44 45 46 47 47 48 52 52
WAN optimization configuration examples

Example: Basic peer-to-peer WAN optimization configuration . . . . . . . . Network topology and assumptions . . . . . . . . . . . . . . . . . . . . General configuration steps . . . . . . . . . . . . . . . . . . . . . . . . Configuring basic peer-to-peer WAN optimization - web-based manager Configuring basic peer-to-peer WAN optimization - CLI . . . . . . . . . Testing and troubleshooting the configuration. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
53
53 53 54 54 56 57 59 59 60 60 63 65 66 67 67 67 70
Example: Active-passive WAN optimization . . . . . . . . . . . . . . . . . . . Network topology and assumptions . . . . . . . . . . . . . . . . . . . . . General configuration steps . . . . . . . . . . . . . . . . . . . . . . . . . Configuring basic active-passive WAN optimization - web-based manager Configuring basic active-passive WAN optimization - CLI. . . . . . . . . . Testing and troubleshooting the configuration. . . . . . . . . . . . . . . .
. . . . . . . . . . . .
Example: Adding secure tunneling to an active-passive WAN optimization configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Network topology and assumptions . . . . . . . . . . . . . . . . . . . . . . General configuration steps . . . . . . . . . . . . . . . . . . . . . . . . . . Configuring WAN optimization with secure tunneling - web-based manager . Configuring WAN optimization with secure tunneling - CLI . . . . . . . . . .
WAN Optimization, Web Cache, Explicit Proxy, and WCCP for FortiOS 4.0 MR3 01-433-96996-20120113 http://docs.fortinet.com/
Contents
Web caching
Web caching in security policies . . . . . . . . . . . . . . . . . . . . . . . . . . . . Example: Web caching of Internet content for users on an internal network . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Web Caching only WAN optimization . . . . . . . . . . . . . . . . . . . . . . . . . Example: Web Cache Only WAN optimization. . . . . . . . . . . . . . . . . . . Web caching for active-passive WAN optimization . . . . . . . . . . . . . . . . . . Example: Active-passive Web Caching . . . . . . . . . . . . . . . . . . . . . . Web caching for peer-to-peer WAN optimization . . . . . . . . . . . . . . . . . . . Example: Peer-to-peer web caching. . . . . . . . . . . . . . . . . . . . . . . . Exempting web sites from web caching . . . . . . . . . . . . . . . . . . . . . . . . Changing web cache settings . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Monitoring Web caching performance . . . . . . . . . . . . . . . . . . . . . . . . .
73
74 74 77 77 82 82 86 87 90 91 93
Advanced configuration example

Out-of-path WAN optimization with inter-VDOM routing . Network topology and assumptions . . . . . . . . . . Configuration steps . . . . . . . . . . . . . . . . . . Client-side configuration steps - web-based manager Server-side configuration steps - web-based manager Client-side configuration steps - CLI. . . . . . . . . . Server-side configuration steps - CLI . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
95
. 95 . 95 . 96 . 97 . 104 . 107 . 114
SSL offloading for WAN optimization and web caching

About SSL server full and half mode . . . . . . . . . . . . . . . . . WAN optimization full mode SSL server configuration . . . . . WAN optimization half mode SSL server configuration . . . . . Reverse proxy web cache full mode SSL server configuration . Reverse proxy web cache half mode SSL server configuration . Example: SSL offloading for a WAN optimization tunnel. Network topology and assumptions . . . . . . . . . General configuration steps . . . . . . . . . . . . . Client-side configuration steps. . . . . . . . . . . . Server-side configuration steps . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
119
120 120 121 122 123 124 124 125 125 126 127 127 129 129 132
Example: SSL offloading and reverse proxy web caching for an Internet web server using static one-to-one virtual IPs . . . . . . . . . . . . . . Network topology and assumptions . . . . . . . . . . . . . . . . . General configuration steps . . . . . . . . . . . . . . . . . . . . . Configuration steps - web-based manager . . . . . . . . . . . . . Configuration steps - CLI . . . . . . . . . . . . . . . . . . . . . .
Contents
Example: SSL offloading and reverse proxy web caching for an Internet web server using a port forwarding virtual IP for HTTPS traffic . . . . . Network topology and assumptions . . . . . . . . . . . . . . . . . General configuration steps . . . . . . . . . . . . . . . . . . . . . Configuration steps - web-based manager . . . . . . . . . . . . . Configuration steps - CLI . . . . . . . . . . . . . . . . . . . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
133 134 135 136 139
FortiClient WAN optimization
143
Configuring FortiClient WAN optimization . . . . . . . . . . . . . . . . . . . . . . . 143 FortiClient configuration steps . . . . . . . . . . . . . . . . . . . . . . . . . . . 144 FortiGate unit configuration steps . . . . . . . . . . . . . . . . . . . . . . . . . 144
The FortiGate explicit web proxy

Explicit web proxy configuration overview . Proxy auto-config (PAC) configuration . Unknown HTTP version . . . . . . . . Authentication realm . . . . . . . . . . Other explicit web proxy options. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
145
147 150 150 150 151 151 152 152 152
Proxy chaining . . . . . . . . . . . . . . . . . . . . . . . . . . . . Adding a web proxy forwarding server . . . . . . . . . . . . . Web proxy forwarding server monitoring and health checking . Adding proxy chaining to an explicit web proxy security policy .
Explicit web proxy authentication . . . . . . . . . . . . . . . . . . . . . . . . . . . 153 IP-Based authentication . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 154 Per session authentication . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 154 UTM features and the explicit web proxy . . . . . . . . . . . . . . . . . Explicit web proxy sessions and flow-based scanning . . . . . . . . Explicit web proxy sessions and protocol options. . . . . . . . . . . Explicit web proxy sessions web filtering and FortiGuard web filtering Explicit web proxy sessions and HTTPS deep scanning . . . . . . . Explicit web proxy sessions and antivirus . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 155 156 156 156 156 157
Web Proxy Services . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 157 Web Proxy Service Groups . . . . . . . . . . . . . . . . . . . . . . . . . . . . 158 Example: users on an internal network browsing the Internet through the explicit web proxy with web caching, RADIUS authentication, web filtering and virus scanning . . . . . . . . . . . . . . . . . . . . General configuration steps . . . . . . . . . . . . . . . . . . . . Configuring the explicit web proxy - web-based manager . . . . Configuring the explicit web proxy - CLI . . . . . . . . . . . . . . Testing and troubleshooting the configuration. . . . . . . . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
158 159 159 161 162
Explicit proxy sessions and user limits . . . . . . . . . . . . . . . . . . . . . . . . . 163
Contents
Explicit web proxy configuration options. . . Explicit Web Proxy Options . . . . . . . Web Proxy Forwarding Servers Options . Adding Web Proxy Forwarding Servers .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
165 165 167 167
The FortiGate explicit FTP proxy
169
How to use the explicit FTP proxy to connect to an FTP server . . . . . . . . . . . . 170 Explicit FTP proxy configuration overview . . . . . . . . . . . . . . . . . . . . . . . 172 Restricting the IP address of the explicit FTP proxy . . . . . . . . . . . . . . . . 175 Restricting the outgoing source IP address of the explicit FTP proxy . . . . . . . 175 UTM features and the explicit FTP proxy . . . . . . . . . . . . . . . . . . . . . . . 175 Explicit FTP proxy sessions and protocol options . . . . . . . . . . . . . . . . . 175 Explicit FTP proxy sessions and antivirus . . . . . . . . . . . . . . . . . . . . . 176 Example: users on an internal network connecting to FTP servers on the Internet through the explicit FTP with RADIUS authentication and virus scanning . . . . . . . . . . . . . . . . . . . . . . . . . . General configuration steps . . . . . . . . . . . . . . . . . . . Configuring the explicit FTP proxy - web-based manager . . . Configuring the explicit FTP proxy - CLI . . . . . . . . . . . . . Testing and troubleshooting the configuration. . . . . . . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
176 177 177 178 180
Explicit FTP proxy sessions and user limits . . . . . . . . . . . . . . . . . . . . . . 182 Explicit FTP proxy options . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 182
FortiGate WCCP
WCCP service groups, service numbers, service IDs and well known services . Example WCCP server and client configuration for caching HTTP sessions (service ID = 0) . . . . . . . . . . . . . . . . . . . . . . . . . . . Example WCCP server and client configuration for caching HTTPS sessions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Example WCCP server and client configuration for caching HTTP and HTTPS sessions . . . . . . . . . . . . . . . . . . . . . . . . . Other WCCP service group options . . . . . . . . . . . . . . . . . . . . .
183
. . . 184 . . . 184 . . . 185 . . . 186 . . . 186
WCCP configuration overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 187 Example: caching HTTP sessions on port 80 using WCCP . . . . . . . . . . . . . . 188 Configuring the WCCP server (WCCP_srv) . . . . . . . . . . . . . . . . . . . . 189 Configuring the WCCP client (WCCP_client) . . . . . . . . . . . . . . . . . . . 190 Example: caching HTTP sessions on port 80 and HTTPS sessions on port 443 using WCCP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 190 Configuring the WCCP server (WCCP_srv) . . . . . . . . . . . . . . . . . . . . 191 Configuring the WCCP client (WCCP_client) . . . . . . . . . . . . . . . . . . . 192 WCCP packet flow . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 192 Configuring the forward and return methods and adding authentication . . . . . . . 193 WCCP Messages . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 194
Contents
Troubleshooting WCCP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 194 Real time debugging . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 194 Application debugging . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 194
WAN optimization, web cache, explicit proxy and WCCP get and diagnose commands 197
get test {wa_cs | wa_dbd | wad | wad_diskd | wccpd} <test_level> . . . . . . . . . . 197 Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 197 diagnose wad. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 200 Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 200 diagnose wacs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 202 diagnose wadbd . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 202 diagnose debug application {wa_cs | wa_dbd | wad | wad_diskd | wccpd} [<debug_level>] . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 202
Appendix
Document conventions . . . . . . . . . . . IPv4 IP addresses . . . . . . . . . . . Example Network . . . . . . . . . . . Tips, must reads, and troubleshooting. Typographical conventions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
205
205 205 206 207 207
Registering your Fortinet product . . . . . . . . . . . . . . . . . . . . . . . . . . . 208 Training Services . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 208 Technical Documentation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 208 Comments on Fortinet technical documentation . . . . . . . . . . . . . . . . . 208 Customer service and support . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 208 Fortinet products End User License Agreement . . . . . . . . . . . . . . . . . . . . 208
Index
209
FortiOS Handbook
The FortiOS Handbook chapter contains the following sections: WAN optimization, web cache, explicit proxy, and WCCP concepts: Provides an overview of FortiGate WAN optimization best practices and technologies and some of the concepts and rules for using them. We recommend that you begin with this chapter before attempting to configure your FortiGate unit to use WAN optimization. WAN optimization and Web cache storage: Describes how to configure WAN optimization storage settings to control how data is stored for web caching and byte caching. WAN optimization peers and authentication groups: Describes how to use WAN optimization peers and authentication groups to control access to WAN optimization tunnels. Configuring WAN optimization rules: Provides basic configuration for WAN optimization rules, including adding rules, organizing rules in the rule list and using WAN optimization addresses. This chapter also explains how WAN optimization accepts sessions, as well as how and when you can apply UTM features to WAN optimization traffic. WAN optimization configuration examples: Describes basic active-passive and peer-topeer WAN optimization configuration examples. This chapter is a good place to start learning how to put an actual WAN optimization network together. Web caching: Describes how WAN optimization web caching works to cache different session types, including HTTPS, and includes web caching configuration examples. Advanced configuration example: Provides a configuration example that combines WAN optimization, web caching, out-of-path WAN optimization, and the use of multiple VDOMs to apply UTM features to sessions being optimized. SSL offloading for WAN optimization and web caching: Describes how to offload SSL processing from web sites to FortiGate units to improve WAN performance for SSL-protected web sites on a WAN. FortiClient WAN optimization: Describes how FortiGate and FortiClient WAN optimization work together and includes an example configuration. The FortiGate explicit web proxy: Describes how to configure the FortiGate explicit web proxy, how users connect to the explicit web proxy, and how to add web caching to the explicit web proxy. The FortiGate explicit FTP proxy: Describes how to configure the FortiGate explicit FTP proxy and how users connect to the explicit FTP proxy. FortiGate WCCP: Describes FortiGate WCCP and how to configure WCCP and the WCCP client. WAN optimization, web cache, explicit proxy and WCCP get and diagnose commands: describes get and diagnose commands available for troubleshooting WAN optimization, web cache, and WCCP.
10
FortiOS Handbook

FortiGate WAN optimization consists of a number of techniques that you can apply to improve the efficiency of communication across your WAN. These techniques include protocol optimization, byte caching, web caching, SSL offloading, and secure tunnelling. Protocol optimization can improve the efficiency of traffic that uses the CIFS, FTP, HTTP, or MAPI protocol, as well as general TCP traffic. Byte caching caches files and other data on FortiGate units to reduce the amount of data transmitted across the WAN. Web caching stores web pages on FortiGate units to reduce latency and delays between the WAN and web servers. SSL offloading offloads SSL decryption and encryption from web servers onto FortiGate SSL acceleration hardware. Secure tunnelling secures traffic as it crosses the WAN. You can apply different combinations of these WAN optimization techniques to a single traffic stream depending on the traffic type. For example, you can apply byte caching and secure tunneling to any TCP traffic. For HTTP and HTTPS traffic, you can also apply protocol optimization and web caching. You can configure a FortiGate unit to be an explicit web proxy server and an explicit FTP proxy server. Users on your internal network can browse the Internet through the explicit web proxy server or connect to FTP servers through the explicit FTP proxy server. You can also configure these proxies to protect access to web or FTP servers behind the FortiGate unit using a reverse proxy configuration. FortiGate units that support WAN optimization can also be configured to support web caching. Both WAN optimization and web caching require that the FortiGate unit include a hard disk. Either an internal hard disk or AMC or other hard disk module. Web caching can be applied to any HTTP, this includes HTTP traffic accepted by a security policy, explicit web proxy traffic, and HTTP and HTTPS WAN optimization traffic. You can also configure a FortiGate unit to operate as a Web Cache Communication Protocol (WCCP) client or server. WCCP provides the ability to offload web caching to one or more redundant web caching servers. This chapter describes: WAN optimization topologies Explicit Web proxy topologies Explicit FTP proxy topologies Web caching topologies WCCP topologies WAN optimization client/server architecture WAN optimization tunnels Protocol optimization Byte caching WAN optimization and HA
11
WAN optimization topologies
WAN optimization, web caching and memory usage Monitoring WAN optimization performance Configuring WAN optimization traffic usage logs Best practices

This section describes some common WAN optimization topologies: Basic WAN optimization topologies on page 12 Out-of-path topology on page 13 Topology for multiple networks on page 15 WAN optimization with web caching on page 16 WAN optimization and web caching with FortiClient peers on page 17
Basic WAN optimization topologies

The basic FortiGate WAN optimization topology consists of two FortiGate units operating as WAN optimization peers intercepting and optimizing traffic crossing the WAN between the private networks. Figure 1: Security device and WAN optimization topology
e eN two rk
Pri
va
As shown in Figure 1, the FortiGate units can be deployed as security devices that protect private networks connected to the WAN and also perform WAN optimization. In this configuration, the FortiGate units are configured as typical security devices for the private networks and are also configured for WAN optimization. The WAN optimization configuration intercepts traffic to be optimized as it passes through the FortiGate unit and uses a WAN optimization tunnel with another FortiGate unit to optimize the traffic that crosses the WAN.
d n an atio ity iz ur tim ec p S o N A W A W io at iz tim el op nn N tu n
WAN
d n an atio ity iz ur tim ec p S o N A W
Pri
va
e eN
two
rk
12
As shown in Figure 2, you can also deploy WAN optimization on single-purpose FortiGate units that only perform WAN optimization. In Figure 2, the WAN optimization FortiGate units are located on the WAN outside of the private networks. You can also install the WAN optimization FortiGate units behind the security devices on the private networks. The WAN optimization configuration is the same for FortiGate units deployed as security devices and for single-purpose WAN optimization FortiGate units. The only differences would result from the different network topologies.
Out-of-path topology
In an out-of-path topology, one or both of the FortiGate units configured for WAN optimization are not directly in the main data path. Instead, the out-of-path FortiGate unit is connected to a device on the data path, and the device is configured to redirect sessions to be optimized to the out-of-path FortiGate unit. Figure 2: Single-purpose WAN optimization topology
t e eN two rk
Pri
va
Figure 3 shows out-of-path FortiGate units configured for WAN optimization and connected directly to FortiGate units in the data path. The FortiGate units in the data path use a method such as policy routing to redirect traffic to be optimized to the out-of-path FortiGate units. The out-of-path FortiGate units establish a WAN optimization tunnel between each other and optimize the redirected traffic.
S ec ur ity op A W at iz tim el op nn N tu io n N on A ti W iza tim
WAN
op
N on A ti W iza tim S ec ur ity

Pri v N ate etw ork
13
Figure 3: Out-of-path WAN optimization

t e eN two rk
Pri
va
ur ec S ity
th pa on of- ati ut- timiz O p o AN W
WAN
ur ec S ity
One of the benefits of out-of-path WAN optimization is that out-of-path FortiGate units only perform WAN optimization and do not have to process other traffic. An in-path FortiGate unit configured for WAN optimization also has to process other non-optimized traffic on the data path. The out-of-path FortiGate units can operate in NAT/Route or Transparent mode. Other out-of-path topologies are also possible. For example, you can install the out-ofpath FortiGate units on the private networks instead of on the WAN. Also, the out-of-path FortiGate units can have one connection to the network instead of two. In a one-arm configuration such as this, security policies and routing have to be configured to send the WAN optimization tunnel out the same interface as the one that received the traffic.
A W at iz tim el op nn N tu io n
ath n f-p tio t-o miza Ou pti o AN W
Pri
va
e eN
two
rk
14
Topology for multiple networks

As shown in Figure 4, you can create multiple WAN optimization configurations between many private networks. Whenever WAN optimization occurs, it is always between two FortiGate units, but you can configure any FortiGate unit to perform WAN optimization with any of the other FortiGate units that are part of your WAN. Figure 4: WAN optimization among multiple networks
e eN tw ork
Pri
va
WAN optimization tunnels N WA ation iz tim
Se
cu
rity
op
You can also configure WAN optimization between FortiGate units with different roles on the WAN. FortiGate units configured as security devices and for WAN optimization can perform WAN optimization as if they are single-purpose FortiGate units just configured for WAN optimization.
d n an atio ity i z ur tim ec p S o N A W
WAN
S ec
d an ion ty uri izat c Se ptim o AN W
ur ity
th pa on of- ati ut- timiz O p No WA Pr iv
N ate
etw
ork
15
WAN optimization with web caching

You can add web caching to a WAN optimization topology when users on a private network communicate with web servers located across the WAN on another private network. Figure 5: WAN optimization with web caching topology
e eN two rk
Pri
va
The topology in Figure 5 is the same as that of Figure 1 on page 12 with the addition of web caching to the FortiGate unit in front of the private network that includes the web servers. In a similar way, you can add web caching to all of the topologies shown in WAN optimization topologies on page 12.
16
d n an atio ity iz ur tim ec p S o N A W io at iz tim el op nn N u A t W n
WAN
, ion ity at g ur iz hin ec im c S pt ca o b N e A w W nd a
rk two Ne te va th Pri wi rvers e bs we
WAN optimization and web caching with FortiClient peers

FortiClient WAN optimization works with FortiGate WAN optimization to accelerate remote user access to the private networks behind FortiGate units. The FortiClient application requires a simple WAN optimization configuration to automatically detect if WAN optimization is enabled on the FortiGate unit. Once WAN optimization is enabled, the FortiClient application transparently makes use of the WAN optimization and web caching features available. Figure 6: FortiClient WAN optimization topology
R em lie tiC or F s e er ot us nt
WAN, LAN, or Internet

io at iz tim ls op ne N n A tu W n
A W N op tim iz at io n
Pri va te tw Ne ork
17
Explicit Web proxy topologies
Explicit Web proxy topologies

You can configure a FortiGate unit to be an explicit web proxy server for Internet web browsing. To use the explicit web proxy, users must add the IP address of the FortiGate interface configured for the explicit web proxy to their web browser proxy configuration. Figure 7: Explicit web proxy topology
If the FortiGate unit supports web caching, you can also add web caching to the security policy that accepts explicit web proxy sessions The FortiGate unit then caches Internet web pages on a hard disk to improve web browsing performance. Figure 8: Explicit web proxy with web caching topology
tw ne ork
it lic xy xp ro E p eb w
Pr
iva
te
tw Ne
ork
Pri
va
te
it lic xy ng xp ro E p er hi eb rv ac w se b c e w
18
w et rn es te it In b s e w
ith
Explicit FTP proxy topologies
Explicit FTP proxy topologies

You can configure a FortiGate unit to be an explicit FTP proxy server for FTP users. To use the explicit web proxy, FTP users must connect to and authenticate with the explicit FTP proxy before connecting to an FTP server. Figure 9: Explicit FTP proxy topology
You can also configure reverse explicit FTP proxy (Figure 10). In this configuration, users on the Internet connect to the explicit web proxy before connecting to an FTP server installed behind a FortiGate unit. Figure 10: Reverse explicit FTP proxy topology
it lic xy xp ro E p P T F
Pri
va
te
tw Ne
ork
er Int
ne
s tu
ers
ty ic pl ex xy o se pr er P ev T R F
FT e Ps rve r
19
Web caching topologies

FortiGate web caching can be added to any security policy and any HTTP or HTTPS traffic accepted by that security policy can be cached on the FortiGate unit hard disk. You can also add web caching explicit web proxy security policies to cache explicit web proxy traffic. You can also created web caching only WAN optimization rules. The network topologies for all of these scenarios are very similar. They involved a FortiGate unit installed between users and web servers with web caching enabled. A typical web-caching topology includes one FortiGate unit that acts as a web cache server (Figure 11). Web caching is enabled in a security policy and the FortiGate unit intercepts web page requests accepted by the security policy, requests web pages from the web servers, caches the web page contents, and returns the web page contents to the users. When the FortiGate unit intercepts subsequent requests for cached web pages, the FortiGate unit contacts the destination web server just to check for changes. Figure 11: Web caching topology
e eN tw ork
Pr
iva
You can also configure reverse proxy web-caching (Figure 12). In this configuration, users on the Internet browse to a web server installed behind a FortiGate unit. The FortiGate unit intercepts the web traffic (HTTP and HTTPS) and caches pages from the web server. Reverse proxy web caching on the FortiGate unit reduces the number of requests that the web server must handle, leaving it free to process new requests that it has not serviced before.
eb W
20
ca ch e
r rve se k b r We two ne
Figure 12: Reverse proxy web caching topology

u et se rs
Int
ern
y ox pr e h se c er ca ev b R we
er erv b s ork We tw ne 21
WCCP topologies
WCCP topologies
You can operate a FortiGate unit as a Web Cache Communication Protocol (WCCP) router or cache engine. As a router, the FortiGate unit intercepts web browsing requests from client web browsers and forwards them to a WCCP cache engine. The cache engine returns the required cached content to the client web browser. If the cache server does not have the required content it accesses the content, caches it and returns the content to the client web browser. Figure 13: WCCP topology
b we nt rs e Cli wse ro b
it un a e s at g a ter tiG tin ou or a r F er P C op C W
FortiGate units can also operate as WCCP cache servers, communicating with WCCP routers, caching web content and providing it to client web browsers as required. WCCP is transparent to client web browsers. The web browsers do not have to be configured to use a web proxy.
it un a e s at g a nt e tiG tin li or a C F er P C op C W
P e C h C ac W C nts e b lie W C
22
WAN optimization 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. To optimize these sessions, you add security policies to the client-side FortiGate unit (which is located between the client network and the WAN, see Figure 14) to accept sessions from the client network that are destined for the server network. To apply WAN optimization to these sessions, you must also add WAN optimization rules to the client-side FortiGate unit. The WAN optimization rules intercept sessions accepted by security policies and apply WAN optimization to them. Figure 14: Client/server architecture
Cli en t
ide t-s it ien te un Cl a rtiG Fo
When a client-side FortiGate unit matches a session with a WAN optimization rule, it uses the information in the rule to attempt to start a WAN optimization tunnel with a server-side FortiGate unit installed in front of the server network. The client-side and server side FortiGate units must be able to identify each other. To do this the client-side FortiGate unit configuration must include the IP address and peer host ID of the server-side FortiGate unit and the configuration of the server-side FortiGate unit must include the IP address and peer host ID of the client-side FortiGate unit. With this information available, when the client-side FortiGate unit attempts to contact the server-side FortiGate unit, the two units share their IP addresses and peer host IDs and confirm that they can create a WAN optimization tunnel between each other. Security policies are not required for WAN optimization on the server-side FortiGate unit. Sessions from the client-side to the server-side FortiGate unit are WAN optimization tunnel requests. As long as the client-side and server-side FortiGate units can identify each other according to peer host ID and IP address the server-side FortiGate unit will accept WAN optimization tunnel requests from the client-side FortiGate unit.
C lie nt co nn ec ts
ide r-s it rve te un Se Ga rti Fo
to se rv er
WAN
S er ve e nn co t es en iv cli ce re m r fro ct io n
Se rve r
23
In addition to basic identification by peer host ID and IP address you can configure authentication options to impose authentication using certificates and pre-shared keys. In addition to you can configure FortiGate units involved in WAN optimization to accept connections from any identified peer or restrict connections to specific peers.
WAN optimization peers

The client-side and server-side FortiGate units are called WAN optimization peers (see Figure 15) 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 clientside 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. Figure 15: WAN optimization peer and tunnel architecture
tw Ne ork
Cli
en
r e ) ee id it P t-s un n e lie at (c tiG or F

n lie er P e ortiC e F n) sid tio nt- plica ie (cl ap t za mi pti el N o nn WA tu tio n
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.
Peer-to-peer and active-passive WAN optimization

You can create peer-to-peer and active-passive WAN optimization configurations. Peerto-peer configurations are less complex because they only require the creation of a WAN optimization rule in the client side FortiGate unit. Active-passive WAN optimization configurations require an active rule on the client side FortiGate unit and a passive rule on the server-side FortiGate unit. For more details about peer to peer and active-passive WAN optimization, see Configuring WAN optimization rules on page 43.
24
A W io at iz tim el op nn N tu n r de ) ee si it P er- un v te er a (s tiG or F

Se rve e rn tw ork
WAN optimization tunnels
WAN optimization and the FortiClient application

PCs running the FortiClient application are client-side peers that initiate WAN optimization tunnels with server-side peer FortiGate units. However, you can have an ever-changing number of FortiClient peers with IP addresses that also change regularly. To avoid maintaining a list of such peers, you can instead configure WAN optimization to accept any peer and use authentication to identify FortiClient peers. Together, the WAN optimization peers apply the WAN optimization features to optimize the traffic flow over the WAN between the clients and servers. WAN optimization reduces bandwidth requirements, increases throughput, reduces latency, offloads SSL encryption/decryption and improves privacy for traffic on the WAN.
Operating modes and VDOMs

To use WAN optimization, the FortiGate units can operate in either NAT/Route or Transparent mode. The client-side 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.

All optimized traffic passes between the FortiGate units or between a FortiClient peer and a FortiGate unit over a WAN optimization tunnel. Traffic in the tunnel can be sent in plain text or encrypted using AES-128bit-CBC SSL. Figure 16: WAN optimization tunnels
e tn tw ork
Cli
en
e id nit -s u nt te lie a C tiG or F
WAN
P ac ke ts
3 2 1
de it si n r- u ve te er a S tiG
or
E N A W ) in s n e 10 et un 78 ck n t rt pa tio po ed za r: 1 pt i ee 3 2 ry tim -p nc op r-to ee (P P ac

3 2
ke ts
1
Se
rv
n er
etw
ork
25
Both plain text and the encrypted peer-to-peer tunnels use TCP destination port 7810. Before a tunnel can be started, the peers must be configured to authenticate with each other and to agree on the tunnel configuration. Then, the client-side 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 rule CLI keyword to configure tunnel sharing for WAN optimization rules with auto-detect set to off. Tunnel sharing means multiple WAN optimization sessions share the same WAN optimization tunnel. Tunnel sharing can improve WAN 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. Tunnel sharing is not always recommended and may not always be the best practice. Aggressive and non-aggressive 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-aggressive protocols.) HTTP and FTP are considered aggressive protocols. If aggressive and nonaggressive 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-sharing 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 users experience with the protocol. Set tunnel-sharing to sharing for applications that are not aggressive and are not sensitive to latency or delays. WAN optimization rules set to sharing and expresssharing can share the same tunnel.
26
Protocol optimization
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 set Protocol to CIFS in a WAN optimization rule, 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. You can select only one protocol in a WAN optimization rule. For best performance, you should separate the traffic by protocol by creating different WAN optimization rules for each protocol. For example, to optimize HTTP traffic, you should set Port to 80 so that only HTTP traffic is accepted by this WAN optimization rule. For an example configuration that uses multiple rules for different protocols, see Example: Active-passive WAN optimization on page 59. If the WAN optimization 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 to a range of different types of traffic 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.
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 leans 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 rule 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, 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.
27
WAN optimization and HA
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 Enable Byte Cache in a WAN optimization rule. The Protocol setting does not affect byte caching. Data is byte cached when it is processed by a WAN optimization rule that includes byte caching. 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.
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 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, the primary unit stores only web cache and byte cache databases. These databases are not synchronized to the subordinate units. So, after a failover, the new primary unit must rebuild its web and byte caches. Rebuilding the byte caches can happen relatively quickly because the new primary unit gets byte cache data from the other FortiGate units 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 and web caching uses provisioned memory to reduce disk I/O and increase disk I/O efficiency. In addition, WAN optimization and web cache require a small amount of additional memory per session for comprehensive flow control logic and efficient traffic forwarding. When WAN optimization and web caching are enabled you will see a reduction in available memory. The amount of reduction will increase when more WAN optimization and web cache sessions are being processed. If you are thinking of enabling WAN optimization or web caching on an operating FortiGate unit, make sure its memory usage is not maxed out during high traffic periods before you enable these features. In addition to using the system dashboard to see the current memory usage you can use the get test wad 1 command to see how much memory is currently being used by WAN optimization and web caching. See get test {wa_cs | wa_dbd | wad | wad_diskd | wccpd} <test_level> on page 197 for more information.
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 WAN Opt. & Cache > Monitor > WAN Opt Monitor.
28
Configuring WAN optimization traffic usage logs
Figure 17: 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 applications 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.
Configuring WAN optimization traffic usage logs

Use the following command to generate WAN optimization traffic log messages for each WAN optimization protocol. WAN optimization traffic logs are required to generate WAN optimization usage reports. By default WAN optimization traffic log messages are not generated:
29
Best practices
config wanopt settings set log-traffic {cifs | ftp | http | mapi | tcp} end For example, to enable WAN optimization traffic logging for CIFS and HTTP traffic enter: config wanopt settings set log-traffic cifs http end You must also enable traffic logging in security policies that accept the traffic to be optimized. As a result of this configuration, traffic log messages with a sub type of wanopt-traffic are generated by the FortiGate unit. You can review, filter, and analyze these messages in the same way as other traffic log messages. For example, to view WAN optimization traffic log messages, go to Log&Report > Log & Archive Access > Traffic Log and configure a filter to view all log messages with a sub type of wanopt-traffic. You can also use the following commands to enable or disable sending WAN optimization traffic logs to memory, FortiAnalyzer, or to a remote syslog server. These are all enabled by default. config log memory filter set wanopt-traffic enable end config log fortianalyzer filter set wanopt-traffic enable end config log syslogd filter set wanopt-traffic enable end
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 Tunnel sharing on page 26. Active-passive HA is the recommended HA configuration for WAN optimization. See Tunnel sharing on page 26. 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 35. Set the explicit HTTP proxy Default Policy Action to Deny. This means that a security policy is required to use the explicit web proxy. See Explicit web proxy configuration overview on page 147. Set the explicit FTP proxy Default Policy Action to Deny. This means that a security policy is required to use the explicit FTP proxy. See Explicit FTP proxy configuration overview on page 172.
30
FortiOS Handbook

WAN optimization storage is used for storing the byte cache and web cache databases. In most cases, you can accept the default WAN optimization storage configuration because all of the disk space available on the FortiGate unit is in one partition. By default WAN optimization and logging and archiving are configured to use this partition. You only have to configure WAN optimization storage if you have more than one possible storage location. This can happen if you have multiple partitions that you can use for storage locations. If you have more than one storage location you can move WAN optimization storage to it. You can also configure WAN optimization to use multiple storage locations. You can also optionally configure WAN optimization storage if you want to adjust the relative amounts of disk space available for byte caching and web caching. This chapter contains the following topics: Formatting the hard disk Configuring WAN optimization and Web cache storage
Formatting the hard disk

In most cases the hard disks on your FortiGate unit should be formatted with one partition that is used for WAN optimization and Logging and Archiving. If for some reason the hard disk is not formatted you can use the following information to format it. In some cases you might also want to use the following options to erase all data from the hard disk by reformatting it. From the web-based manager go to System > Config > Advanced > Disk Management to display information about the hard disk or disks available to the FortiGate unit. To format a hard disk, select the format icon. The hard disk format takes a few minutes and the FortiGate unit restarts after formatting is complete. Fro this web-based manager page you can also view and change the WAN optimization and Web Cache Storage size and view how much of the WAN optimization and web cache storage has been used. From the CLI you can use the following command to view the current disk format and partition status. See the following example for a FortiGate-51B unit. execute disk list
Device I1 partition 1 29.9 GB 29.9 GB ref: 256 ref: 257 SUPER TALENT (IDE) label: 2B6375792136C707
You can use the following command to reformat the hard disk. Use this command if for some reason the disk is not formatted correctly. The command includes the device partition reference number (256) so formats the entire disk and not just the partition. execute disk format 256
31
Configuring WAN optimization and Web cache storage
You can use the following command to reformat the partition. The command includes the partition reference number so formats the partition, removing add data from it. You can use this command to delete all data from the partition and to fix partition errors. execute disk format 257

You can use the following command to add multiple WAN optimization storage locations if your FortiGate unit has multiple disk partitions and you want to use more than one for WAN optimization storage: config system storage Enter get to see the name of the default storage location. You cannot edit this storage location, but you can add new ones: config system storage edit new_storage set partition <partition_number> end Where <partition_number> is the number of the partition to create a storage location in. This cannot be the same as the partition added to the default storage location. This command automatically adds a WAN optimization storage location with the name new_storage.
Changing the amount of space allocated for WAN optimization and Web cache storage
From the web-based manager you can go to System > Config > Advanced > Disk Management to edit the WAN optimization & Web Cache storage and change the allocation size to limit the amount of storage available for WAN optimization byte caching and web caching. The size is in Mbytes. You can use the following command to change the size of any WAN optimization storage location. For example, in the FortiGate-51B the default WAN optimization storage is Internal. Use the following command to limit the amount of space allocated for WAN optimization to 20 Gbytes config wanopt storage edit Internal set size 20000 end
Adjusting the relative amount of disk space available for byte caching and web caching
By default the config wanopt storage command allocates the same amount disk for byte caching and for web caching. In some cases you may want to adjust the relative amounts of disk space available for these two uses. For example, if you have not implemented web caching you may want to reduce the amount of disk space used for web caching and increase the amount of space used for byte caching. You can adjust the relative amount of disk space used for byte caching using the webcache-storage-percentage option of the config wanopt storage command. This option adjusts the percentage in the range of 0 to 100. The default percentage is 50. To reduce the percentage of space allocated on the Internal disk for web caching to 10% (resulting in the amount of space for byte caching increasing to 90%) enter:
32
config wanopt storage edit Internal set webcache-storage-percentage 10 end You can enter this command at any time without disrupting web caching or byte caching performance. Data may be lost from the cache that is reduced in size.
33
34
FortiOS Handbook

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. This chapter describes: Basic WAN optimization peer requirements How FortiGate units process tunnel requests for peer authentication Configuring peers Configuring authentication groups Secure tunneling Monitoring WAN optimization peer performance
Basic WAN optimization peer requirements

WAN optimization requires the following configuration on each peer. For information about configuring local and peer host IDs, see Configuring peers on page 37. 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.
35
How FortiGate units process tunnel requests for peer authentication
Accepting any peer is useful if you have many peers or if peer IP addresses change. For example, you could have many travelling FortiClient peers with IP addresses that are always changing as the users travel to different customer sites. This configuration is also useful if you 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 Configuring authentication groups on page 38.
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 the name of an authentication group, if included in the rule that initiates the tunnel if an authentication group is used, the authentication method it specifies: pre-shared key or certificate the type of tunnel (secure or not). For information about configuring the local host ID, peers and authentication groups, see Configuring peers on page 37 and Configuring authentication groups on page 38. The authentication group is optional unless the tunnel is a secure tunnel. For more information, see Secure tunneling on page 40. 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 clientside 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.
36
Configuring peers
If the server-side FortiGate unit successfully authenticates the tunnel request, the serverside 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 > WAN Opt. Peer > Peer. 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. 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
37
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-to-peer 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. See Secure tunneling on page 40. To add authentication groups, go to WAN Opt. & Cache > WAN Opt. Peer > Authentication Group. 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. For more information about FortiGate units and certificates, see the FortiGate Certificate Management Guide. 1 Go to Wan Opt. & Cache > WAN Opt. Peer > Authentication Group. 2 Select Create New. 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 > Local 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.
38
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 for WAN optimization with the FortiClient application or 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. For more information, see Configuring peers on page 37. 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. For more information, see Configuring WAN optimization rules on page 48. 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. 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 the FortiClient application or 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.
39
Secure tunneling
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 > WAN Opt. Peer > Authentication Group. 2 Select Create New to add a new authentication group. 3 Configure the authentication group: Name Password Peer Acceptance Specify any name. Enter a pre-shared key. Accept Any Peer Authentication Method Pre-shared key
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 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-to-peer 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 Configuring WAN optimization rules on page 43. For a secure tunneling configuration example, see Example: Adding secure tunneling to an active-passive WAN optimization configuration on page 66. Secure tunneling is also used in the configuration example: Example: SSL offloading for a WAN optimization tunnel on page 124.
40
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 peers 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 > Monitor > Peer Monitor.
41
42
FortiOS Handbook

To configure WAN optimization, you add WAN optimization rules. Similar to security policies, when a FortiGate unit receives a connection packet, it analyzes the packets source address, destination address, and service (by destination port number), and attempts to locate a matching WAN optimization rule that decides how to optimize the traffic over the WAN. WAN optimization rules also apply features such as byte-caching and protocol optimization to optimized traffic. You can add one of two types of WAN optimization rules: peer-to-peer and activepassive. A peer-to-peer WAN optimization rule includes a peer host ID. WAN optimization sessions matched by a client-side peer-to-peer rule can only connect to the named server-side peer. When the client-side peer unit 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 rule; you just need to add the client peer host ID and IP address to the server-side FortiGate unit peer list. Peer to peer WAN optimization tunnels use port 7810. For active-passive WAN optimization, you add active rules to client-side FortiGate units and passive rules to server-side FortiGate units. A single passive rule can accept tunnel requests from multiple active rules. The configuration of the active rule enables WAN optimization features. The passive rule uses the configuration of the active rules. The one exception is web caching, which is enabled in passive rules. This chapter describes: WAN optimization rules, security policies, and UTM protection WAN optimization transparent mode WAN optimization rule list WAN optimization address formats Configuring WAN optimization rules
WAN optimization rules, security policies, and UTM protection

The FortiGate unit applies security policies to communication sessions before WAN optimization rules. A WAN optimization rule can be applied to a packet only after the packet is accepted by a security policy. WAN optimization processes all sessions accepted by a security policy that also match a WAN optimization rule. However, if the security policy includes any UTM features, communication sessions accepted by the policy are processed by the UTM engine and not by WAN optimization. Before you add WAN optimization rules, you must add security policies to accept the traffic that you want to optimize.
43
WAN optimization transparent mode
To apply WAN optimization to traffic that is accepted by a security policy containing UTM features, you can use multiple FortiGate units or multiple VDOMs. You apply the UTM features in the first FortiGate unit or VDOM and then apply WAN optimization in the second FortiGate unit or VDOM. You also add inter-VDOM links between the VDOMs. See the configuration example Out-of-path WAN optimization with inter-VDOM routing on page 95. WAN optimization does not apply source and destination NAT settings included in security policies. This means that selecting NAT or adding virtual IPs in a security policy does not affect WAN optimized traffic. WAN optimization is also not compatible with firewall load balancing. However, traffic accepted by these policies that is not WAN optimized is processed as expected. WAN optimization is compatible with identity-based security policies. If a session is allowed after authentication and if the identity-based policy that allows the session does not include UTM features, the session can be processed by matching WAN optimization rules. traffic shaping is compatible with client/server (active-passive) transparent mode WAN optimization rules. Traffic shaping is ignored for peer-to-peer WAN optimization and for client/server WAN optimization not operating in transparent mode.
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 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 FortiGate unit and not from individual clients. Do not confuse WAN optimization transparent mode with FortiGate transparent mode. WAN optimization transparent mode is configured in individual WAN optimization rules. FortiGate Transparent mode is a system setting that controls how the FortiGate unit (or a VDOM) processes traffic.
44
WAN optimization rule list

The WAN optimization rule list displays WAN optimization rules in their order of matching precedence. WAN optimization rule order affects rule matching. For details about arranging rules in the rule list, see How list order affects rule matching on page 46 and Moving a rule to a different position in the rule list on page 47. For information about WAN optimization rules and security policies, see WAN optimization rules, security policies, and UTM protection on page 43. Then you add WAN optimization rules that: match WAN traffic to be optimized that is accepted by a security policy according to source and destination addresses and destination port of the traffic add the WAN optimization techniques to be applied to the traffic. To view the WAN optimization rule list, go to WAN Opt. & Cache > WAN Opt. Rule > Rule. Create New Status ID Source Add a new WAN optimization rule. New rules are added to the bottom of the list. Select to enable a rule or clear to disable a rule. A disabled rule is out of service. The rule identifier. Rules are numbered in the order they are added to the rule list. The source address or address range that the rule matches. For more information, see WAN optimization address formats on page 47. The destination address or address range that the rule matches. For more information, see WAN optimization address formats on page 47. The destination port number or port number range that the rule matches. Indicates whether you have selected byte caching in the WAN optimization rule. Indicates whether the rule is an active (client) rule, a passive (server) rule or if auto-detect is off. If auto-detect is off, the rule can be peer-topeer or Web Cache Only. The protocol optimization WAN optimization technique applied by the rule. For more information, see Protocol optimization on page 27. For a peer-to-peer rule, the name of the peer WAN optimizer at the other end of the link. Indicates whether the rule applies Full Optimization or Web Cache Only. Indicates whether the rule is configured for SSL offloading. Indicates whether the rule is configured to used a WAN optimization tunnel. Delete a rule from the list. Edit a rule.
Destination
Port Method
Auto-Detect
Protocol Peer Mode SSL Secure Tunnel Delete icon Edit icon
45
Insert WAN Optimization Rule Before icon
Add a new rule above the corresponding rule.
Move To icon
Move the corresponding rule before or after another rule in the list. For more information, see How list order affects rule matching on page 46 and Moving a rule to a different position in the rule list on page 47.
How list order affects rule matching

Similar to security policies, you add WAN optimization rules to the WAN optimization rule list. The FortiGate unit uses the first-matching technique to select the WAN optimization rule to apply to a communication session. When WAN optimization rules have been added, each time the FortiGate security accepts a communication session, it then searches the WAN optimization rule list for a matching rule. Matching rules are determined by comparing the rule with the session source and destination addresses and destination port.The search begins at the top of the rule list and progresses in order towards the bottom. Each rule in the rule list is compared with the communication session until a match is found. When the FortiGate unit finds the first matching rule, it applies that rules specified WAN optimization features to the session and disregards subsequent rules. If no WAN optimization rule matches, the session is processed according to the security policy that originally accepted the session. As a general rule, you should order the WAN optimization rule list from most specific to most general because of the order in which rules are evaluated for a match, and because only the first matching rule is applied to a session. Subsequent possible matches are not considered or applied. Ordering rules from most specific to most general prevents rules that match a wide range of traffic from superseding and effectively masking rules that match exceptions. For example, you might have a general WAN optimization rule that applies WAN optimization features but does not apply secure tunneling to most WAN traffic. However, you want to apply secure tunneling to FTP traffic (FTP traffic uses port 21). In this case, you would add a rule that creates a secure tunnel for FTP sessions above the general rule. Figure 18: Example: secure tunneling for FTP correct rule order
Exception
General
FTP sessions (using port 21) would immediately match the secure tunnel rule. Other kinds of services would not match the FTP rule, so rule evaluation would continue until the search reaches the matching general rule. This rule order has the intended effect. But if you reversed the order of the two rules, positioning the general rule before the FTP rule, all session, including FTP, would immediately match the general rule, and the rule to secure FTP would never be applied. This rule order would not have the intended effect.
46
WAN optimization address formats
Figure 19: Example: secure tunneling for FTP incorrect rule order
General
Exception
Similarly, if specific traffic requires exceptional WAN optimization rule settings, you would position those rules above other potential matches in the rule list. Otherwise, the other matching rules would take precedence, and the required exceptional settings might never be used.
Moving a rule to a different position in the rule list

When more than one rule has been defined, the first matching rule is applied to the traffic session. You can arrange the WAN optimization rule list to influence the order in which rules are evaluated for matches with incoming traffic. For more information, see How list order affects rule matching on page 46. Moving a rule in the rule list does not change its ID, which only indicates the order in which the rule was created. To move a rule in the WAN optimization rule list - web-based manager 1 Go to WAN Opt & Cache > WAN Opt. Rule > Rule. 2 In the rule list, note the ID of a rule that is before or after your intended destination. 3 In the row corresponding to the rule that you want to move, select the Move To icon. 4 Select Before or After, and enter the ID of the rule that is before or after your intended destination. This specifies the rules new position in the WAN optimization rule list. 5 Select OK. To move a rule in the WAN optimization rule list - CLI 1 Use the following command to move a WAN optimization rule with ID 34 above the rule in the rule list with ID 10. config wanopt rule move 34 before 10 end 2 Use the following command to move a WAN optimization rule with ID 5 after the rule in the rule list with ID 1. config wanopt rule move 5 after 1 end
WAN optimization address formats

A WAN optimization source or destination address can contain one or more network addresses. Network addresses can be represented by an IP address with a netmask or an IP address range. When representing hosts by an IP address with a netmask, the IP address can represent one or more hosts. For example, a source or destination address can be: a single computer, for example, 192.45.46.45 a subnetwork, for example, 192.168.1.* for a class C subnet
47
0.0.0.0, matches any IP address. The netmask corresponds to the subnet class of the address being added, and can be represented in either dotted decimal or CIDR format. The FortiGate unit automatically converts CIDR-formatted netmasks to dotted decimal format. Example formats: netmask for a single computer: 255.255.255.255, or /32 netmask for a class A subnet: 255.0.0.0, or /8 netmask for a class B subnet: 255.255.0.0, or /16 netmask for a class C subnet: 255.255.255.0, or /24 netmask including all IP addresses: 0.0.0.0 Valid IP address and netmask formats include: x.x.x.x/x.x.x.x, such as 192.168.1.0/255.255.255.0 x.x.x.x/x, such as 192.168.1.0/24 An IP address 0.0.0.0 with netmask 255.255.255.255 is not a valid source or destination address. When representing hosts by an IP range, the range indicates hosts with continuous IP addresses in a subnet, such as 192.168.1.[2-10], or 192.168.1.* to indicate the complete range of hosts on that subnet. You can also indicate the complete range of hosts on a subnet by entering 192.168.1.[0-255] or 192.168.1.0-192.168.1.255. Valid IP range formats include: x.x.x.x-x.x.x.x, for example, 192.168.110.100-192.168.110.120 x.x.x.[x-x], for example, 192.168.110.[100-120] x.x.x.*, for a complete subnet, for example: 192.168.110.* x.x.x.[0-255] for a complete subnet, such as 192.168.110.[0-255] x.x.x.0 -x.x.x.255 for a complete subnet, such as 192.168.110.0 192.168.110.255 You cannot use square brackets [ ] or asterisks * when adding addresses to the CLI. Instead you must enter the start and end addresses of the subnet range separated by a dash -. For example, 192.168.20.0-192.168.20.255 for a complete subnet and 192.168.10.10-192.168.10.100 for a range of addresses.

This section describes all the details that you can configure for the WAN optimization rules. The options available depend on how you configure a specific rule. The conditions are noted. To add a WAN optimization rule - web-based manager 1 Go to WAN Opt. & Cache > WAN Opt. Rule > Rule and select Create New.
48
2 Configure the WAN optimization rule, using the guidance in the following table, and select OK. Select Full Optimization to add a rule that can apply all WAN optimization features. Mode Select Web Cache Only to add a rule that just applies web caching. If you select Web Cache Only, you can configure the source and destination address and port for the rule. You can also select Transparent Mode and Enable SSL. Enter an IP address, followed by a forward slash (/), then subnet mask, or enter an IP address range separated by a hyphen. For more information, see WAN optimization address formats on page 47. Only packets whose source address header contains an IP address matching this IP address or address range will be accepted by and subject to this rule. For a passive rule, the server (passive) source address range should be compatible with the source addresses of the matching client (active) rule. To match one passive rule with many active rules, the passive rule source address range should include the source addresses of all of the active rules. Enter an IP address, followed by a forward slash (/), then subnet mask, or enter an IP address range separated by a hyphen. For more information, see WAN optimization address formats on page 47. Only a packet whose destination address header contains an IP address matching this IP address or address range will be accepted by and subject to this rule. Destination For a Web Cache Only rule, if you set Destination to 0.0.0.0, the rule caches web pages on the Internet or any network. For a passive rule, the server (passive) destination address range should be compatible with the destination addresses of the matching client (active) rule. To match one passive rule with many active rules, the passive rule destination address range should include the destination addresses of all of the active rules. 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 accepted by and subject to this rule. Port For a passive rule, the server (passive) port range should be compatible with the port range of the matching client (active) rule. To match one passive rule with many active rules, the passive rule port range should include the port ranges of all of the active rules.
Source
49
Available only if Mode is set to Full Optimization. Specify whether the rule is Active (client), Passive (server) or if AutoDetect is Off. If Auto-Detect is Off, the rule is a peer-to-peer rule. For an Active (client) rule, you must select all of the WAN optimization features to be applied by the rule. You can select the protocol to optimize, transparent mode, byte caching, SSL offloading, secure tunneling, and an authentication group. A Passive (server) rule uses the settings in the active rule on the client FortiGate unit to apply WAN optimization settings. You can also select web caching for a passive rule. If Auto-Detect is Off, the rule must include all required WAN optimization features and you must select a Peer for the rule. Select this option to configure peer-to-peer WAN optimization where this rule can start a WAN optimization tunnel with this peer only. Available only if Mode is set to Full Optimization, and Auto-Detect is set to Off or Active. Protocol Select CIFS, FTP, HTTP or MAPI to apply protocol optimization for one of these protocols. For information about protocol optimization, see Protocol optimization on page 27. 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. Available only if Mode is set to Full Optimization, and Auto-Detect is set to Off. Peer Select the peer host ID of the peer that this peer-to-peer WAN optimization rule will start a WAN optimization tunnel with. You can also select [Create New...] from the list to add a new peer.
Auto-Detect
Available only if Mode is set to Full Optimization, and Auto-Detect is set to Off or Passive. If Auto-Detect is set to Off, then Protocol must Enable Web be set to HTTP. Cache Select to apply WAN optimization web caching to the sessions accepted by this rule. For more information, see Web caching on page 73. Available only if Mode is set to Full Optimization and Auto-Detect is set to Active or Off, or if Mode is set to Web Cache Only. Servers receiving packets after WAN optimization see different Transparent source addresses depending on whether or not you select Mode Transparent Mode. For more information, see WAN optimization transparent mode on page 44. Available only if Mode is set to Full Optimization, and Auto-Detect is set to Off or Active.
Enable Byte Select to apply WAN optimization byte caching to the sessions Caching accepted by this rule. For more information, see Byte caching on page 27.
50
Available only if Auto-Detect is set to Active or Off. Select to apply SSL offloading for HTTPS 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 rule to accept SSL-encrypted traffic. For example, you can configure the rule to accept HTTPS traffic by setting Port to 443. If you enable SSL offloading, you must also use the CLI command config wanopt ssl-server to add an SSL server for each HTTP server that you want to offload SSL encryption/decryption for. For more information, see SSL offloading for WAN optimization and web caching on page 119. Enable Secure Tunnel
Available only if Mode is set to Full Optimization, and Auto-Detect is set to Active or Off. If you select Enable Secure Tunnel, the WAN optimization tunnel is encrypted using SSL encryption. You must also add an authentication group to the rule. For more information, see Secure tunneling on page 40.
Enable SSL
Available only if Mode is set to Full Optimization, and Auto-Detect is set to Active or Off. Select this option and select an authentication group from the list if you want Authenticati groups of FortiGate units to authenticate with each other before starting the WAN optimization tunnel. You must also select an authentication group if you on Group select Enable Secure Tunnel. You must add identical authentication groups to both of the FortiGate units that will participate in the WAN optimization tunnel started by the rule. For more information, see Configuring authentication groups on page 38.
To add a WAN optimization rule - CLI Using the guidance in the previous table, enter the following commands. For more information, see the wanopt and rules listings in the FortiGate CLI Reference. config wanopt rule edit <index_int> set auth-group <auth_group_name> set auto-detect {active | off | passive} set byte-caching {disable | enable} set dst-ip <address_ipv4>[-<address-ipv4>] set mode {full | webcache-only} set peer <peer_name> set port <port_int>[-<port-int>] set proto {cifs | ftp | http | mapi | tcp} set secure-tunnel {disable | enable} set src-ip <address_ipv4>[-<address-ipv4>] set ssl {disable | enable} set status {disable | enable} set transparent {disable | enable} set tunnel-non-http {disable | enable} set tunnel-sharing {express-shared | private | shared} set unknown-http-version {best-effort | reject | tunnel} set webcache {disable | enable} end
51
Processing non-HTTP sessions accepted by an HTTP rule

From the CLI, use the tunnel-non-http keyword of the config wanopt rule 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. 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 unknown-http-version keyword of the config wanopt rule command to specify how a rule handles such HTTP sessions. 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.
52
FortiOS Handbook

This chapter provides the following basic examples to illustrate WAN optimization configurations introduced in the previous chapters: Example: Basic peer-to-peer WAN optimization configuration Example: Active-passive WAN optimization Example: Adding secure tunneling to an active-passive WAN optimization configuration
Example: Basic peer-to-peer WAN optimization configuration

Peer-to-peer WAN optimization is the simplest WAN optimization configuration. In a peer to peer configuration the WAN optimization tunnel can be set up only between one clientside FortiGate unit and one server-side FortiGate unit named in the WAN optimization rule added to the client-side FortiGate unit. When the client-side FortiGate unit initiates a tunnel with the server-side FortiGate unit, the packets that initiate the tunnel include extra information so that this server-side FortiGate unit can determine that it is a peer-to-peer tunnel request. This extra information is required because the server-side FortiGate unit does not require a WAN optimization rule; you just need to add the client peer host ID and IP address to the server-side FortiGate unit peer list. The extra information in the communication session plus the peer list entry allow the server-side FortiGate unit to set up the WAN optimization tunnel with the client-side FortiGate unit by using only the settings on the client-side WAN optimization rule. Traffic shaping is ignored for peer-to-peer WAN optimization.
In a peer-to-peer WAN optimization configuration you create a peer-to-peer WAN optimization rule on the client-side FortiGate unit with Auto-Detect to Off and include the peer host ID of the server-side FortiGate unit. Using this rule, the client-side FortiGate unit can create a WAN optimization tunnel only with the peer that is added to the rule. You do not have to add a rule to the server-side FortiGate unit. But the server-side FortiGate unit peer list must include the Peer Host ID and IP address of the client FortiGate unit. The server-side FortiGate unit uses the WAN optimization settings in the client-side rule.
Network topology and assumptions

This example configuration includes a client-side FortiGate unit called Peer_Fgt_1 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 Peer_Fgt_2 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.
53
Figure 20: Example peer-to-peer topology

ork etw t n 20.0 en 1 Cli .20. 2 17
IP 17 A 2. dd 2 0 re . 3 ss 4. 12
WAN
IP 19 A 2. dd 1 6 re 8 . ss 30 .1 2 A W (L oc n io _2 at gt iz _F tim er er op rv Pe N se D: tI os al H
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 by adding peers and a security policy that accepts traffic to be optimized. 2 Configure the server-side FortiGate unit. Also note that if you perform any additional actions between procedures, your configuration may have different results.
Configuring basic peer-to-peer WAN optimization - web-based manager

Use the following steps to configure the example WAN optimization configuration from the client-side and server-side FortiGate unit web-based manager. (CLI steps follow.) To configure the client-side FortiGate unit and security policy 1 Go to WAN Opt. & Cache > WAN Opt. Peer > Peer and enter a Local Host ID for the client-side FortiGate unit: Local Host ID Peer_Fgt_1
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 IP Address 4 Select OK. Peer_Fgt_2 192.168.30.12
) n io _1 at gt iz _F tim t er op n e ie P N cl : D A tI W os H al oc (L
tw ne er .0 erv 8.10 b s 16 We 192.
ork
54
5 Go to Policy > Policy > Policy and add a security policy to the client-side FortiGate unit that accepts traffic to be optimized: Source Interface/Zone Source Address Destination Address Schedule Service Action port1 all all always ANY ACCEPT
Destination Interface/Zone port2
6 Go to WAN Opt. & Cache > WAN Opt. Rule > Rule and select Create New. 7 Configure the rule: Mode Source Destination Port Auto-Detect Protocol Peer Transparent Mode Full Optimization 172.20.120.* 192.168.10.* 135 Off MAPI Peer_Fgt_2 Select
Enable Byte Caching Select 8 Select OK. The rule is added to the bottom of the WAN optimization list. 9 If required, move the rule to a different position in the list so that the rule accepts the required MAPI sessions that use port 135. Depending on your rule list configuration, this may involve moving the rule above more general rules that would also match MAPI traffic. For more information, see How list order affects rule matching on page 46 and Moving a rule to a different position in the rule list on page 47. To configure the server-side FortiGate unit 1 Go to WAN Opt. & Cache > WAN Opt. Peer > Peer and enter a Local Host ID for the server-side FortiGate unit: Local Host ID Peer_Fgt_2
2 Select Apply to save your setting. 3 Select Create New and add a Peer Host ID and the IP Address for the peer side FortiGate unit: Peer Host ID IP Address 4 Select OK. Peer_Fgt_1 172.20.34.12
55
Configuring basic peer-to-peer WAN optimization - CLI

Use the following steps to configure the example WAN optimization configuration from the client-side and server-side FortiGate unit CLI. To configure the client-side FortiGate unit and security policy 1 Add the Local Host ID to the client-side FortiGate configuration: config wanopt settings set host-id Peer_Fgt_1 end 2 Add the server-side Local Host ID to the client-side peer list: config wanopt peer edit Peer_Fgt_2 set ip 192.168.30.12 end 3 Add a security policy to the client-side FortiGate unit to accept the traffic to be optimized: config firewall policy edit 23 set srcintf port1 set dstintf port2 set srcaddr all set dstaddr all set action accept set service ANY set schedule always end end 4 Add the following peer-to-peer rule: config wanopt rule edit 2 set src-ip 172.20.120.0-172.20.120.255 set dst-ip 192.168.10.0-192.168.10.255 set port 135 set proto mapi set peer Peer_Fgt_2 end Accept default settings for auto-detect (off), transparent (enable), status (enable), mode (full), byte-caching (enable), ssl (disable), secure-tunnel (disable), auth-group (null), unknown-http-version (tunnel), and tunnelnon-http (disable). 5 If required, move the rule to a different position in the list. For more information, see Moving a rule to a different position in the rule list on page 47. 6 If required, use the move command to change the order of the rules in the list so that the rule accepts the required MAPI sessions that use port 135. Depending on your rule list configuration, this may involve moving the rule above more general rules that would also match MAPI traffic. For more information, see How list order affects rule matching on page 46 and Moving a rule to a different position in the rule list on page 47.
56
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 Peer_Fgt_2 end 2 Add the client-side Local Host ID to the server-side peer list: config wanopt peer edit Peer_Fgt_1 set ip 192.168.30.12 end
Testing and troubleshooting the configuration

To test the configuration attempt to start a web browsing session between the user network and the web server network. For example, from a PC on the user 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 user network you should be able to connect to this web server over the WAN optimization tunnel. If you can connect, check WAN optimization monitoring (go to WAN Opt. & Cache > Monitor > Monitor). 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 cant 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 UTM options. 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 user 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 user 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 on the client-side FortiGate unit to display WAN optimization tunnel protocol statistics. The http tunnel and tcp tunnel parts of the command output below shows that WAN optimization has been processing HTTP and TCP packets. get test wad 11 wad tunnel protocol stats: http tunnel bytes_in=1751767 bytes_out=325468 ftp tunnel bytes_in=0 bytes_out=0 cifs tunnel bytes_in=0 bytes_out=0 mapi tunnel bytes_in=0 bytes_out=0
57
tcp tunnel bytes_in=3182253 bytes_out=200702 maintenance tunnel bytes_in=11800 bytes_out=15052 Enter the following command to display the current WAN optimization peers. You can use this command to make sure all peers are configured correctly. The command output for the client side FortiGate unit shows one peer with IP address 192.168.20.1, peer name Web_servers, and with 10 active tunnels. get test wad 26 peer name=Web_servers ip=192.168.20.1 vd=0 version=1 tunnels(active/connecting/failover)=10/0/0 sessions=0 n_retries=0 version_valid=true 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
58
Example: Active-passive WAN optimization
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

In active-passive WAN optimization you add active WAN optimization rules on the clientside FortiGate unit by setting WAN optimization Auto-Detect to Active. You configure passive WAN optimization rules on the server-side FortiGate unit by setting WAN optimization Auto-Detect to Passive. You can add multiple active rules for one passive rule to optimize different protocols. Since you do not configure the protocol in the passive rule, one passive rule can be used for each of the active rules. Adding fewer passive rules simplifies the WAN optimization configuration.

This example configuration includes three active rules on the client-side FortiGate unit and one passive rule in the server-side FortiGate unit. The active rules do the following: optimize CIFS traffic from IP addresses 172.20.120.100 to 172.20.120.200 optimize HTTP traffic from IP addresses 172.20.120.100 to 172.20.120.150 optimize FTP traffic from IP addresses 172.20.120.151 172.20.120.200. You can do this by adding three active WAN optimization rules to the client-side FortiGate unit, one for each protocolwith port set to 80 for the HTTP rule, 21 for the FTP rule and 1-65535 for the CIFS rule. Then you arrange the rules in the WAN optimization rule list with the CIFS rule last because the HTTP and FTP rules include single port numbers.
59
Figure 21: Example active-passive WAN optimization topology

ork o etw 0 t r n 0.10 0 e Us 0.12 0.20 2.2 0.12 17 2.2 17
IP 17 A 2. dd 30 re .1 ss 20 .1
WAN
IP 19 A 2. dd 16 re 8. ss 20 .1 Lo ca e ve id ) r S le e r- ru _s ve e eb er iv W S ss : a ID (p st o lH

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 by adding peers and a security policy that accepts traffic to be optimized. 2 Add WAN optimization rules to the FortiGate unit. 3 Configure the server-side FortiGate unit. Also note that if you perform any additional actions between procedures, your configuration may have different results.
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 server-side FortiGate unit web-based manager. (CLI steps follow.) To configure peers on the client-side FortiGate unit and add a security policy 1 Go to WAN Opt. & Cache > WAN Opt. Peer > Peer and enter a Local Host ID for the client-side FortiGate unit: Local Host ID
User_net
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 IP Address
Web_servers 192.168.20.1
Lo
e e id ) _n -S le er nt ru s lie e : U C ctiv ID (a ost lH t
ca
o etw rn 0 rve .10. e b s 168 We 192.
rk
60
rs
4 Select OK. 5 Go to Policy > Policy > Policy and select Create New to add a security policy to the client-side FortiGate unit to accept the traffic to be optimized: Source Interface/Zone Source Address Destination Interface/Zone Destination Address Schedule Service Action port1 all port2 all always ANY ACCEPT
To add the active rules to the client-side FortiGate unit 1 Go to WAN Opt. & Cache > WAN Opt. Rule > Rule. 2 Select Create New to add the active rule to optimize CIFS traffic from IP addresses 172.20.120.100 to 172.20.120.200: Mode Source Destination Port Auto-Detect Protocol Transparent Mode Full Optimization 172.20.120.[100-200] 192.168.10.* 1 - 65535 Active CIFS Select
Enable Byte Caching Select 3 Select OK. 4 Select Create New to add the active rule to optimize HTTP traffic for IP addresses 172.20.120.100 to 172.20.120.150: Mode Source Destination Port Auto-Detect Protocol Transparent Mode Full Optimization 172.20.120.[100-150] 192.168.10.* 80 Active HTTP Select
Enable Byte Caching Select 5 Select OK.
61
6 Select Create New to add the active rule to optimize FTP traffic from IP addresses 172.20.120.151 172.20.120.200: Mode Source Destination Port Auto-Detect Protocol Transparent Mode Full Optimization 172.20.120.[151-200] 192.168.10.* 21 Active FTP Select
Enable Byte Caching Select 7 Select OK. 8 If required, use the Move To icon to change the order of the rules in the list so that the HTTP and FTP rules are above the CIFS rule in the list. You may need to do this if you have other WAN optimization rules in the list. For more information, see How list order affects rule matching on page 46 and Moving a rule to a different position in the rule list on page 47. To configure the server-side FortiGate unit 1 Go to WAN Opt. & Cache > WAN Opt. Peer > Peer and enter a Local Host ID for the server-side FortiGate unit: Local Host ID Web_servers
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 IP Address 4 Select OK. 5 Go to WAN Opt. & Cache > WAN Opt. Rule > Rule and select Create New. 6 Add the passive rule. The source address matches the 172.20.120.100 to 172.20.120.200 IP address range and the 1-65535 port range. You can also enable web caching for the HTTP traffic: Mode Source Destination Port Auto-Detect Enable Web Cache 7 Select OK. The rule is added to the bottom of the rule list. Full Optimization 172.20.120.[100-200] 192.168.10.* 1-65535 Passive Select User_net 172.30.120.1
62
8 If required, move the rule to a different position in the list so that the tunnel request from the client-side FortiGate unit matches with this rule. For more information, see Moving a rule to a different position in the rule list on page 47.
Configuring basic active-passive WAN optimization - CLI

Use the following steps to configure the example WAN optimization configuration from the client-side and server-side FortiGate unit CLI. To configure peers on the client-side FortiGate unit and add a security policy 1 Add the Local Host ID to the client-side FortiGate configuration: config wanopt settings set host-id User_net end 2 Add the server-side Local Host ID to the client-side peer list: config wanopt peer edit Web_servers set ip 192.168.20.1 end 3 Add a security policy to the client-side FortiGate unit to accept the traffic to be optimized: config firewall policy edit 20 set srcintf port1 set dstintf port2 set srcaddr all set dstaddr all set action accept set service ANY set schedule always end end To add the active rules to the client-side FortiGate unit 1 Add the following active rule to optimize CIFS traffic for IP addresses 172.20.120.100 to 172.20.120.200: config wanopt rule edit 2 set auto-detect active set src-ip 172.20.120.100-172.20.120.200 set dst-ip 192.168.10.0-192.168.10.255 set port 1-65535 set proto cifs end Accept default settings for transparent (enable), status (enable), mode (full), byte-caching (enable), ssl (disable), secure-tunnel (disable), auth-group (null), unknown-http-version (tunnel), and tunnel-non-http (disable). 2 Add the following active rule to optimize HTTP traffic for IP addresses 172.20.120.100 to 172.20.120.150:
63
config wanopt rule edit 3 set auto-detect active set src-ip 172.20.120.100-172.20.120.150 set dst-ip 192.168.10.0-192.168.10.255 set port 80 end Accept default settings for transparent (enable), proto (http), status (enable), mode (full), byte-caching (enable), ssl (disable), secure-tunnel (disable), auth-group (null), unknown-http-version (tunnel), and tunnelnon-http (disable). 3 Add the following active rule to optimize FTP traffic from IP addresses 172.20.120.151 172.20.120.200: config wanopt rule edit 4 set auto-detect active set src-ip 172.20.120.151-172.20.120.200 set dst-ip 192.168.10.0-192.168.10.255 set port 21 set proto ftp end Accept default settings for transparent (enable), status (enable), mode (full), byte-caching (enable), ssl (disable), secure-tunnel (disable), authgroup (null), unknown-http-version (tunnel), and tunnel-non-http (disable). 4 If required, use the move command to change the order of the rules in the list so that the HTTP and FTP rules are above the CIFS rule in the list. You may need to do this if you have other WAN optimization rules in the list. For more information, see How list order affects rule matching on page 46 and Moving a rule to a different position in the rule list on page 47. 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 Web_servers end 2 Add the client-side Local Host ID to the server-side peer list: config wanopt peer edit User_net set ip 172.20.120.1 end 3 Add the following passive rule to the server-side FortiGate unit: config wanopt rule edit 5 set auto-detect passive set src-ip 172.20.120.[100-200] set dst-ip 192.168.10.0-192.168.10.255 set port 1-65535 set webcache enable
64
end Accept default settings for status (enable) and mode (full). 4 If required, use the move command to move the rule to a different position in the list so that the tunnel request from the client-side FortiGate unit matches with this rule. For more information, see Moving a rule to a different position in the rule list on page 47.

To test the configuration attempt to start a web browsing session between the user network and the web server network. For example, from a PC on the user 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 user network you should be able to connect to this web server over the WAN optimization tunnel. If you can connect, check WAN optimization monitoring (go to WAN Opt. & Cache > Monitor > Monitor). 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 cant 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 UTM options. 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 user 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 user 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 display WAN optimization tunnel protocol statistics. The http tunnel and tcp tunnel parts of the command output below shows that WAN optimization has been processing HTTP and TCP packets. get test wad 11 wad tunnel protocol stats: http tunnel bytes_in=1751767 bytes_out=325468 ftp tunnel bytes_in=0 bytes_out=0 cifs tunnel bytes_in=0 bytes_out=0 mapi tunnel bytes_in=0 bytes_out=0 tcp tunnel bytes_in=3182253 bytes_out=200702 maintenance tunnel bytes_in=11800 bytes_out=15052
65
Example: Adding secure tunneling to an active-passive WAN optimization configuration WAN optimization configuration examples
Enter the following command to display the current WAN optimization peers. You can use this command to make sure all peers are configured correctly. The command output for the client side FortiGate unit shows one peer with IP address 192.168.20.1, peer name Web_servers, and with 10 active tunnels. get test wad 26 peer name=Web_servers ip=192.168.20.1 vd=0 version=1 tunnels(active/connecting/failover)=10/0/0 sessions=0 n_retries=0 version_valid=true 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 rule is added to the client-side FortiGate unit and a passive rule to the server-side FortiGate unit. The active rule uses 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 preshared key is 2345678. The topology for this example is shown in Figure 22. This example includes web-based manager configuration steps followed by equivalent CLI configuration steps. For information about secure tunneling, see Secure tunneling on page 40.
66
WAN optimization configuration examples Example: Adding secure tunneling to an active-passive WAN optimization configuration

This example configuration includes a client-side FortiGate unit called User_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. Figure 22: Example active-passive WAN optimization and secure tunneling topology
ork tw ne 20.0 er Us .20.1 72 1
IP 17 A 2. dd 30 re .1 ss 20 .1
WAN
IP 19 A 2. dd 16 re 8. ss 20 .1 Lo ca e ve id ) r S le e r- ru _s ve e eb er iv W S s : as ID (p st o lH

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 by adding peers and a security policy that accepts traffic to be optimized. 2 Add an authentication group and WAN optimization rule to the client-side FortiGate unit. 3 Configure peers on the server-side FortiGate unit. 4 Add the same authentication group and add a WAN optimization rule to the serverside FortiGate unit. 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 server-side FortiGate unit web-based manager. (CLI steps follow.)
Lo
e e id ) _n -S le er nt ru s lie e : U C ctiv ID (a ost lH t
ca
o tw ne er 0.0 erv .1 b s 168 We 192.
rk
rs
67
To configure peers on the client-side FortiGate unit and add a security policy 1 Go to WAN Opt. & Cache > WAN Opt. Peer > Peer and enter a Local Host ID for the client-side FortiGate unit: Local Host ID User_net
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 IP Address 4 Select OK. 5 Go to Policy > Policy > Policy and select Create New to add a security policy to the client-side FortiGate unit to accept the traffic to be optimized: Source Interface/Zone Source Address Destination Interface/Zone Destination Address Schedule Service Action port1 all port2 all always ANY ACCEPT Web_servers 192.168.20.1
To add the authentication group and WAN optimization rule to the client-side FortiGate unit 1 Go to Wan Opt. & Cache > WAN Opt. Peer > Authentication Group. 2 Select Create New to add a new authentication group to be used for secure tunneling: Name Password Peer Acceptance 3 Select OK. 4 Go to Wan Opt. & Cache > WAN Opt. Rule > Rule. 5 Select Create New to add an active rule that enables secure tunneling and includes the authentication group: Mode Source Destination Port Auto-Detect Protocol Full Optimization 172.20.120.[100-200] 192.168.10.* 80 Active HTTP Auth_Secure_Tunnel 2345678 Accept Any Peer Authentication Method Pre-shared key
68
Transparent Mode Enable Byte Caching Enable Secure Tunnel Authentication Group 6 Select OK.
Select Select Select Auth_Secure_Tunnel
To configure peers on the server-side FortiGate unit 1 Go to WAN Opt. & Cache > WAN Opt. Peer > Peer and enter a Local Host ID for the server-side FortiGate unit: Local Host ID Web_servers
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 IP Address 4 Select OK. To add the authentication group and WAN optimization rule to the server-side FortiGate unit 1 Go to Wan Opt. & Cache > WAN Opt. Peer > Authentication Group. 2 Select Create New and add a new authentication group to be used for secure tunneling: Name Password Peer Acceptance Auth_Secure_Tunnel 2345678 Accept Any Peer Authentication Method Pre-shared key User_net 172.30.120.1
3 Go to WAN Opt. & Cache > WAN Opt. Rule > Rule and select Create New. 4 Add the passive rule. The source address matches the 172.20.120.100 to 172.20.120.200 IP address range and the 1-65535 port range. You can also enable web caching for HTTP traffic: Mode Source Destination Port Auto-Detect Full Optimization 172.20.120.[100-200] 192.168.10.* 1-65535 Passive
Enable Web Cache Select 5 Select OK.
69
Configuring WAN optimization with secure tunneling - CLI

Use the following steps to configure the example WAN optimization configuration from the client-side and server-side FortiGate unit CLI. To configure peers on the client-side FortiGate unit and add a security policy 1 Add the Local Host ID to the client-side FortiGate configuration: config wanopt settings set host-id User_net end 2 Add the server-side Local Host ID to the client-side peer list: config wanopt peer edit Web_servers set ip 192.168.20.1 end 3 Add a security policy to the server-side FortiGate unit to accept the traffic to be optimized: config firewall policy edit 20 set srcintf port1 set dstintf port2 set srcaddr all set dstaddr all set action accept set service ANY set schedule always end end To add the authentication group and WAN optimization rule to the client-side FortiGate unit 1 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. 2 Add the following active rule to optimize HTTP traffic for IP addresses 172.20.120.100 to 172.20.120.200: config wanopt rule edit 1 set auto-detect active set src-ip 172.20.120.100-172.20.120.200 set dst-ip 192.168.10.0-192.168.10.255 set port 80 set proto http set secure-tunnel enable set auth-group Auth_Secure_Tunnel end Leave the rest of the settings at their default values.
70
To configure peers on the server-side FortiGate unit 1 Add the Local Host ID to the server-side FortiGate configuration: config wanopt settings set host-id Web_servers end 2 Add the client-side Local Host ID to the server-side peer list: config wanopt peer edit User_net set ip 172.20.120.1 end To add the authentication group and WAN optimization rule to the server-side FortiGate unit 1 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. 2 Add the following passive rule to the server-side FortiGate unit: config wanopt rule edit 5 set auto-detect passive set src-ip 172.20.120.[100-200] set dst-ip 192.168.10.0-192.168.10.255 set port 1-65535 set webcache enable end Leave status (enable) and mode (full) at their default values.
71
72
FortiOS Handbook
Web caching
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. Web caching can also support caching HTTPS sessions provided that you import the correct certificate. See RFC 2616 for information about web caching for HTTP 1.1. Web caching does not cache audio and video streams including Flash videos and streaming content. Web caching involves storing HTML pages, images, servlet responses and other webbased objects for later retrieval. These objects are stored in the web cache storage location defined by the config wanopt storage command. You can also go to System > Config > Advanced > Disk Management to view the storage locations on the FortiGate unit hard disks. 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. 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 and WAN optimization rule. 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. When enabled in a WAN optimization rule, the FortiGate unit caches HTTP traffic processed by that WAN optimization rule. You can add WAN optimization rules that only apply web caching. You can also add web caching to WAN optimization rules for HTTP traffic that also include byte caching, protocol optimization, and other WAN optimization features. Web caching caches compressed and non-compressed versions of the same file separately. If the HTTP protocol considers the compressed and uncompressed versions of a file the same object, only the compressed or uncompressed file will be cached. This section contains the following topics: Web caching in security policies Web Caching only WAN optimization Web caching for active-passive WAN optimization Web caching for peer-to-peer WAN optimization Exempting web sites from web caching Changing web cache settings Monitoring Web caching performance
73
Web caching in security policies
Web caching

Web caching can be applied to any HTTP traffic, including explicit web proxy traffic, accepted by any security policy by enabling web caching in that security policy. Enabling web caching in a security policy cannot apply web caching to HTTPS traffic. To apply web caching to HTTPS traffic you need to create a WAN optimization rule. Web Caching in a security policy takes place before web caching in a WAN Optimization rule. So traffic accepted by a security policy that includes web caching will not be cached by the WAN optimization rule. By default FortiOS assumes HTTP traffic uses TCP port 80. So web caching in a security policy caches all HTTP traffic accepted by the policy on TCP port 80. If you want to cache HTTP traffic on other ports, you can enable UTM for the security policy and configure a protocol options profile to that looks for HTTP traffic on other TCP ports or on multiple ports. If you set the HTTP port to 0 (for auto detection) in a protocol options profile, FortiOS looks for HTTP traffic on any port. In this case, HTTP traffic is detected by the IPS. Setting the HTTP port to 0 in a protocol options profile is not compatible with web caching. If you set the HTTP port to 0, web caching only caches HTTP traffic on port 80. You can add web caching to a security 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 requirements of a public facing web server by caching objects on the FortiGate unit to offload processing from the web server. A reverse proxy with web caching configuration. Do this by selecting the web cache option for 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.
Example: Web caching of Internet content for users on an internal network

This example describes how to configure web caching for users on a private network connecting to the Internet. This example uses web caching in a security policy to cache HTTP traffic.

This example includes a client network with subnet address 10.31.101.0 connecting to web servers on the Internet (Figure 23). In this basic example, 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 is just added to this security policy. Initially, UTM is not selected so the example caches all HTTP traffic on TCP port 80. The example also describes how to configure the security policy to cache HTTP traffic on port 80 and 8080 by added a protocol options profile that looks for HTTP traffic on TCP ports 80 and 8080.
74
Web caching
Figure 23: Example web caching topology

ork etw 24 N / ate 1.0 riv 1.10 P 3 . 10
e ac erf int 100 al . ern 01 Int .31.1 10

This section breaks down the configuration for this example into smaller procedures. For best results, follow the procedures in the order given: 1 Add web caching to the security policy that all users on the private network use to connect to the Internet. 2 Add a protocol options profile to look for HTTP traffic on ports 80 and 8080 and add this protocol options profile to the security policy to enable web caching HTTP traffic on ports 80 and 8080. 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 web caching to a security policy 1 Go to Policy > Policy > Policy and add a security policy that allows all users on the internal network to access the Internet. Source Interface/Zone Source Address Destination Address Schedule Service Action Enable web cache NAT Internal all all always ANY ACCEPT Select Enable NAT
Destination Interface/Zone wan1
2 Select OK to save the security policy. 3 If required, adjust the position of the security policy in the internal > wan1 policy list to make sure all outgoing connections to the Internet use this policy
e at he tiG ac or C F b e W
75
Web caching
To cache HTTP traffic on port 80 and 8080 1 Go to Policy > Policy > Protocol Options and either add a new a new protocol options profile or edit the default profile. 2 Change the HTTP settings of the protocol options profile to look for HTTP traffic on ports 80 and 8080: Port 80, 8080
Adjust other settings as required or leave them as the defaults. 3 Edit the security policy created in the previous procedure. Select UTM and set Protocol Options to the protocol options profile you added or changed.
Configuration Steps - CLI

Use the following steps to configure the example configuration from the FortiGate CLI. To add 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. 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 webcache enable set nat enable end 2 If required, adjust the position of the security policy in the internal > wan1 policy list to make sure all outgoing connections to the Internet use this policy To cache HTTP traffic on port 80 and 8080 1 Go to Policy > Policy > Protocol Options and either add a new a new protocol options profile or edit the default profile. 1 Enter the following command to add a protocol option profile that looks for HTTP traffic on ports 80 and 8080. config firewall profile-protocol-options edit custom-HTTP-proto config http set port 80 8080 end end 2 Enter the following command to add the protocol options profile to the security policy: config firewall policy edit 1 set utm-status enable set profile-protocol-options custom-HTTP-proto end
76
Web caching
Web Caching only WAN optimization

You can use Web Cache Only WAN optimization to cache web pages from any web server. In a Web Cache Only configuration, only one FortiGate unit is involved. All traffic between a client network and one or more web servers is intercepted by a Web Cache Only WAN optimization rule. This rule causes the FortiGate unit to cache pages from the web servers on the FortiGate unit and makes the cached pages available to users on the client network. Web cache only WAN optimization can be configured for standard and reverse web caching. In a standard web caching configuration, the FortiGate unit caches pages for users on a client network. The FortiGate unit is installed between the client network and the WAN or Internet, and the web server or servers are located elsewhere on the WAN or Internet. See Example: Web Cache Only WAN optimization on page 77 for an example of this configuration. You can also create a reverse proxy web caching configuration where the FortiGate unit is dedicated to providing web caching for a single web server or server farm. In this second configuration, the FortiGate unit is installed between the server network and the WAN or Internet, and users are located elsewhere on the WAN or Internet. See Example: SSL offloading and reverse proxy web caching for an Internet web server using static one-toone virtual IPs on page 127 for an example of this configuration. WAN optimization rule order affects Web Cache Only rules in the same way as other WAN optimization rules. For more information, see How list order affects rule matching on page 46 and Moving a rule to a different position in the rule list on page 47. Since only one FortiGate unit is involved in a Web Cache Only configuration, you do not need to change the WAN optimization peer configuration.
Example: Web Cache Only WAN optimization

This example describes how to configure web caching for users in a client network connecting to a web server network across a WAN.

This example includes a client network with subnet address 172.20.120.0 connecting to web servers on a network with subnet address 192.168.10.0. Only the communication between the client network and the web server network using Port 80 is to be cached, so the Web Cache Only WAN optimization rule includes the IP addresses of the networks and the Port is set to 80. As well, the security policy used in this example includes the addresses of the client and sever subnets instead of more general security addresses.
77
Web caching
Figure 24: Example Web Cache Only topology

ork tw Ne 0.0 t en 12 Cli 2.20. 7 1
n io at iz e tim ch op ca N b A e W w
0 11 0 11 10 10 10

This section breaks down the configuration for this example into smaller procedures. For best results, follow the procedures in the order given: 1 Add firewall addresses and a security policy that accepts traffic to be optimized to the FortiGate unit. 2 Add a Web Cache Only WAN optimization rule to the FortiGate unit. If you perform any additional actions between procedures, your configuration may have different results.
Configuring Web Cache Only WAN optimization - web-based manager

Use the following steps to configure the example WAN optimization configuration from the FortiGate unit web-based manager. To add the firewall addresses and security policy 1 Go to Firewall Objects > Address > Address and select Create New to add the firewall address for the client network: Address Name Type Interface Client_Net Subnet/IP Range Any
Subnet / IP Range 172.20.120.*
2 Add the firewall address for the web server network: Address Name Type Web_Server_Net Subnet/IP Range
eb W ca ch e
er erv b s ork We tw 0.0 ne 8.1 6 2.1 19
78
Web caching
Subnet / IP Range 192.168.10.* Interface Any 3 Go to Policy > Policy > Policy and select Create New to add a security policy that accepts traffic to be web cached: Source Interface/Zone Source Address Destination Interface/Zone Destination Address Schedule Service Action port1 Client_Net port2 Web_Server_Net always HTTP ACCEPT
To add a Web Cache Only WAN optimization rule 1 Go to WAN Opt. & Cache > WAN Opt. Rule > Rule and select Create New. 2 Select Web Cache Only. 3 Configure the Web Cache Only rule: Mode Source Destination Web Cache Only 172.20.120.* 192.168.10.* 80 Port Usually you would set the port to 80 to cache normal HTTP traffic. But you can change the Port to a different number (for example 8080) or to a port number range so that the FortiGate unit provides web caching for HTTP traffic using other ports. Do not select Enable SSL. Enable SSL In this example SSL offloading is disabled. For an example of a reverse proxy Web Cache Only configuration that also includes SSL offloading, see Example: SSL offloading for a WAN optimization tunnel on page 124.
Transparent Mode Select Transparent Mode
4 Select OK. The rule is added to the bottom of the WAN optimization list. 5 If required, use the Move To icon to move the rule to a different position in the list. The order of the rules in the list significantly affects how the rules are applied. For more information, see How list order affects rule matching on page 46 and Moving a rule to a different position in the rule list on page 47.
Configuring Web Cache Only WAN optimization - CLI

Use the following steps to configure the example WAN optimization configuration from the FortiGate unit CLI. To add the firewall addresses and security policy 1 Add the firewall address for the client network:
79
Web caching
config firewall address edit Client_Net set type iprange set start-ip 172.20.120.0 set end-ip 172.20.120.255 end 2 Add the firewall address for the web server network: config firewall address edit Web_Server_Net set type iprange set start-ip 192.168.10.0 set end-ip 192.168.10.255 end 3 Add a security policy that accepts traffic to be web cached: config firewall policy edit 2 set srcintf port1 set dstintf port2 set srcaddr Client_Net set dstaddr Web_Server_Net set action accept set service HTTP set schedule always end end To add a Web Cache Only WAN optimization rule 1 Add the following Web Cache Only rule: config wanopt rule edit 2 set mode webcache-only set src-ip 172.20.120.0-172.20.120.255 set dst-ip 192.168.10.0-192.168.10.255 set port 80 set peer Peer_Fgt_2 end Accept default settings for transparent (enable), status (enable), ssl (disable), unknown-http-version (tunnel), and tunnel-non-http (disable). In this example, SSL offloading is disabled. For an example of a reverse proxy Web Cache Only configuration that also includes SSL offloading, see Example: SSL offloading for a WAN optimization tunnel on page 124. 2 If required, use the move command to move the rule to a different position in the list. The order of the rules in the list significantly affects how the rules are applied. For more information, see How list order affects rule matching on page 46 and Moving a rule to a different position in the rule list on page 47.
80
Web caching

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 user network you should be able to connect to this web server over the WAN optimization tunnel. If you can connect, check WAN optimization monitoring in WAN Opt. & Cache > Monitor > Monitor. If WAN optimization has been forwarding the traffic, the WAN optimization monitor should show the HTTP protocol that has been optimized and the reduction rate in WAN bandwidth usage. If you cannot connect, 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 UTM options. 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 user 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 user 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 on the client-side FortiGate unit to display WAN optimization tunnel protocol statistics. The http tunnel and tcp tunnel parts of the command output below shows that WAN optimization has been processing HTTP packets. If the http bytes in and bytes out fields are zero, then WAN optimization is not accepting HTTP packets. get test wad 11 wad tunnel protocol stats: http tunnel bytes_in=1749865 bytes_out=25926 ftp tunnel bytes_in=0 bytes_out=0 cifs tunnel bytes_in=0 bytes_out=0 mapi tunnel bytes_in=0 bytes_out=0 tcp tunnel bytes_in=0 bytes_out=0 maintenance tunnel bytes_in=0 bytes_out=0 You can use the following command to display information about the WAN optimization web cache daemon. The command will only display information if the web cache daemon is running and the statistics displayed show the number of open connections and other indications of activity: diagnose wacs stats Disk 0 /Internal-2B6375792136C707/wa_cs
81
Web caching for active-passive WAN optimization
Web caching
Current number of open connections: 2 Number of terminated connections: 7 Number of requests -- Adds: 206 (0 repetitive keys), Lookups: 860, Conflict incidents: 0 Percentage of missed lookups: 88.49 Communication is blocked for 0 client(s) Disk usage: 5196 KB (11%)

You add web caching support to the passive or server side of an active-passive WAN optimization configuration. Web pages are cached on the server-side FortiGate unit so you should also select Enable Byte Caching for optimum WAN optimization performance. For web caching to work, the WAN optimization tunnel must accept HTTP (and optionally HTTPS) traffic. To do this, the active rule on the client side must include the ports used for HTTP (and HTTPS) traffic. Set Protocol to HTTP to perform protocol optimization of the HTTP traffic. You can also enable SSL offloading and secure tunneling, as well as add an authentication group.
Example: Active-passive Web Caching

This example describes how to configure active-passive web caching for users in a client network connecting to a web server network across a WAN.

This example configuration includes a client-side FortiGate unit called Client_Side with a WAN IP address of 172.10.10.1 in front of a user network with IP address 172.20.120.0. The server-side FortiGate unit is called Server_Side and has a WAN IP address of 172.20.20.1. This server-side unit is in front of a web server network with IP address 192.168.10.0. Web caching is enabled on the server-side FortiGate unit.
82
Web caching
Figure 25: Example active-passive web cache topology

ork tw ne 20.0 er Us .20.1 2 17
IP 17 A 2. dd 10 re .1 ss 0. 1
WAN
eb W ca ch e
e e id ) id -S le TP S nt ru T t_ lie e H en C iv = li ct ol C (a oc D: t I ro st P o lH
IP 17 A 2. dd 20 re .2 ss 0. 1

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 by adding peers, a security policy that accepts traffic to be optimized, and an active WAN optimization rule. 2 Configure the server-side FortiGate unit by adding peers and a passive WAN optimization rule that includes web caching. If you perform any additional actions between procedures, your configuration may have different results.
Configuring active-passive web caching - web-based manager

Use the following steps to configure the example WAN optimization configuration from the client-side and server-side FortiGate unit web-based manager. (CLI steps follow.) To configure the client-side FortiGate unit 1 Go to WAN Opt. & Cache > WAN Opt. Peer > Peer and enter a Local Host ID for the client FortiGate unit: Local Host ID Client_Side
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 IP Address 4 Select OK.
Lo
ca
0 11 0 11 10 10 10
e id ) e de S le h i r- ru ac r_S ve e C e er iv b rv S s e e as W S (p le ID: b t na s E Ho l ca
Lo
o etw rn 0 rve .10. e b s 168 We 192.
rk
Server_Side 172.20.20.1
83
Web caching
5 Go to Policy > Policy > Policy and add a security policy that accepts traffic to be web cached: Source Interface/Zone Source Address Destination Interface/Zone Destination Address Schedule Service Action port1 all port2 all always ANY ACCEPT
6 Go to WAN Opt. & Cache > WAN Opt. Rule > Rule and select Create New. 7 Configure the rule: Mode Source Destination Port Auto-Detect Protocol Transparent Mode Full Optimization 172.20.120.* 192.168.10.* 1-65535 Active HTTP Select Transparent Mode
Enable Byte Caching Select Enable Byte Caching 8 Select OK. The rule is added to the bottom of the WAN optimization list. 9 If required, use the Move To icon to move the rule to a different position in the list. The order of the rules in the list significantly affects how the rules are applied. For more information, see How list order affects rule matching on page 46 and Moving a rule to a different position in the rule list on page 47. To configure the server-side FortiGate unit 1 Go to WAN Opt. & Cache > WAN Opt. Peer > Peer and enter a Local Host ID for the server-side FortiGate unit: Local Host ID Server_Side
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 IP Address Client_Side 172.10.10.1
4 Go to WAN Opt. & Cache > WAN Opt. Rule > Rule and select Create New.
84
Web caching
5 Configure the passive web cache rule: Mode Source Destination Port Auto-Detect Full Optimization 172.20.120.* 192.168.10.* 1-65535 Passive
Enable Web Cache Select 6 Select OK. The rule is added to the bottom of the WAN optimization rule list. 7 If required, use the Move To icon to move the rule to a different position in the list. For more information, see Moving a rule to a different position in the rule list on page 47.
Configuring active-passive web caching - CLI

Use the following steps to configure the example WAN optimization configuration from the client-side and server-side 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_Side end 2 Add the server-side Local Host ID to the client-side peer list: config wanopt peer edit Server_Side set ip 172.20.20.1 end 3 Add a security policy to the server-side FortiGate unit to accept the traffic to be optimized: config firewall policy edit 23 set srcintf port1 set dstintf port2 set srcaddr all set dstaddr all set action accept set service ANY set schedule always end end 4 Configure the following active rule: config wanopt rule edit 2 set auto-detect active set src-ip 172.20.120.0-172.20.120.255 set dst-ip 192.168.10.0-192.168.10.255 set port 1-65535
85
Web caching for peer-to-peer WAN optimization
Web caching
set proto http end Accept default settings for transparent (enable), status (enable), mode (full), byte-caching (enable), ssl (disable), secure-tunnel (disable), authgroup (null), unknown-http-version (tunnel), and tunnel-non-http (disable). 5 If required, use the move command to move the rule to a different position in the list. The order of the rules in the list significantly affects how the rules are applied. For more information, see How list order affects rule matching on page 46 and Moving a rule to a different position in the rule list on page 47. 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_Side end 2 Add the client-side Local Host ID to the server-side peer list: config wanopt peer edit Client_Side set ip 172.10.10.1 end 3 Add the following passive web cache rule: config wanopt rule edit 5 set auto-detect passive set src-ip 172.20.120.0-172.20.120.255 set dst-ip 192.168.10.0-192.168.10.255 set port 1-65535 set webcache enable end Accept default settings for status (enable) and mode (full). 4 If required, use the move command to move the rule to a different position in the list so that the tunnel request from the client-side FortiGate unit matches with this rule. For more information, see Moving a rule to a different position in the rule list on page 47.

In a peer-to-peer web caching configuration, you create a peer-to-peer WAN optimization rule on the client-side FortiGate unit and include the peer host ID of the server-side FortiGate unit. In the rule, you set Auto-Detect to Off and select Enable Web Cache. By using this rule, the client-side FortiGate unit can create a WAN optimization tunnel only with the peer that is added to the rule. In a peer-to-peer configuration, you do not have to add a rule to the server-side FortiGate unit. If the server-side FortiGate unit peer list contains the client FortiGate unit, the server FortiGate unit accepts WAN optimization tunnel connections from the client FortiGate unit and the two units can form a WAN optimization tunnel. The server-side FortiGate unit uses the settings in the rule added to the client-side FortiGate unit.
86
Web caching
For web caching to work, the WAN optimization tunnel must allow HTTP (and optionally HTTPS) traffic. To do this, the WAN optimization rule must include the ports used for HTTP (and HTTPS) traffic. Set Protocol to HTTP to perform protocol optimization of the HTTP traffic. You can also enable WAN optimization transparent mode, byte caching, SSL offloading, and secure tunneling, as well as add an authentication group.
Example: Peer-to-peer web caching

This example describes how to configure peer-to-peer web caching for users in a client network connecting to a web server network across a WAN.

This example configuration includes a client-side FortiGate unit called Client_Side with a WAN IP address of 172.10.10.1 in front of a user network with IP address 172.20.120.0 The server-side FortiGate unit is called Server_Side and has a WAN IP address of 172.20.20.1. This server-side unit is in front of a web server network with IP address 192.168.10.0. Web caching is enabled on the server-side FortiGate unit. Figure 26: Example peer-to-peer web cache topology
ork tw ne 20.0 er Us .20.1 2 17
IP 17 A 2. dd 20 re .3 ss 4. 12
WAN
eb W ca ch e
IP 19 A 2. dd 16 re 8. ss 30 .1 2

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 by adding peers, a security policy that accepts traffic to be optimized, and a peer-to-peer WAN optimization rule that includes web caching. 2 Configure the server-side FortiGate unit. Also note that if you perform any additional actions between procedures, your configuration may have different results.
e id ) -S le TP e de nt ru T ch Si lie e H a t_ C iv = C ct ol b ien (a oc e Cl t W : ro e D P abl t I n os E lH ca
Lo
0 11 0 11 10 10 10
Lo
e ) id id d S S ire r_ r- qu ve ve re er S er S ule D: r I o t (n os lH ca e
etw rn 0 rve .10. e b s 168 We 192.
ork
87
Web caching
Configuring peer-to-peer web caching - web-based manager

Use the following steps to configure the example WAN optimization configuration from the client-side and server-side FortiGate unit web-based manager. (CLI steps follow.) To configure the client-side FortiGate unit 1 Go to WAN Opt. & Cache > WAN Opt. Peer > Peer and enter a Local Host ID for the client FortiGate unit: Local Host ID Client_Side
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 IP Address 4 Select OK. 5 Go to Policy > Policy > Policy and add a security policy that accepts traffic to be web cached: Source Interface/Zone Source Address Destination Interface/Zone Destination Address Schedule Service Action port1 all port2 all always ANY ACCEPT Server_Side 192.168.30.12
6 Go to WAN Opt. & Cache > WAN Opt. Rule > Rule and select Create New. 7 Configure the rule: Mode Source Destination Port Auto-Detect Protocol Peer Enable Web Cache Transparent Mode Enable Byte Caching 8 Select OK. The rule is added to the bottom of the WAN optimization list. 9 If required, use the Move To icon to move the rule to a different position in the list. The order of the rules in the list significantly affects how the rules are applied. For more information, see How list order affects rule matching on page 46 and Moving a rule to a different position in the rule list on page 47.
Full Optimization 172.20.120.* 192.168.10.* 80 Off HTTP Server_Side Select Select Select
88
Web caching
To configure the server-side FortiGate unit 1 Go to WAN Opt. & Cache > WAN Opt. Peer > Peer and enter a Local Host ID for the server FortiGate unit: Local Host ID Server_Side
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 IP Address 4 Select OK. Client_Side 172.20.34.12
Configuring peer-to-peer web caching - CLI

Use the following steps to configure the example WAN optimization configuration from the client-side and server-side 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_Side end 2 Add the server-side Local Host ID to the client-side peer list: config wanopt peer edit Server_Side set ip 192.168.30.12 end 3 Add a security policy to the server-side FortiGate unit to accept the traffic to be optimized: config firewall policy edit 23 set srcintf port1 set dstintf port2 set srcaddr all set dstaddr all set action accept set service ANY set schedule always end end 4 Configure the following active rule: config wanopt rule edit 5 set auto-detect off set src-ip 172.20.120.* set dst-ip 192.168.10.* set port 80 set proto http set peer Server_Side set web cache enable
89
Exempting web sites from web caching
Web caching
end Accept default settings for transparent (enable), status (enable), mode (full), byte-caching (enable), ssl (disable), secure-tunnel (disable), authgroup (null), unknown-http-version (tunnel), and tunnel-non-http (disable). 5 If required, use the move command to the rule to a different position in the list. The order of the rules in the list significantly affects how the rules are applied. For more information, see How list order affects rule matching on page 46 and Moving a rule to a different position in the rule list on page 47. 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_Side end 2 Add the client-side Local Host ID to the server-side peer list: config wanopt peer edit Client_Side set ip 172.20.34.12 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. All traffic accepted by WAN optimization and the explicit web proxy for these websites will not be cached. You can add URLs and numeric IP addresses to the web cache exempt list. When enabled the web cache exempt list applies to web caching in security policies and in WAN optimization rules. Enter the following command to add www.example.com to the web cache exempt list. config wanopt webcache set cache-exemption enable config cache-exemption-list edit 1 set url-pattern www.example.com set status enable end end Enter the following command to enable the web cache exempt list and add two IP address URLs and a web page URL to the list. config wanopt webcache set explicit enable set cache-exemption enable config cache-exemption-list edit 1 set url-pattern "192.168.1.121" next edit 2 set url-pattern "google.com/test123/321"
90
Web caching
Changing web cache settings
next edit 3 set url-pattern "1.1.1.1" next end end You can also add URLs to the web cache exempt list by going to WAN Opt. & Cache > Cache > Exempt List. However, the web cache exempt feature must be enabled from the CLI.

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 > Cache > Settings. From the FortiGate CLI, you can use the config wanopt webcache command to change these WAN optimization web cache settings. For more information about many of these web cache settings, see RFC 2616.
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.
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.
91
Web caching
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).
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.
92
Web caching
Monitoring Web caching performance
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-nocache. 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.

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 WAN Opt. & Cache > Monitor > Cache Monitor.
93
Web caching
Figure 27: Web cache monitor
94
FortiOS Handbook

This chapter contains an advanced WAN optimization configuration example that combines many of the concepts described in the previous chapters of this document. The configuration example described here includes active-passive rules, web caching, policy routes for out-of-path WAN optimization, and multiple VDOMs with inter-VDOM routing to apply virus scanning (and optionally other UTM features) to traffic before it is optimized.
Out-of-path WAN optimization with inter-VDOM routing

This example describes how to configure out-of-path WAN optimization to optimize web browsing and FTP file transfers between a client network and a server network.

The client network connects to the Internet through a FortiGate-300A unit, and the server network connects to the Internet through a cluster of two FortiGate-1000A units. Adding in-path WAN optimization requires replacing these FortiGate units with models that support WAN optimization or adding new FortiGate units in the data path. In either of these in-path configurations, the optimizing FortiGate units would also be required to support all traffic on the data path plus provide WAN optimization. The out-of-path topology shown in Figure offloads WAN optimization to out-of-path FortiGate units that only process sessions to be optimized. The topology includes a FortiGate-311B unit installed at the client network and a single FortiGate-620B unit installed at the server network. The FortiGate-620B unit is installed at the server network because other client networks also use it for WAN optimization. The configuration for those other client networks is not described in this example. The client-side FortiGate-300A unit uses policy routing to offload WAN optimization of HTTP and FTP sessions by re-directing all HTTP and FTP sessions to the FortiGate-311B unit. The FortiGate-311B and 620B units work together to apply web caching, byte caching, and HTTP and FTP protocol optimization to HTTP and FTP sessions. The WAN optimization tunnel between the 311B and the 620B operates in Transparent mode. The FortiGate-311B unit also web caches all Internet HTTP traffic from the client network. The client-side FortiGate-311B unit also applies virus scanning (and optionally other UTM features) to the HTTP and FTP traffic. To do this, the FortiGate-311B unit is configured for multiple VDOM operation. A new VDOM named Wanopt is added to the FortiGate-311B. HTTP and FTP sessions are received by the root VDOM. Security policies in the root VDOM accept HTTP and FTP sessions and apply virus scanning (and optionally other UTM features) to them. To preserve the source addresses of the HTTP and FTP sessions, NAT is not enabled for these policies. The sessions are then routed through an inter-VDOM link to the Wanopt VDOM. The Wanopt VDOM includes security policies that accept the HTTP and FTP sessions and WAN optimization rules that apply WAN optimization and web caching to the sessions.
95
Figure 28: Out-of-path WAN optimization

ork etw t N 0.0 en 0.12 Cli 2.2 17
F or at tiG rt po 5 po 10 rt6 .1 0. 10 . 1 e30 0A
WAN
1 0. 4 .1 rt 1 0 2 po 2 . 0. 17 1 .1 rt 1 0 po 2 . 17
.1 po 0. r t 1 10 0 .2
10
po 10 rt2 .2 0. 20 .
po
rt 5 rt po 0.1 .2
1 20
The server-side FortiGate-620B unit includes a passive WAN optimization rule that accepts WAN optimization tunnel requests from the FortiGate-311B unit. Only one passive rule is required on the FortiGate-620B unit. The FortiGate-620B unit also forwards sessions to the server-side FortiGate-1000A cluster which forwards them to the server network. WAN optimization is operating in Transparent mode, so the packets from the client network include their client network source IP addresses. To preserve these source IP addresses, the security policies on the FortiGate-1000A cluster that accept the sessions from the FortiGate- 620B unit should not apply NAT. If the security policies were to apply NAT, the client network addresses would be replaced with the port1 IP address of the FortiGate-1000A cluster and the client network source IP addresses would be lost. The optimizing FortiGate units operate in NAT/Route mode and are directly connected to the Internet. This configuration requires two Internet connections and two Internet IP addresses for each network. (Reminder: All of the example IP addresses shown in Figure are private IP addresses because all Fortinet documentation examples use only private IP addresses.) If these extra Internet IP addresses are not available, you can install a router between the WAN and the FortiGate units or install the optimizing FortiGate units out of path on the private networks and configure routing on the private networks to route HTTP and FTP sessions to the optimizing FortiGate units.
Configuration steps
This example is divided into client-side and the server-side steps, as configured through the web-based manager and the CLI. Use either method, but for best results, follow the procedures in the order given. Also, note that if you perform any additional actions between procedures, your configuration may have different results. This example includes the following sections: Client-side configuration steps - web-based manager on page 97 Server-side configuration steps - web-based manager on page 104
Lo
F 1B t_ 31 en e- li at : C tiG ID or t F os lH ca gt
F A 00 10 e- r at s t e tiG lu or c
19 2. 19 2. 20 1 rt po 0.2
10 Lo ca
96
16 rt .2 po 20 0.
.2
.2
ork etw r n .0 ve 8.10 r Se 2.16 19
F 0B er_ 62 rv e- e at : S tiG ID or t F os lH gt
Client-side configuration steps - CLI on page 107 Server-side configuration steps - CLI on page 114
Client-side configuration steps - web-based manager

This section describes the configuration steps required to redirect HTTP and FTP sessions from the client-side FortiGate-300A unit and to configure the client-side FortiGate-311B unit to optimize HTTP and FTP sessions to the server network and to apply web caching to all other HTTP sessions from the client network. The section breaks down the client-side configuration into smaller procedures. For best results, follow the procedures in the order given: 1 Configure the FortiGate-300A unit to redirect all HTTP and FTP sessions to the FortiGate-311B unit. 2 Configure the FortiGate-311B unit for multiple VDOM operation and add an interVDOM link. 3 Configure routing for the FortiGate-311B root VDOM. 4 Add security policies to the FortiGate-311B root VDOM to accept HTTP and FTP sessions received at port1 and destined for Vlink0, and apply virus scanning (and optionally other UTM features). 5 Configure routing for the FortiGate-311B Wanopt VDOM. 6 Add security policies to the FortiGate-311B Wanopt VDOM to accept HTTP and FTP sessions received at the Vlink1 interface of the inter-VDOM link and destined for port10. 7 Configure peers for the FortiGate-311B Wanopt VDOM. 8 Add WAN optimization rules for HTTP and FTP to the FortiGate-311B Wanopt VDOM. Also note that if you perform any additional actions between procedures, your configuration may have different results. To configure the FortiGate-300A unit to redirect all HTTP and FTP sessions to the FortiGate-311B unit 1 Go to System > Network > Interface, edit port4, and set the port4 IP address to 172.10.10.1/24. 2 Go to Policy > Policy > Policy and select Create New to add a security policy that allows all port5 to port4 HTTP sessions: Source Interface/Zone Source Address Destination Interface/Zone Destination Address Schedule Service Action NAT port5 all port4 all always HTTP ACCEPT Select
Configure other policy settings that you may require.
97
3 Select Create New to add a security policy that allows all port5 to port4 FTP sessions: Source Interface/Zone Source Address Destination Interface/Zone Destination Address Schedule Service Action NAT port5 all port4 all always FTP ACCEPT Select
Configure other policy settings that you may require. 4 Select OK. 5 If required, use the Move To icon to change the order of the security policies. Follow the normal rules for ordering security policies in the policy list. For example, move specific rules above general rules. 6 Go to Router > Static > Policy Route and select Create New to add a policy route to redirect HTTP traffic received at port5 to exit the FortiGate unit using port4. Set the gateway address of the route to 172.10.10.2 so that the HTTP sessions are directed to the FortiGate-311B port1 interface. For HTTP traffic, the protocol is 6 (TCP) and the destination port is 80: Protocol Incoming interface Source address / mask Destination address / mask Destination Ports Type of Service Outgoing interface Gateway Address 7 Select OK. 8 Select Create New to add a policy route to redirect FTP traffic received at port5 to exit the FortiGate unit using port4. Set the gateway address of the route to 172.10.10.2 so that the HTTP sessions are directed to the FortiGate-311B port1 interface. For FTP traffic, the protocol is 6 (TCP) and the destination port is 21: Protocol Incoming interface Source address / mask Destination address / mask Destination Ports Type of Service 6 port5 0.0.0.0/0.0.0.0 0.0.0.0/0.0.0.0 From 21 to 21 bit pattern: 00 (hex) bit mask: 00 (hex) 6 port5 0.0.0.0/0.0.0.0 0.0.0.0/0.0.0.0 From 80 to 80 bit pattern: 00 (hex) bit mask: 00 (hex) port4 172.10.10.2
98
Outgoing interface Gateway Address 9 Select OK.
port4 172.10.10.2
To configure the FortiGate-311B unit for multiple VDOM operation and add an interVDOM link 1 Go to System > Status > Dashboard. 2 In the System Information widget, select Enable beside Virtual Domain to enable multiple VDOM operation and log back in to the web-based manager. 3 Go to System > VDOM and select Create New to add a new virtual domain named Wanopt. 4 Select OK twice to add the Wanopt VDOM with default resource limits. 5 Go to System > Network, edit the port10 interface, and configure the following settings to add the port10 interface to the Wanopt VDOM: Virtual Domain Addressing Mode IP/Netmask Wanopt Manual 10.10.10.2/24
Configure other settings that you may require. 6 Select OK. 7 Select Create New > VDOM Link and add an inter-VDOM link with the following settings: Name Interface #0 Virtual Domain IP/Netmask Interface #1 Virtual Domain IP/Netmask 8 Select OK. To configure routing for the FortiGate-311B root VDOM 1 Log in to the root VDOM. 2 Go to Router > Static and select Create New to add a default route. The destination of the default route is the inter-VDOM link interface in the root VDOM. The gateway of the default route is the IP address of the inter-VDOM link interface in the Wanopt VDOM. The result is the default route sends all traffic out the inter-VDOM link and into the Wanopt VDOM: Destination IP/Mask Device Gateway Distance 3 Select OK. 0.0.0.0/0.0.0.0 Vlink0 172.1.1.2 10 Wanopt 172.1.1.2/24 root 172.1.1.1/24 Vlink
99
4 Select Create New to add a route to send return traffic from the server network destined for the client network out the port1 interface to the port4 interface of the FortiGate-300A which has IP address 172.10.10.1: Destination IP/Mask Device Gateway Distance 5 Select OK. To add security policies to the FortiGate-311B root VDOM to accept HTTP and FTP sessions received at port1 destined for Vlink0 and apply virus scanning (and optionally other UTM features) 1 Log in to the root VDOM. 2 Go to Policy > Policy > Policy and select Create New to add a security policy that accepts HTTP sessions received at port1 destined for Vlink0 and applies virus scanning and other UTM features: Source Interface/Zone Source Address Destination Interface/Zone Destination Address Schedule Service Action NAT port1 all Vlink0 all always HTTP ACCEPT Do not select. To preserve the source addresses of the HTTP sessions, NAT should not be enabled for this policy. Select UTM, select a protocol options profile and select an antivirus profile. Optionally select other UTM profiles. 172.20.120.0/24 port1 172.10.10.1 10
UTM
Configure other policy settings that you may require. You can also use more specific security addresses or add one security policy that accepts both FTP and HTTP traffic. 3 Select OK.
100
4 Go to Policy > Policy > Policy and select Create New to add a security policy that accepts FTP sessions received at port1 and destined for Vlink0 and applies virus scanning and other UTM features to them: Source Interface/Zone Source Address Destination Interface/Zone Destination Address Schedule Service Action NAT port1 all Vlink0 all always FTP ACCEPT Do not select. To preserve the source addresses of the FTP sessions, NAT should not be enabled for this policy. Select UTM, select a protocol options profile and select an antivirus profile. Optionally select other UTM profiles.
UTM
Configure other policy settings that you may require. You can also use more specific security addresses or add one security policy that accepts both FTP and HTTP traffic. 5 Select OK. To configure routing for the FortiGate-311B Wanopt VDOM 1 Log in to the Wanopt VDOM. 2 Go to Router > Static and select Create New to add a default route. The destination of the default route is the port10 interface. The gateway of the default route is the next hop router that the port10 interface connects with: Destination IP/Mask Device Gateway Distance 3 Select OK. 4 Select Create New to add a route to send return traffic from the server network destined for the client network out the Vlink1 interface to the Vlink0 interface in the root VDOM, which has the IP address 172.1.1.2: Destination IP/Mask Device Gateway Distance 5 Select OK. To add security policies to the FortiGate-311B Wanopt VDOM to accept HTTP and FTP sessions received at the Vlink1 interface of the inter-VDOM link and destined for port10 1 Log in to the Wanopt VDOM. 172.20.120.0/24 Vlink1 172.1.1.2 10 0.0.0.0/0.0.0.0 port10 (next hop router IP address) 10
101
2 Go to Policy > Policy > Policy and select Create New to add a security policy that accepts HTTP sessions received at Vlink1 and destined for port10: Source Interface/Zone Vlink1 Source Address Destination Interface/Zone Destination Address Schedule Service Action all port10 all always HTTP ACCEPT Select NAT NAT is ignored for all HTTP sessions for the server network because these sessions are intercepted by a full optimization WAN optimization rule. However, HTTP sessions for the Internet are intercepted by the Web Cache Only rule, so source NAT is required for replies. Do not select. UTM Do not select UTM because you cannot apply UTM and WAN optimization to the same session in the same VDOM. UTM was applied to the session in the root VDOM.
Configure other settings that you may require. 3 Select OK. 4 Go to Policy > Policy > Policy and select Create New to add a security policy that accepts FTP sessions received at Vlink1 and destined for port10: Source Interface/Zone Vlink1 Source Address Destination Interface/Zone Destination Address Schedule Service Action all port10 all always FTP ACCEPT Select NAT NAT is ignored for all FTP sessions for the server network because these sessions are intercepted by a full optimization WAN optimization rule. However, FTP sessions for the Internet are allowed to reach their destination, so source NAT is required for replies. Do not select. UTM Do not select UTM because you cannot apply UTM and WAN optimization to the same session in the same VDOM. UTM was applied to the session in the root VDOM.
Configure other settings that you may require.
102
5 Select OK. To configure peers for the FortiGate-311B Wanopt VDOM 1 Log in to the Wanopt VDOM. 2 Go to WAN Opt. & Cache > WAN Opt. Peer > Peer and enter a Local Host ID for the client-side FortiGate-311B unit: Local Host ID Client_Fgt
3 Select Apply to save your setting. 4 Select Create New and add a Peer Host ID and the IP Address for the server-side FortiGate-620B unit: Peer Host ID IP Address 5 Select OK. To add WAN optimization rules for HTTP and FTP to the FortiGate-311B Wanopt VDOM 1 Log in to the Wanopt VDOM. 2 Go to WAN Opt. & Cache > WAN Opt. Rule > Rule. 3 Select Create New to add an active rule to optimize HTTP traffic from IP addresses on the Client network (172.20.120.0) with a destination address on the server network (192.168.10.0): Mode Source Destination Port Auto-Detect Protocol Transparent Mode Enable Byte Caching Enable SSL Enable Secure Tunnel Authentication Group 4 Select OK. 5 Select Create New to add an active rule to optimize FTP traffic from IP addresses on the Client network (172.20.120.0) with a destination address on the server network (192.168.10.0): Mode Source Destination Port Full Optimization 172.20.120.* 192.168.10.* 21 Full Optimization 172.20.120.* 192.168.10.* 80 Active HTTP Select Select Do not select. Do not select. For improved privacy you can select this option and add an authentication group to both optimizing FortiGate units. Do not select. Server_Fgt 10.20.20.2
103
Auto-Detect Protocol Transparent Mode Enable Byte Caching Enable SSL Enable Secure Tunnel Authentication Group 6 Select OK.
Active FTP Select Select Do not select. Do not select. For improved privacy you can select this option and add an authentication group to both optimizing FortiGate units. Do not select.
7 Select Create New to add a rule to web cache HTTP traffic from IP addresses on the Client network (172.20.120.0) with any destination address: Mode Source Destination Port Transparent Mode Enable SSL 8 Select OK. 9 If required, use the Move To icon to move the Web Cache Only rule below the full optimization HTTP and FTP rules in the list. The Web Cache Only rule should be below the full optimization rules because it will match all HTTP traffic and you need HTTP sessions with destination address 192.168.10.0 to match the full optimization HTTP rule. Web Cache Only 172.20.120.* 0.0.0.0 80 Select Do not select.
Server-side configuration steps - web-based manager

This section describes the configuration steps required for the server-side FortiGate620B unit to perform WAN optimization with the client-side FortiGate-311B unit and to send HTTP and FTP sessions to the server-side FortiGate-1000A cluster. This section also describes how to configure the FortiGate-1000A cluster to forward HTTP and FTP sessions from the client network to the server network. The section breaks down the client-side configuration into smaller procedures. For best results, follow the procedures in the order given: 1 Configure routing for the FortiGate-620B unit. 2 Configure peers for the server-side FortiGate-620B unit. 3 Add a passive WAN optimization rule to the server-side FortiGate-620B unit. 4 Configure the FortiGate-1000A cluster to accept HTTP and FTP connections at port5 and forward them out port1 to the server network. Also note that if you perform any additional actions between procedures, your configuration may have different results.
104
To configure routing for the FortiGate-620B unit 1 Go to Router > Static and select Create New to add a default route. The destination of the default route is the port16 interface. The gateway of the default route is the next hop router that the port16 interface connects with: Destination IP/Mask Device Gateway Distance 2 Select OK. 3 Select Create New to add a route to send traffic for the server network out port1 to the port5 interface of the FortiGate-1000A cluster, which has the IP address 192.20.20.1: Destination IP/Mask Device Gateway Distance 4 Select OK. To configure peers for the server-side FortiGate-620B unit 1 Go to WAN Opt. & Cache > WAN Opt. Peer > Peer and enter a Local Host ID for the server-side FortiGate-620B unit: Local Host ID Server_Fgt 192.168.10.0/24 port1 192.20.20.1 10 0.0.0.0/0.0.0.0 port16 (next hop router IP address) 10
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-311B unit: Peer Host ID IP Address 4 Select OK. To add a passive WAN optimization rule to the server-side FortiGate-620B unit You can add one passive WAN optimization rule to the server-side FortiGate-620B unit for both active rules on the FortiGate-311B unit. This rule can also allow the FortiGate620B to perform WAN optimization with other client-side devices as long as the required Peer Host IDs are added to the FortiGate-620B configuration and to the client-side configurations. 1 Go to WAN Opt. & Cache > WAN Opt. Rule > Rule and select Create New to add a passive rule that accepts any WAN optimization tunnel request: Mode Source Destination Full Optimization 0.0.0.0 192.168.10.* 1-65535 Port You can also use a narrower port range such as 21-80 or add two rules, one with port set to 80 and one with port set to 21. Client_Fgt 10.10.10.2
105
Auto-Detect Enable Web Cache 2 Select OK.
Passive Select
3 If required, use the Move To icon to move the rule to a different position in the list so that the tunnel request from the client-side FortiGate unit matches with this rule. For more information, see Moving a rule to a different position in the rule list on page 47. To configure the FortiGate-1000A cluster to accept HTTP and FTP connections at port5 and forward them out port1 to the server network 1 Go to Firewall Objects > Address and select Create New to add an address for the server network: Address Name Type Subnet / IP Range Interface 2 Select OK. 3 Go to Firewall Objects > Address and select Create New to add an address for the client network: Address Name Type Subnet / IP Range Interface 4 Select OK. 5 Go to Policy > Policy > Policy and select Create New to add a security policy that accepts HTTP sessions at port5 destined for port1 and the server network: Source Interface/Zone Source Address Destination Interface/Zone Destination Address Schedule Service port5 Client_Net port1 Server_Net always HTTP Client_Net Subnet / IP Range 172.20.120.* Any Server_Net Subnet / IP Range 192.168.10.* Any
106
Action
ACCEPT Do not select. WAN optimization is operating in Transparent mode so the packets from the client network include their client network source IP addresses. To preserve these source IP addresses the security policies on the FortiGate1000A cluster that accept the sessions from the FortiGate- 620B unit should not apply NAT. If the policies were to apply NAT, the client network addresses would be replaced with the port1 IP address of the FortiGate1000A cluster and the client network source IP addresses would be lost.
NAT
6 Select OK. 7 Go to Policy > Policy > Policy and select Create New to add a security policy that accepts FTP sessions at port5 destined for port1 and the server network: Source Interface/Zone Source Address Destination Interface/Zone Destination Address Schedule Service Action NAT 8 Select OK. port5 Client_Net port1 Server_Net always FTP ACCEPT Do not select As described above, selecting NAT would cause the loss of client network source IP addresses.
Client-side configuration steps - CLI

This section describes the configuration steps required to redirect HTTP and FTP sessions from the client-side FortiGate-300A unit and to configure the client-side FortiGate-311B unit to optimize HTTP and FTP sessions to the server network and to apply web caching to all other HTTP sessions from the client network. The section breaks down the client-side configuration into smaller procedures. For best results, follow the procedures in the order given: 1 Configure the FortiGate-300A unit to redirect all HTTP and FTP sessions to the FortiGate-311B unit. 2 Configure the FortiGate-311B unit for multiple VDOM operation and add an interVDOM link. 3 Configure routing for the FortiGate-311B root VDOM. 4 Add security policies to the FortiGate-311B root VDOM to accept HTTP and FTP sessions received at port1 and destined for Vink0, and apply virus scanning (and optionally other UTM features). 5 Configure routing for the FortiGate-311B Wanopt VDOM.
107
6 Add security policies to the FortiGate-311B Wanopt VDOM to accept HTTP and FTP sessions received at the Vlink1 interface of the inter-VDOM link and destined for port10. 7 Configure peers for the FortiGate-311B Wanopt VDOM. 8 .Add WAN optimization rules for HTTP and FTP to the FortiGate-311B Wanopt VDOM. Also note that if you perform any additional actions between procedures, your configuration may have different results. To configure the FortiGate-300A unit to redirect all HTTP and FTP sessions to the FortiGate-311B unit 1 Set the FortiGate-300A port4 IP address to 172.10.10.1: config system interface edit port4 set ip 172.10.10.1/24 end end 2 Add a security policy that allows all port5 to port4 HTTP sessions: config firewall policy edit 1 set srcintf port5 set dstintf port4 set srcaddr all set dstaddr all set action accept set service HTTP set schedule always set nat enable end end Configure other policy settings that you may require. For example, you could add virus scanning (and optionally other UTM features). 3 Add a security policy that allows all port5 to port4 FTP sessions: config firewall policy edit 2 set srcintf port5 set dstintf port4 set srcaddr all set dstaddr all set action accept set service FTP set schedule always set nat enable end end Configure other policy settings that you may require. 4 If required, use the move command to change the order of the policies in the policy list. Follow the normal rules for ordering security policies in the policy list. For example, move specific rules above general rules.
108
5 Add a policy route to redirect HTTP traffic received at port5 to exit the FortiGate unit using port4. Set the gateway address of the route to 172.10.10.2 so that the HTTP sessions are directed to the FortiGate-311B port1 interface. For HTTP traffic, the protocol is 6 (TCP) and the destination port is 80: config router policy edit 1 set protocol 6 set input-device port5 set output-device port4 set src 0.0.0.0/0.0.0.0 set dst 0.0.0.0/0.0.0.0 set start-port 80 set end port 80 set gateway 172.10.10.2 end end Accept default settings for tos (0x00) and tos-mask (0x00). 6 Add a policy route to redirect FTP traffic received at port5 to exit the FortiGate unit using port4. Set the gateway address of the route to 172.10.10.2 so that the FTP sessions are directed to the FortiGate-311B port1 interface. For FTP traffic, the protocol is 6 (TCP) and the destination port is 21: config router policy edit 1 set protocol 6 set input-device port5 set output-device port4 set src 0.0.0.0/0.0.0.0 set dst 0.0.0.0/0.0.0.0 set start-port 21 set end port 21 set gateway 172.10.10.2 end end Accept default settings for tos (0x00) and tos-mask (0x00). To configure the FortiGate-311B unit for multiple VDOM operation and add an interVDOM link 1 Enable multiple VDOM operation and log back in to the web-based manager: config system global set vdom-admin enable end 2 Log back in to the CLI. 3 Add a new virtual domain named Wanopt. config vdom edit Wanopt end 4 Add the port10 interface to the Wanopt VDOM: config global config system interface edit port10 set vdom Wanopt
109
set IP 10.10.10.2/24 end end 5 Add an inter-VDOM named Vlink and configure the Vlink0 and Vlink1 interfaces: config global config system vdom-link edit Vlink end config system interface edit Vlink0 set vdom root set ip 172.1.1.1/24 next edit Vlink1 set vdom Wanopt set ip 172.1.1.2/24 end end To configure routing for the FortiGate-311B root VDOM 1 Log in to the root VDOM from the CLI. 2 Add a default route. The destination of the default route is the inter-VDOM link interface in the root VDOM. The gateway of the default route is the IP address of the inter-VDOM link interface in the Wanopt VDOM. The result is the default route sends all traffic out the inter-VDOM link and into the Wanopt VDOM: config router static edit 1 set dst 0.0.0.0/0.0.0.0 set device Vlink0 set gateway 172.1.1.2 set distance 10 end 3 Add a route to send return traffic from the server network destined for the client network out the port1 interface to the port4 interface of the FortiGate-300A which has IP address 172.10.10.1: config router static edit 2 set dst 172.20.120.0/24 set device port1 set gateway 172.10.10.1 set distance 10 end To add security policies to the FortiGate-311B root VDOM to accept HTTP and FTP sessions received at port1 and destined for Vlink0 and apply virus scanning and optionally other UTM features) 1 Log in to the root VDOM from the CLI. 2 Add a security policy that accepts HTTP sessions received at port1 and applies virus scanning to them: config firewall policy edit 20
110
set set set set set set set set set set end
srcintf port1 dstintf Vlink0 srcaddr all dstaddr all action accept service HTTP schedule always utm-status enable profile-protocol-options default av-profile scan
To preserve the source addresses of the HTTP sessions, NAT should not be enabled for this policy. Configure other policy settings that you may require. You can also use more specific firewall addresses or add one security policy that accepts both FTP and HTTP traffic. 3 Add a security policy that accepts FTP sessions received at port1 and applies virus scanning to them: config firewall policy edit 20 set srcintf port1 set dstintf Vlink0 set srcaddr all set dstaddr all set action accept set service FTP set schedule always set utm-status enable set profile-protocol-options default set av-profile scan end To preserve the source addresses of the HTTP sessions, NAT should not be enabled for this policy. Configure other policy settings that you may require. You can also use more specific firewall addresses or add one security policy that accepts both FTP and HTTP traffic. To configure routing for the FortiGate-311B Wanopt VDOM 1 Log in to the Wanopt VDOM from the CLI. 2 Add a default route. The destination of the default route is the port10 interface. The gateway of the default route is the next hop router that the port10 interface connects with: config router static edit 1 set dst 0.0.0.0/0.0.0.0 set device port10 set gateway (next hop router IP address) set distance 10 end
111
3 Add a route to send return traffic from the server network destined for the client network out the Vlink1 interface to the Vlink0 interface in the root VDOM, which has the IP address 172.1.1.2: config router static edit 2 set dst 172.20.120.0/24 set device Vlink1 set gateway 172.1.1.2 set distance 10 end To add security policies to the FortiGate-311B Wanopt VDOM to accept HTTP and FTP sessions received at the Vlink1 interface of the inter-VDOM link destined for port10 1 Log in to the Wanopt VDOM from the CLI. 2 Add a security policy that accepts HTTP sessions received at Vlink1 and destined for port10: config firewall policy edit 20 set srcintf Vlink1 set dstintf port10 set srcaddr all set dstaddr all set action accept set service HTTP set schedule always set nat enable end NAT is ignored for all HTTP sessions for the server network because these sessions are intercepted by a full optimization WAN optimization rule. However, HTTP sessions for the Internet are intercepted by the Web Cache Only rule, so source NAT is required for replies. Do not enable UTM because you cannot apply UTM features and WAN optimization to the same session in the same VDOM. Virus scanning was applied to the session in the root VDOM. Configure other settings that you may require. 3 Go to Policy > Policy > Policy and select Create New to add a security policy that accepts FTP sessions received at Vlink1 and destined for port10: config firewall policy edit 20 set srcintf Vlink1 set dstintf port10 set srcaddr all set dstaddr all set action accept set service FTP set schedule always set nat enable end
112
NAT is ignored for all HTTP sessions for the server network because these sessions are intercepted by a full optimization WAN optimization rule. However, HTTP sessions for the Internet are intercepted by the Web Cache Only rule, so source NAT is required for replies. Do not enable UTM because you cannot apply UTM features and WAN optimization to the same session in the same VDOM. Virus scanning was applied to the session in the root VDOM. Configure other settings that you may require. To configure peers for the FortiGate-311B Wanopt VDOM 1 Log in to the Wanopt VDOM from the CLI. 2 Add the Local Host ID for the client-side FortiGate-311B unit: config wanopt settings set host-id Client_Fgt end 3 Add a Peer Host ID and the IP Address for the server-side FortiGate-620B unit. config wanopt peer edit Server_Fgt set ip 10.20.20.2 end To add WAN optimization rules for HTTP and FTP to the FortiGate-311B Wanopt VDOM 1 Log in to the Wanopt VDOM from the CLI. 2 Add an active rule to optimize HTTP traffic from IP addresses on the Client network (172.20.120.0) with a destination address on the server network (192.168.10.0): config wanopt rule edit 4 set auto-detect active set src-ip 172.20.120.0-172.20.120.255 set dst-ip 192.168.10.0-192.168.10.255 set port 80 set proto http end Accept default settings for transparent (enable), status (enable), mode (full), byte-caching (enable), ssl (disable), secure-tunnel (disable), authgroup (null), unknown-http-version (tunnel), and tunnel-non-http (disable). For improved privacy you can enable secure-tunnel and add an authentication group to both optimizing FortiGate units. 3 Add an active rule to optimize FTP traffic from IP addresses on the Client network (172.20.120.0) with a destination address on the server network (192.168.10.0): config wanopt rule edit 5 set auto-detect active
113
set set set set end
src-ip 172.20.120.0-172.20.120.255 dst-ip 192.168.10.0-192.168.10.255 port 21 proto ftp
Accept default settings for transparent (enable), status (enable), mode (full), byte-caching (enable), ssl (disable), secure-tunnel (disable), authgroup (null), unknown-http-version (tunnel), and tunnel-non-http (disable). For improved privacy you can enable secure-tunnel and add an authentication group to both optimizing FortiGate units. 4 Add a rule to web cache HTTP traffic from IP addresses on the Client network (172.20.120.0) with any destination address: config wanopt rule edit 6 set mode webcache-only set src-ip 172.20.120.0-172.20.120.255 set dst-ip 0.0.0.0 set port 80 set proto http end Accept default settings for transparent (enable), status (enable), ssl (disable), unknown-http-version (tunnel), and tunnel-non-http (disable). 5 If required, use the move command to move the Web Cache Only rule below the full optimization HTTP and FTP rules in the list. The Web Cache Only rule should be below the full optimization rules because it will match all HTTP traffic and you need HTTP sessions with destination address 192.168.10.0 to match the full optimization HTTP rule For more information, see Moving a rule to a different position in the rule list on page 47.
Server-side configuration steps - CLI

This section describes the configuration steps required for the server-side FortiGate620B unit to perform WAN optimization with the client-side FortiGate-311B unit and to send HTTP and FTP sessions to the server-side FortiGate-1000A cluster. This section also describes how to configure the FortiGate-1000A cluster to forward HTTP and FTP sessions from the client network to the server network. The section breaks down the client-side configuration into smaller procedures. For best results, follow the procedures in the order given: 1 Configure routing for the FortiGate-620B unit. 2 Configure peers for the server-side FortiGate-620B unit. 3 Add a passive WAN optimization rule to the server-side FortiGate-620B unit. 4 Configure the FortiGate-1000A cluster to accept HTTP and FTP connections at port5 and forward them out port1 to the server network. Also note that if you perform any additional actions between procedures, your configuration may have different results.
114
To configure routing for the FortiGate-620B unit 1 Add a default route. The destination of the default route is the port16 interface. The gateway of the default route is the next hop router that the port16 interface connects with: config router static edit 1 set dst 0.0.0.0/0.0.0.0 set device port16 set gateway (next hop router IP address) set distance 10 end 2 Add a route to send traffic for the server network out port1 to the port5 interface of the FortiGate-1000A cluster, which has the IP address 192.20.20.1: config router static edit 2 set dst 192.168.10.0/24 set device port1 set gateway 192.20.20.1 set distance 10 end To configure peers for the server-side FortiGate-620B unit 1 Add the Local Host ID for the server-side FortiGate-620B unit: config wanopt settings set host-id Server_Fgt end 2 Add a Peer Host ID and the IP Address for the client-side FortiGate-311B unit: config wanopt peer edit Client_Fgt set ip 10.10.10.2 end To add a passive WAN optimization rule to the server-side FortiGate-620B unit You can add one passive WAN optimization rule to the server-side FortiGate-620B unit for both active rules on the FortiGate-311B unit. This rule can also allow the FortiGate620B to perform WAN optimization with other client-side devices as long as the required Peer Host IDs are added to the FortiGate-620B configuration and to the client-side configurations. 1 Go to WAN Opt. & Cache > WAN Opt. Rule > Rule and select Create New to add a passive rule that accepts any WAN optimization tunnel request: config wanopt rule edit 5 set auto-detect passive set src-ip 0.0.0.0 set dst-ip 192.168.10.0-192.168.10.255 set port 1-65535 set webcache enable end
115
Accept default settings for status (enable) and mode (full). You can also use a narrower port range such as 21-80 or add two rules, one with port set to 80 and one with port set to 21. 2 If required, use the move command to move the rule to a different position in the list so that the tunnel request from the client-side FortiGate unit matches with this rule. For more information, see Moving a rule to a different position in the rule list on page 47. To configure the FortiGate-1000A cluster to accept HTTP and FTP connections at port5 and forward them out port1 to the server network 1 Add a firewall address for the server network: config firewall address edit Server_Net set type iprange set start-ip 192.168.10.0 set end-ip 192.168.10.255 end 2 Add a firewall address for the client network: config firewall address edit Client_Net set type iprange set start-ip 172.20.120.0 set end-ip 172.20.120.255 end 3 Go to Policy > Policy > Policy and select Create New to add an security policy that accepts HTTP sessions at port5 destined for port1 and the server network: config firewall policy edit 10 set srcintf port5 set dstintf port1 set srcaddr Client_Net set dstaddr Server_Net set action accept set service HTTP set schedule always end end WAN optimization is operating in Transparent mode so the packets from the client network include their client network source IP addresses. To preserve these source IP addresses, the security policies on the FortiGate-1000A cluster that accept the sessions from the FortiGate- 620B unit should not apply NAT. If the policies were to apply NAT, the client network addresses would be replaced with the port1 IP address of the FortiGate-1000A cluster and the client network source IP addresses would be lost.
116
4 Go to Policy > Policy > Policy and select Create New to add an security policy that accepts FTP sessions at port5 destined for port1 and the server network: config firewall policy edit 11 set srcintf port5 set dstintf port1 set srcaddr Client_Net set dstaddr Server_Net set action accept set service FTP set schedule always end end As described above, selecting NAT would cause the loss of the client network source IP addresses.
117
118
FortiOS Handbook

WAN optimization SSL offloading uses a FortiGate units FortiASIC SSL encryption/decryption engine to accelerate SSL performance. Most commonly SSL offloading is used accelerate the performance of a web server that secures communication using the HTTPS protocol. SSL offloading can be applied to WAN optimization configurations and reverse proxy web caching configurations. In a WAN optimization configuration where clients on a client network use HTTPS to communicate with a web server over a WAN optimization tunnel, you can use SSL offloading to decrypt HTTPS traffic before sending it through the WAN optimization tunnel. Decrypting the HTTPS traffic before it enters the tunnel allows WAN optimization to apply optimization techniques to the in the clear HTTP traffic. These techniques that would not be as effective with encrypted HTTPS traffic. When the optimized traffic leaves the WAN optimization tunnel it can either be forwarded as clear text HTTP traffic or it can be re-encrypted as HTTPS traffic before being sent to its destination. To forward clear text traffic, SSL offloading must be configured in half mode. To forward encrypted traffic, SSL offloading must be configured in full mode. In a half mode reverse proxy web caching SSL offloading configuration, the FortiGate unit intercepts HTTPS traffic from clients and decrypts it before sending it as HTTP clear text traffic to a web server. The HTTP clear text response from the web server is encrypted by the FortiGate unit and returned to the clients as encrypted HTTPS traffic. SSL offloading improves performance by offloading SSL processing from the web server. In a full mode reverse proxy web cache SSL offloading configuration, the FortiGate unit decrypts HTTPS traffic, applies web caching, and then re-encrypts the HTTPS traffic before forwarding it to the web server. You can also combine SSL offloading with other WAN optimization techniques such as HTTP protocol optimization, byte caching, and web caching to further enhance web server performance. You enable SSL offloading by selecting Enable SSL in a WAN optimization rule. You must also add SSL servers to support SSL offloading by using the CLI command config wanopt ssl-server. You must add one SSL server for each web server for which you are configuring SSL offloading. The SSL server configuration must include the destination IP address and port number of the HTTPS packets to be decrypted. The SSL server configuration also includes the SSL mode (full or half), the name of the HTTP server CA certificate used to decrypt and encrypt the traffic, the size of the Diffie-Hellman prime used in DHE-RSA negotiation, the relative strength of the encryption algorithms accepted during negotiation, the SSL/TLS versions to use, and the behavior regarding sending empty fragments to avoid a CBC IV attack. You load HTTP server CA certificate into the FortiGate unit as a local certificate and then add it to the SSL server configuration using the ssl-cert keyword. The certificate key size must be 1024 or 2048 bits. 4096-bit keys are not supported.
119
About SSL server full and half mode
SSL offload does not perform address or port translation. If your configuration requires address translation this must be configured at the security policy level using firewall virtual IPs. You can configure one WAN optimization rule to offload SSL encryption/decryption for multiple HTTP servers. To do this, you configure the WAN optimization rule source and destination addresses, so that the rule accepts packets destined for all of the HTTP servers for which you want offloading. Then you add one SSL server for each of the HTTP servers. This chapter describes: Example: SSL offloading for a WAN optimization tunnel Example: SSL offloading and reverse proxy web caching for an Internet web server using static one-to-one virtual IPs Example: SSL offloading and reverse proxy web caching for an Internet web server using a port forwarding virtual IP for HTTPS traffic

An SSL server configuration can operate in full mode or half mode. In full mode the SSL server performs both decryption and encryption of the HTTPS traffic. The full mode sequence is: HTTPS -> HTTP -> HTTPS HTTPS <- HTTP <- HTTPS In half mode, the SSL server 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. The half mode sequence is: HTTPS -> HTTP HTTPS <- HTTP
WAN optimization full mode SSL server configuration

As shown in Figure 29, in a WAN optimization full mode SSL server configuration, encrypted HTTPS packets received from a client network are decrypted into clear text HTTP packets that are sent over the WAN optimization tunnel to a server network. When the packets exit the tunnel they are re-encrypted and sent to the web server as HTTPS packets. HTTPS responses from the server are unencrypted before being sent across the tunnel and then re-encrypted before being returned to the clients.
120
Figure 29: WAN optimization full mode SSL server configuration

nt k lie r C two e N n io n at tio iz ra im u pt fig O on N C A l W ne n Tu
3 2 1
This full mode configuration is used when the traffic on both the client and server networks must be encrypted. This configuration enhances performance by allowing WAN optimization to apply HTTP optimization, byte caching, and web caching to the HTTP traffic in the WAN optimization tunnel.
WAN optimization half mode SSL server configuration

As shown in Figure 30, in a WAN optimization half mode SSL server configuration, encrypted HTTPS packets received from a client network are decrypted into clear text HTTP packets that are sent over the WAN optimization tunnel and forwarded to the server. HTTP responses from the server are sent across the tunnel and then re-encrypted before being returned to the clients.
E n S e P li T C T d H te fic p f ry ra nc T t l P T ne T H e un xt sid T Te In tion ar f i c a le f i z C a Tr tim p O N A W

3 2 1
r ve n er i o S at ) L ur e S g od S fi M on ll C Fu (
3 2 1
E nc e S rv P e T S T H ted fic p f ry Tra r
bS We
erv
er
121
Figure 30: WAN optimization half mode SSL server configuration

nt k lie r C two e N n io n at tio iz ra im u pt fig O on N C A l W ne n Tu
3 2 1
This half mode configuration is used when the traffic on the server network can be in clear text. This configuration enhances performance by accelerating SSL decryption and encryption and by allowing WAN optimization to apply HTTP optimization, byte caching, and web caching to the HTTP traffic in the WAN optimization tunnel.
Reverse proxy web cache full mode SSL server configuration

As shown in Figure 31, in a reverse proxy web cache full mode SSL server configuration, encrypted HTTPS packets received from a client network are decrypted into clear text HTTP packets that are cached and then re-encrypted and sent to the web server as HTTPS packets. HTTPS responses from the server are unencrypted and cached and then re-encrypted before being returned to the clients.
E S e P li T C T d H te fic p f r y ra nc T nt l P T ne T H e un xt s i d T Te In tion ar f i c a le f iz C Tra tim p O A W

3 2
r ve n er i o S at ) L ur de S g o S fi M on lf C Ha (
122
P T T H fic xt raf Te r T ar e le rv C Se
3 2
We
e bS
rve
Figure 31: Reverse proxy web cache full mode SSL server configuration
d an r h e ve n ac r io C Se r a t e ) e b SL g u o d W S fi M on ll C Fu (
3 2
This full mode configuration is used when the traffic on both the client and server networks must be encrypted. This configuration enhances performance by caching HTTP content.
Reverse proxy web cache half mode SSL server configuration

As shown in Figure 32, in a reverse proxy web cache half mode SSL server configuration, encrypted HTTPS packets received from a client network are decrypted into clear text HTTP packets that are cached and forwarded to the server. HTTP responses from the server are cached and then re-encrypted before being returned to the clients. Figure 32: Reverse proxy web cache half mode SSL server configuration
This half mode configuration is used when the traffic on the server network can be in clear text. This configuration enhances performance by accelerating SSL decryption and encryption and by applying web caching to the HTTP traffic.
E S e P li T C T d H te fic p f r y ra nc T nt T T H xt ts Te ke ar ac le p C
3 2 1
3 2
1
3 2 1
E nc ve P r T e T S H ed i c pt ff ry Tra r
bS We
erv
er
d an r he ve n ac r io C Se rat e) eb SL gu od W S fi M on lf C Ha (
E S e P li T C T d H te fic p f ry ra nc T nt
3 2
U ne r P e T S T d H te i c p f ry raf nc T ve r
We
e bS
rve
123
Example: SSL offloading for a WAN optimization tunnel

This example shows how to configure basic SSL offloading for a WAN optimization tunnel. This basic SSL offloading configuration can be applied to many network configurations.

In this example, clients on a client network use https://192.168.10.20 to browse to a web server. A WAN optimization rule with Auto-Detect set to Off on the client-side FortiGate unit accepts sessions from the clients with source addresses on the 172.20.120.0 network and with a destination address of 192.168.10.0 and a destination port of 443. In this rule, Enable Secure Tunnel is selected so that the tunnel is encrypted. To support the encrypted tunnel, the configuration also includes an authentication group with a preshared key. Both FortiGate units must have the same authentication group with the same pre-shared key. The server-side FortiGate unit includes an SSL server configuration with ip set to 192.168.10.20 and port to 443. The unit also includes the web server CA. Figure 33: SSL offloading WAN optimization configuration
ork etw t n 20.0 en 1 Cli .20. 2 17
.2
0.
12
0.
IP
:1
72
Lo
i ff aff e :o r id ct tT -s te ne nt e r_ lie od e C ut Us a : e: ID ul t R os lH c
ca
WAN
A C er rs rv e de se erv si r- eb _s ve W eb er d S an : W D er t I rv os se H L l S ca S Lo
IP
:1
92
.1 D ec ry pt ed tr fic af
68 fic af e tr th l e ed by n pt d tun ry te d ec c e D e t ot yp 3 pr cr en
1 2
.1
0.
When the client-side FortiGate unit accepts an HTTPS connection for 192.168.10.20, the SSL server configuration provides the information that the client-side unit needs to decrypt the traffic and send it in clear text across a WAN optimization tunnel to the server-side unit. The server-side unit then forwards the clear text packets to the web server.
E nc ry pt ed a Tr c ffi
3 2 1
3 2
IP:
r rve Se ) b 0 0 We ort 8 10.2 (p 68. 1 2. 19
124
The web server CA is not downloaded from the server side to the client-side FortiGate unit. Instead, the client-side FortiGate unit proxies the SSL parameters from the client side to the server side, which returns an SSL key and other required information to the client-side unit so that it can decrypt and encrypt HTTPS traffic. In this peer-to-peer configuration you do not need to add a WAN optimization rule to the server-side FortiGate unit as long as this server-side unit includes the peer host ID of the client-side FortiGate unit in its peer list. However, you can set Auto-Detect to Active on the client-side FortiGate unit and then add a passive rule to the server-side unit. In this example, you do not require the secure tunnel and the authentication group configurations, but they are included to show how to protect the privacy of the WAN optimization tunnel.Alternataively, you could configure a route-based IPsec VPN between the FortiGate units and use IPsec to protect the privacy of the WAN optimization tunnel. In this example, it is assumed that you have a local CA named Web_Server_Cert_1.crt stored in a file that you will import when you configure the server-side FortiGate unit.

This example is divided into client-side and server-side steps, as configured through the web-based manager, and with CLI instructions provided for CLI-only steps. For best results, follow the procedures in the order given. Also, note that if you perform any additional actions between procedures, your configuration may have different results. You also need access to the CLI to perform CLI-only steps.
Client-side configuration steps

To configure the client-side FortiGate unit 1 Go to WAN Opt. & Cache > WAN Opt. Peer > WAN Opt. Peer > Peer and enter a Local Host ID for the server-side FortiGate unit: Local Host ID User_net
2 Select Apply to save your setting. 3 Select Create New and add a Peer Host ID and the IP Address for the peer side FortiGate unit: Peer Host ID IP Address 4 Select OK. 5 Go to WAN Opt. & Cache > WAN Opt. Peer > Authentication Group and select Create New to add an authentication group named SSL_auth_grp to the client-side FortiGate unit. The authentication group includes a preshared key and the peer added in step 3. An authentication group with the same name and the same preshared key must also be added to the server-side FortiGate unit. This authentication group is required for the secure tunnel: Name Authentication Method Password Peer Acceptance SSL_auth_grp Pre-shared key <preshared_key> Specify Peer: Web_servers Web_servers 192.168.10.1
125
6 Select OK. 7 Go to WAN Opt. & Cache > WAN Opt. Rule > Rule and select Create New to add the WAN optimization rule: Mode Source Destination Port Auto-Detect Protocol Peer Transparent Mode Enable SSL Enable Secure Tunnel Authentication Group 8 Select OK. The rule is added to the bottom of the WAN optimization list. 9 If required, move the rule to a different position in the list. The order of the rules in the list significantly affects how the rules are applied. For more information, see How list order affects rule matching on page 46 and Moving a rule to a different position in the rule list on page 47. Full Optimization 172.20.120.* 192.168.10.* 443 Off HTTP Web_servers Select Select Select SSL_auth_grpa
Enable Byte Caching Select
Server-side configuration steps

To configure the server-side FortiGate unit 1 Go to WAN Opt. & Cache > WAN Opt. Peer > WAN Opt. Peer > Peer and enter a Local Host ID for the server-side FortiGate unit: Local Host ID Web_servers
2 Select Apply to save your setting. 3 Select Create New and add a Peer Host ID and the IP Address for the peer side FortiGate unit: Peer Host ID IP Address 4 Select OK. User_net 172.20.120.1
126
SSL offloading for WAN optimization and web caching Example: SSL offloading and reverse proxy web caching for an Internet web
5 Go to WAN Opt. & Cache > WAN Opt. Peer > Authentication Group and select Create New to add an authentication group named SSL_auth_grp to the server-side FortiGate unit. The authentication group includes a preshared key and the peer added to the serverside FortiGate unit in step 3: Name Authentication Method Password Peer Acceptance 6 Select OK. 7 Go to System > Certificates > Local Certificates and select Import to import the web servers CA. For Type, select Local Certificate. Select the Browse button to locate the file, Web_Server_Cert_1.crt. The certificate key size must be 1024 or 2048 bits. 4096-bit keys are not supported. 8 From the CLI, enter the following command to add the SSL server to the server-side FortiGate unit: config wanopt ssl-server edit example_server set ip 192.168.10.20 set port 443 set ssl-mode half set ssl-cert Web_Server_Cert_1 end Configure other ssl-server settings that you may require for your configuration. SSL_auth_grp Pre-shared key <pre-shared_key> Specify Peer: User_net
Example: SSL offloading and reverse proxy web caching for an Internet web server using static one-to-one virtual IPs
This section describes configuring SSL offloading for a reverse proxy Web Cache Only WAN optimization 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. For an example of this configuration see Example: SSL offloading and reverse proxy web caching for an Internet web server using a port forwarding virtual IP for HTTPS traffic on page 133.

In this configuration, clients on the Internet use HTTP and HTTPS to browse to a web server. The FortiGate unit intercepts the HTTP traffic and a Web Cache Only WAN optimization rule forwards the HTTP traffic to the web server. The FortiGate unit intercepts the HTTPS traffic and a different Web Cache Only WAN optimization rule with SSL offloading enabled decrypts the traffic before sending it to the web server. The FortiGate unit also caches HTTP and HTTPS pages from the web server. Replies to HTTPS sessions from the web server are encrypted by the FortiGate unit before returning to the web browsing clients.
127
SSL
In the Web Cache Only rules transparent mode is enabled because the FortiGate unit is performing NAT between the Internet and the HTTP server and the web server network is not configured to route Internet traffic between the FortiGate unit and the web server. 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: avoids the capital expense of additional web servers by increasing the capacity of existing servers serves more requests for static content from web servers serves more requests for dynamic content from web servers reduces operating expenses including the cost of bandwidth required to serve content accelerates the response time of web servers and of page download times to end users. 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 the clients it services. Unlike internal clients, external clients are not reconfigured to access the proxy server. Instead, the site URL routes the client to the FortiGate unit as if it were a web server. 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 also includes two Web Cache Only rules, one that accepts the HTTP traffic for web caching and one that accepts the HTTPS traffic for SSL offloading and web caching. You could instead add only one rule for both the HTTP and HTTPS traffic. For this example, it is also assumed 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 web server requests are 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 and HTTPS 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. WAN optimization receives the packets after the DNAT has occurred so the source address for the reverse proxy WAN optimization rules should be 172.10.20.30.
128
Figure 34: SSL offloading and reverse proxy web caching for an Internet web server using static one-to-one virtual IPs
ic 3 S ff 4 P ra 4 T T t T d or .1 H te P 10 p n . ry tio 68 nc a .1 E tin 82 es 1 D IP
3 2 1
IP he 3 V ac t 44 g tic C or in ta b P d S e or loa W f f d le of an ru SL ly S on ith w
) ed pt ry 3 nc 44 ne rt 0 (u Po 0.3 fic n .2 af tio 0 tr a .1 P tin 2 T s 7 T e 1 H D IP
.1 68 po .1 rt2 0. 1
IP :1
72
3 2
.1 p 0. or 20 t1 .2
3 2
3 2
IP :1
92

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.
Configuration steps - web-based manager

To configure the FortiGate unit as a reverse proxy web cache server 1 Go to Firewall Objects > Virtual IP > Virtual IP and 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): Name External Interface Type Source Address Filter External IP Address/Range Mapped IP Address/Range Port Forwarding Reverse_proxy_VIP port2 Static NAT Do not select. 192.168.10.1 172.10.20.30 Do not select.
0 fic 8 af rt Tr Po 0.1 1 P T n . T tio 8 H na .16 ti 2 es 19 D IP
IP he 0 V ac t 8 r tic C o ta b P S e for W d le an ru ly on
0 fic t 8 af r tr Po .30 0 P T n 2 T tio . H na .10 ti 2 es 17 D IP
TP r HT erve 443) t b S por We and 0.30 0 0.2 rt 8 2.1 po : 17 ( P I
129
SSL
2 Select OK to save your settings. 3 Go to Policy > Policy > 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 UTM features. Set the destination address to the virtual IP. You do not have to enable NAT. Source Interface/Zone Source Address Destination Interface/Zone Destination Address Schedule Service Action port2 all port1 Reverse_proxy_VIP always HTTP and HTTPS Select Multiple to select more than one service. ACCEPT
4 Select OK to save your settings. 5 Go to WAN Opt. & Cache > WAN Opt Rule > Rule and select Create New to add a Web Cache Only WAN optimization rule. Configure the rule to accept the HTTP traffic on port 80 accepted by the security policy: Mode Source Destination Port Transparent Mode Enable SSL 6 Select OK. The rule is added to the bottom of the WAN optimization list. 7 If required, move the rule to a different position in the list. The order of the rules in the list significantly affects how the rules are applied. For more information, see How list order affects rule matching on page 46 and Moving a rule to a different position in the rule list on page 47. Web Cache Only 0.0.0.0 172.10.20.30 You need to set Destination to the translated (DNATed) IP address (172.10.20.30). 80 Select Do not select
130
To configure the FortiGate unit for SSL offloading of HTTPS traffic The security policy added in the first procedure accepts HTTPS traffic so you do not have to add another one. 1 Go to WAN Opt. & Cache > WAN Opt Rule > Rule and select Create New to add a Web Cache Only WAN optimization rule. Configure the rule to accept the HTTPS traffic on port 443 accepted by the security policy: Mode Source Destination Port Enable SSL 2 Select OK. The rule is added to the bottom of the WAN optimization list. 3 If required, move the rule to a different position in the list. The HTTPS rule can be above or below the HTTP rule. The order of the rules in the list significantly affects how the rules are applied. For more information, see How list order affects rule matching on page 46 and Moving a rule to a different position in the rule list on page 47. To add an SSL server to offload SSL encryption and decryption for the web server 1 Go to System > Certificates > Local Certificates and select Import to import the web servers CA. For Type, select Local Certificate. Select the Browse button to locate the file Rev_Proxy_Cert_1.crt. The certificate key size must be 1024 or 2048 bits. 4096-bit keys are not supported. 2 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 wanopt 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 3 Configure other ssl-server settings that you may require for your configuration. Web Cache Only 0.0.0.0 172.10.20.30 You need to set Destination to the translated (DNATed) IP address (172.10.20.30). 443 Select.
Transparent Mode Select.
131
SSL
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. Do not select UTM features. 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 end 3 Enter the following command to add a Web Cache Only WAN optimization rule that accepts the HTTP traffic on port 80 accepted by the security policy. Set dst-ip to the translated (DNATed) IP address (172.10.20.30). config wanopt rule edit 0 set mode webcache-only set src-ip 0.0.0.0 set dst-ip 172.10.20.30 set port 80 set transparent enable set ssl disable end 4 If required, move the rule to a different position in the list. The order of the rules in the list significantly affects how the rules are applied. For more information, see How list order affects rule matching on page 46 and Moving a rule to a different position in the rule list on page 47. To configure the FortiGate unit for SSL offloading of HTTPS traffic The security policy added in the first procedure accepts HTTPS traffic so you do not have to add another one. 1 Enter the following command to add a Web Cache Only WAN optimization rule that accepts the HTTPS traffic on port 443 accepted by the security policy. Set dst-ip to the translated (DNATed) IP address (172.10.20.30).
132
config wanopt rule edit 0 set mode webcache-only set src-ip 0.0.0.0 set dst-ip 172.10.20.30 set port 443 set transparent enable set ssl enable end 2 If required, move the rule to a different position in the list. The HTTPS rule can be above or below the HTTP rule. The order of the rules in the list significantly affects how the rules are applied. For more information, see How list order affects rule matching on page 46 and Moving a rule to a different position in the rule list on page 47. To add an SSL server to offload SSL encryption and decryption for the web server 1 Place a copy of the web servers 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 servers 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 wanopt 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.
Example: SSL offloading and reverse proxy web caching for an Internet web server using a port forwarding virtual IP for HTTPS traffic
This section describes configuring SSL offloading for a reverse proxy Web Cache Only WAN optimization configuration using a static virtual IP (VIP) for HTTP traffic and a port forwarding virtual IP for HTTPS traffic. While the port forwarding configuration described in this example is commonly used, it also possible to use a static virtual IP that does not change the destination port. For an example of this configuration see Example: SSL offloading and reverse proxy web caching for an Internet web server using static one-toone virtual IPs on page 127.
133
Example: SSL offloading and reverse proxy web caching for an Internet web server using a port forwarding virtual IP for HTTPS

In this configuration, clients on the Internet use HTTP (on port 80) and HTTPS (on port 9443) to browse to a web server. The FortiGate unit intercepts the HTTP traffic and a Web Cache Only WAN optimization rule forwards the HTTP traffic to the web server. The FortiGate unit intercepts the HTTPS traffic and a different Web Cache Only WAN optimization rule with SSL offloading enabled decrypts the traffic before sending it to the web server. The FortiGate unit also caches pages from the web server. Replies to HTTPS sessions from the web server are encrypted by the FortiGate unit before returning to the web browsing clients. In the Web Cache Only WAN optimization rules, transparent mode is enabled because the FortiGate unit is performing NAT between the Internet and the HTTP server and the web server network is not configured to route Internet traffic between the FortiGate unit and the web server. 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: avoids the capital expense of additional web servers by increasing the capacity of existing servers serves more requests for static content from web servers serves more requests for dynamic content from web servers reduces operating expenses including the cost of bandwidth required to serve content accelerates the response time of web servers and of page download times to end users. 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 the clients it services. Unlike internal clients, external clients are not reconfigured to access the proxy server. Instead, the site URL routes the client to the FortiGate unit as if it were a web server. 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 also includes two Web Cache Only rules, one that accepts the HTTP traffic for web caching and one that accepts the HTTPS traffic for SSL offloading and web caching. For this example, it is also assumed that all HTTP traffic uses port 80 and all HTTPS traffic uses port 9443. (Since HTTPS traffic is received on the non-standard port of 9443 a security policy that accepts this traffic must have service set to ALL or you must add a custom service that matches traffic on port 9443. The example takes the custom service approach.) The FortiGate unit includes the web server CA and an SSL server configuration for IP address 172.10.20.30 and port to 8080. The name of the file containing the CA is Rev_Proxy_Cert_1.crt.
134
The destination address of incoming HTTP requests is translated to the IP address of the web server using a static NAT virtual IP that performs destination address translation (DNAT). The DNAT translates the destination address of the HTTP packets from 192.168.10.1 to 172.10.20.30 but does not change the destination port of the HTTP traffic. The destination address and port number of incoming HTTPS requests is translated to the IP address of the web server and to port 8080 using a port forwarding virtual IP that performs destination address translation (DNAT) and destination port translation (port forwarding). The DNAT translates the destination address of the packets from 192.168.10.1 to 172.10.20.30. Port forwarding changes the destination port number from 9443 to 8080. WAN optimization receives the packets after the address and port translation has occurred so the source address for the reverse proxy WAN optimization rules should be 172.10.20.30 and the source port should be 80 for the HTTP traffic and 8080 for the HTTPS traffic. Figure 35: SSL offloading and reverse proxy web caching for an Internet web server using a static virtual IP for HTTP traffic and a port forwarding virtual IP for HTTPS traffic
ic 3 S ff 4 P ra 4 T T 9 T d rt .1 H te Po 10 . p ry ion 68 nc t .1 E tina 82 es 1 D IP
3 2 1
) ed pt ry 80 nc 80 ne rt 0 (u Po 0.3 fic n .2 af io 0 tr at .1 1 P in 2 T t 7 T es 1 3 2 H D IP ng ) di 80 ar 0 0 w 8 he 8 or to ac 80 g t F 43 C rt in or 4 b o d P (9 We r P floa o IP d e f of V an rul SL ly h S on wit
IP
3 2
:1 0 fic 8 af rt Tr Po 0.1 1 P T n . T tio 8 H na .16 ti 2 es 19 D IP
92
.1
68 po .1 rt2 0. 1
IP
3 2
:1 0 fic t 8 af r tr Po .30 0 P T n 2 T tio . H na .10 ti 2 es 17 D IP

1
72
.1 p 0. or 20 t1 .2

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 for the HTTP traffic (port 80, static DNAT). 2 Configure the FortiGate unit as a reverse proxy web cache server with SSL offloading for HTTPS traffic (DNAT, port forwarding (9443 to 8080), SSL offloading).
IP he 0 V ac t 8 r tic C o ta b P S e for W d le an ru ly on
TP r ) HT erve 8080 S ort b We nd p 0.30 0 a .10.2 rt 8 72 (poIP: 1
135
Also note that if you perform any additional actions between procedures, your configuration may have different results.
Configuration steps - web-based manager

To configure the FortiGate unit as a reverse proxy web cache server for the HTTP traffic 1 Go to Firewall Objects > Virtual IP > Virtual IP and 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 the destination port): Name External Interface Type Source Address Filter External IP Address/Range Mapped IP Address/Range Port Forwarding 2 Select OK to save your settings. 3 Go to Policy > Policy > Policy and select Create New to add a port2 to port1 security policy that accepts HTTP traffic from the Internet. Do not select UTM features. Set the destination address to the virtual IP. You do not have to enable NAT. Source Interface/Zone Source Address Destination Interface/Zone Destination Address Schedule Service Action port2 all port1 Reverse_proxy_http_VIP always HTTP ACCEPT Reverse_proxy_http_VIP port2 Static NAT Do not select. 192.168.10.1 172.10.20.30 Do not select.
4 Select OK to save your settings. 5 Go to WAN Opt. & Cache > WAN Opt Rule > Rule and select Create New to add a Web Cache Only WAN optimization rule. Configure the rule to accept the HTTP traffic on port 80 accepted by the security policy: Mode Source Destination Port Web Cache Only 0.0.0.0 172.10.20.30 You need to set Destination to the translated (DNATed) IP address (172.10.20.30). 80
136
Transparent Mode Select Enable SSL 6 Select OK. The rule is added to the bottom of the WAN optimization list. 7 If required, move the rule to a different position in the list. The order of the rules in the list significantly affects how the rules are applied. For more information, see How list order affects rule matching on page 46 and Moving a rule to a different position in the rule list on page 47. To configure the FortiGate unit as a reverse proxy web cache server for the HTTPS traffic 1 Go to Firewall Objects > Virtual IP > Virtual IP and select Create New to add a port forwarding virtual IP that translates destination IP addresses from 192.168.10.1 to 172.10.20.30 and translates the destination port from 9443 to 8080: Name External Interface Type Source Address Filter External IP Address/Range Mapped IP Address/Range Port Forwarding Protocol External Service Port Map to Port Reverse_proxy_https_VIP port2 Static NAT Do not select. 192.168.10.1 172.10.20.30 Select TCP 9443 8080 Do not select
2 Select OK to save your settings. 3 Go to Firewall Objects > Service > Custom and select Create New to add a custom service for HTTPS on port 9443: Name Protocol Type Protocol Source Port (Low - High) Destination Port (Low High) HTTPS_9443 TCP/UDP/SCTP TCP 1 - 65535 9443 - 9443
4 Go to Policy > Policy > Policy and select Create New to add a port2 to port1 security policy that uses the custom service and accepts traffic from the Internet. Do not select UTM features. Set the destination address to the virtual IP. You do not have to enable NAT. Source Interface/Zone Source Address Destination Interface/Zone Destination Address port2 all port1 Reverse_proxy_https_VIP
137
Schedule Service Action
always HTTPS_9443 ACCEPT
5 Select OK to save your settings. 6 Go to WAN Opt. & Cache > WAN Opt Rule > Rule and select Create New to add a Web Cache Only WAN optimization rule. Configure the rule to accept the HTTPS traffic on port 8080, the as translated by the port forwarding virtual IP: Mode Source Destination Port Enable SSL 7 Select OK. The rule is added to the bottom of the WAN optimization list. 8 If required, move the rule to a different position in the list. The HTTPS rule can be above or below the HTTP rule. The order of the rules in the list significantly affects how the rules are applied. For more information, see How list order affects rule matching on page 46 and Moving a rule to a different position in the rule list on page 47. 9 Go to System > Certificates > Local Certificates and select Import to import the web servers CA. For Type, select Local Certificate. Select the Browse button to locate the file Rev_Proxy_Cert_1.crt. The certificate key size must be 1024 or 2048 bits. 4096-bit keys are not supported. 10 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 after being translated by the virtual IP (8080). The SSL server operates in half mode since it performs a single-step conversion (HTTPS to HTTP or HTTP to HTTPS). config wanopt ssl-server edit rev_proxy_server set ip 172.10.20.30 set port 8080 set ssl-mode half set ssl-cert Rev_Proxy_Cert_1 end 11 Configure other ssl-server settings that you may require for your configuration. Web Cache Only 0.0.0.0 172.10.20.30 You need to set Destination to the translated (DNATed) IP address (172.10.20.30). 8080 Select
Transparent Mode Select
138
Configuration steps - CLI

To configure the FortiGate unit as a reverse proxy web cache server for the HTTP traffic 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_http_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 traffic from the Internet. Do not select UTM features. 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_http_VIP set schedule always set service HTTP set action accept end 3 Enter the following command to add a Web Cache Only WAN optimization rule that accepts the HTTP traffic on port 80 accepted by the security policy. Set dst-ip to the translated (DNATed) IP address (172.10.20.30). config wanopt rule edit 0 set mode webcache-only set src-ip 0.0.0.0 set dst-ip 172.10.20.30 set port 80 set transparent enable set ssl disable end 4 If required, move the rule to a different position in the list. The order of the rules in the list significantly affects how the rules are applied. For more information, see How list order affects rule matching on page 46 and Moving a rule to a different position in the rule list on page 47. To configure the FortiGate unit as a reverse proxy web cache server for the HTTPS traffic 1 Enter the following command to add a port forwarding virtual IP that translates destination IP addresses from 192.168.10.1 to 172.10.20.30 and translates the destination port from 9443 to 8080:
139
config firewall vip edit Reverse_proxy_https_VIP set extintf port2 set type static-nat set port-forward enable set extip 192.168.10.1 set mappedip 172.10.20.30 set extport 9443 set mappedport 8080 end 2 Enter the following command to add a custom service for HTTPS on port 9443: config firewall service custom edit HTTPS_9443 set protocol TCP/UDP/SCTP set tcp_portrange 9443 end 3 Enter the following command to add a port2 to port1 security policy that uses the custom service and accepts traffic from the Internet. Do not select UTM features. 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_https_VIP set schedule always set service HTTPS_9443 set action accept end 4 Enter the following command to add a Web Cache Only WAN optimization rule that accepts the HTTPS traffic on port 443 accepted by the security policy. Set dst-ip to the translated (DNATed) IP address (172.10.20.30) and set port to the translated port (8080). config wanopt rule edit 0 set mode webcache-only set src-ip 0.0.0.0 set dst-ip 172.10.20.30 set port 8080 set transparent enable set ssl enable end 5 If required, move the rule to a different position in the list. The HTTPS rule can be above or below the HTTP rule. The order of the rules in the list significantly affects how the rules are applied. For more information, see How list order affects rule matching on page 46 and Moving a rule to a different position in the rule list on page 47. 6 Place a copy of the web servers CA (file name Rev_Proxy_Cert_1.crt) in the root folder of a TFTP server.
140
7 Enter the following command to import the web servers 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. 8 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 after being translated by the virtual IP (8080). The SSL server operates in half mode since it performs a single-step conversion (HTTPS to HTTP or HTTP to HTTPS). config wanopt ssl-server edit rev_proxy_server set ip 172.10.20.30 set port 8080 set ssl-mode half set ssl-cert Rev_Proxy_Cert_1 end 9 Configure other ssl-server settings that you may require for your configuration.
141
142
FortiOS Handbook

FortiClient WAN optimization works together with WAN optimization on a FortiGate unit to accelerate network traffic between a PC running version 4.0 or greater of the FortiClient application and a network behind a FortiGate unit. When a user of a PC with FortiClient WAN optimization enabled attempts to connect to network resources behind a server-side FortiGate unit, the FortiClient application automatically detects if WAN optimization is enabled on the FortiGate unit. If WAN optimization is detected and the FortiClient application can successfully negotiate a WAN optimization tunnel with the FortiGate unit, a WAN optimization tunnel starts. FortiClient WAN optimization includes protocol optimization settings selected in the FortiClient application and byte caching (byte caching is enabled by default in the FortiClient application and cannot be disabled). Web caching is applied if selected in the passive rule on the FortiGate unit that accepts FortiClient WAN optimization tunnel requests. This chapter describes how to configure the FortiClient application for WAN optimization and how to configure a FortiGate unit to accept WAN optimization tunnel requests from the FortiClient application. Figure 36: FortiClient WAN optimization topology
Configuring FortiClient WAN optimization

Configuring WAN optimization with the FortiClient application consists of enabling WAN optimization for the FortiClient application and configuring the FortiGate unit to accept WAN optimization tunnel requests from the FortiClient application.
R em lie tiC or F s e er ot us nt

io at iz tim ls op ne N n A tu W n
A W N op tim iz at io n
Pri va te tw Ne ork
143
Configuring FortiClient WAN optimization
FortiClient configuration steps

To configure WAN Optimization for the FortiClient application 1 From the FortiClient user interface, go to Status > WAN Optimization. 2 Select Enable WAN Optimization. 3 Enable the protocols to be optimized: HTTP (web browsing), CIFS (Windows file sharing), MAPI (Microsoft Exchange) and FTP (file transfers). 4 Set Maximum Disk Cache to 512, 1024, or 2048 MB. The default is 512 MB. If the PC hard disk can accommodate a larger cache, better optimization performance is possible. 5 Select Apply.
FortiGate unit configuration steps

To configure FortiClient WAN Optimization on the FortiGate unit Because PCs running the FortiClient application can have IP addresses that change often, it is usually not practical to add PCs running the FortiClient application to the WAN optimization peer list. Instead, a FortiGate unit that accepts WAN optimization tunnel requests from the FortiClient application should be configured to accept any peer (see Accepting any peers on page 35) by adding an authentication group named auth-fc with Peer acceptance set to Accept Any Peer. On the FortiGate unit, you also need to add a passive rule that includes source and destination addresses that will accept connections from the IP addresses of PCs running the FortiClient application. If these PCs can be anywhere on the Internet, the source address for this rule is 0.0.0.0. You can also use a more restrictive address range if the PCs running the FortiClient application have a restricted range of addresses. You do not need to add security policies to the FortiGate unit because it is on the server side of the WAN optimization tunnel. 1 Go to WAN Opt. & Cache > WAN Opt. Peer > Authentication Group and select Create New. 2 Configure the authentication group: Name Authentication Method Certificate Peer Acceptance 3 Select OK. 4 Go to WAN Opt. & Cache > WAN Opt. Rule > Rule and select Create New. 5 Configure a rule to accept FortiClient WAN optimization sessions: Mode Source Destination Port Auto-Detect 6 Select OK. Full Optimization 0.0.0.0 0.0.0.0 1-65535 Passive auth-fc Certificate Fortinet_Firmware Accept Any Peer
144
FortiOS Handbook

You can use the FortiGate explicit web proxy to enable explicit HTTP, and HTTPS proxying on one or more FortiGate interfaces. The explicit web proxy also supports proxying FTP sessions from a web browser and proxy auto-config (PAC) to provide automatic proxy configurations for explicit web proxy users. From the CLI you can also configure the explicit web proxy to support SOCKS sessions from a web browser. The explicit web and FTP proxies can be operating at the same time on the same or on different FortiGate interfaces. Web proxies are configured for each VDOM when multiple VDOMs are enabled.
In most cases you would configure the explicit web proxy for users on a network by enabling the explicit web proxy on the FortiGate interface connected to that network. Users on the network would configure their web browsers to use a proxy server for HTTP and HTTPS, FTP, or SOCKS and set the proxy server IP address to the IP address of the FortiGate interface connected to their network. Users could also enter the PAC URL into their web browser PAC configuration to automate their web proxy configuration using a PAC file stored on the FortiGate unit. Enabling the explicit web proxy on an interface connected to the Internet is a security risk because anyone on the Internet who finds the proxy could use it to hide their source address. If the FortiGate unit is operating in Transparent mode, users would configure their browsers to use a proxy server with the FortiGate unit management IP address. The web proxy receives web browser sessions to be proxied at FortiGate interfaces with the explicit web proxy enabled. The web proxy uses FortiGate routing to route sessions through the FortiGate unit to a destination interface. Before a session leaves the exiting interface, the explicit web proxy changes the source addresses of the session packets to the IP address of the exiting interface. When the FortiGate unit is operating in Transparent mode the explicit web proxy changes the source addresses to the management IP address. For more information about explicit web proxy sessions, see Explicit proxy sessions and user limits on page 163.
145
Figure 37: Example explicit web proxy topology
To allow all explicit web proxy traffic to pass through the FortiGate unit you can set the explicit web proxy default firewall proxy action to accept. However, in most cases you would want to use security policies to control explicit web proxy traffic and apply security features such as access control/authentication, UTM, and traffic logging. You can do this by keeping the default explicit web proxy security policy action to deny and then adding web-proxy security policies. You can also change the explicit web proxy default security policy action to accept and add explicit web proxy security policies. If you do this, sessions that match web-proxy security policies are processed according to the security policy settings. Connections to the explicit web proxy that do not match a web-proxy security policy are allowed with no restrictions or additional security processing. This configuration is not recommended and is not a best practice. Web-proxy security policies can selectively allow or deny traffic, apply authentication using identity-based policies, enable traffic logging, and use UTM options to apply virus scanning, web filtering, and DLP to explicit web proxy traffic. There are some limitations to the UTM features that can be applied to explicit web proxy sessions. See UTM features and the explicit web proxy on page 155. You cannot configure IPsec, SSL VPN, or Traffic shaping for explicit web proxy traffic. Security policies for the web proxy can only include firewall addresses not assigned to a FortiGate unit interface or with interface set to Any. (On the web-based manager you must set the interface to Any. In the CLI you must unset the associated-interface.) Authentication of explicit web proxy sessions uses HTTP authentication and can be based on the users source IP address or on cookies from the users web browser. For more information, see Explicit web proxy authentication on page 153. To use the explicit web proxy, users must add the IP address of a FortiGate interface on which the explicit web proxy is enabled and the explicit web proxy port number (default 8080) to the proxy configuration settings of their web browsers. On FortiGate units that support WAN optimization, you can also enable web caching for explicit web proxy sessions. This section describes: Explicit web proxy configuration overview Proxy chaining Explicit web proxy authentication UTM features and the explicit web proxy
146
it lic xy xp ro E p eb w
Pr iva t e eN tw ork
Explicit web proxy configuration overview
Web Proxy Services Example: users on an internal network browsing the Internet through the explicit web proxy with web caching, RADIUS authentication, web filtering and virus scanning Explicit proxy sessions and user limits Explicit web proxy configuration options

You can use the following general steps to configure the explicit web proxy. To enable the explicit web proxy - web-based manager 1 Go to System > Network > Explicit Proxy. Select Enable Explicit Web Proxy to turn on the explicit web proxy for HTTP and HTTPS traffic. You can also select FTP to enable the web proxy for FTP over HTTP sessions in a web browser (not an FTP client) and PAC to enable automatic proxy configuration. You can also optionally change the HTTP port that the proxy listens on (the default is 8080) and optionally specify different ports for HTTPS, FTP, and PAC. 2 Select Apply. The default explicit web proxy configuration has Default Firewall Policy Action set to Deny and requires you to add a security policy to allow access to the explicit web proxy. This configuration is recommended as a best practice because you can use security policies to control access to the explicit web proxy and also apply security features such as logging, UTM, and authentication (by adding identity-based policies). 3 Go to System > Network > Interface and select one or more interfaces for which to enable the explicit web proxy. Edit the interface configuration and select Enable Explicit Web Proxy. Enabling the explicit web proxy on an interface connected to the Internet is a security risk because anyone on the Internet who finds the proxy could use it to hide their source address. If you enable the proxy on such an interface make sure authentication is required to use the proxy. 4 Go to Policy > Policy > Policy and select Create New and set the Source Interface/Zone to web-proxy. You can add multiple web-proxy security policies.
147
5 Configure the security policy as required to accept the traffic that you want to be processed by the explicit web proxy. The source address of the policy should match client source IP addresses. The firewall address selected as the source address cannot be assigned to a FortiGate interface. The Interface field of the firewall address must be blank or it must be set to Any. The destination address of the policy should match the IP addresses of web sites that clients are connecting to. Usually the destination address would be all if proxying Internet web browsing. If Default Firewall Policy Action is set to Deny, traffic sent to the explicit web proxy that is not accepted by a web-proxy security policy is dropped. If Default Firewall Policy Action is set to Allow then all web-proxy sessions that dont match with a security policy are allowed. For example the following security policy allows users on an internal network to access the Internet through the wan1 interface of a FortiGate unit. Source Interface/Zone Source Address Destination Interface/Zone Destination Address Action web-proxy Internal_subnet wan1 all ACCEPT
6 You can select other security policy options as required. For example, you can apply UTM protection to web proxy sessions and log allowed web proxy traffic. 7 You can also select Enable Identity Based Policy to apply authentication to explicit web proxy sessions. 8 You can add multiple identity based policies to apply different authentication for different user groups and also apply different UTM and logging settings for different user groups. To enable the explicit web proxy - CLI
You must use the CLI to enable the explicit web proxy for VLAN interfaces.
1 Enter the following command to turn on the explicit web proxy for HTTP and HTTPS traffic. config web-proxy explicit set status enable end You can also enter the following command to enable the web proxy for FTP sessions in a web browser. config web-proxy explicit set ftp-over-http enable end The default explicit web proxy configuration has sec-default-action set to deny and requires you to add a security policy to allow access to the explicit web proxy.
148
2 Enter the following command to enable the explicit web proxy for the internal interface. config system interface edit internal set explicit-web-proxy enable end end 3 Use the following command to add a firewall address that matches the source address of users who connect to the explicit web proxy. config firewall address edit Internal_subnet set type iprange set start-ip 10.31.101.1 set end-ip 10.31.101.255 end The source address for a web-proxy security policy cannot be assigned to a FortiGate unit interface. 4 Use the following command to add a security policy that allows all users on the 10.31.101.0 subnet to use the explicit web proxy for connections through the wan1 interface to the Internet. config firewall policy edit 2 set srcintf web-proxy set dstintf wan1 set scraddr Internal_subnet set dstaddr all set action accept set identity-based enable set schedule always config identity-based-policy edit 1 set groups Internal_users set utm-status enable set profile-protocol-options default set av-profile Scan set logtraffic enable set schedule always set service ANY end end The firewall address selected as the source address cannot be assigned to a FortiGate unit interface. Either the field must be blank or it must be set to Any. 5 Use the following command to change global web proxy settings, for example to set the maximum request length for the explicit web proxy to 10: config web-proxy global set max-request-length 10 end
149
Proxy auto-config (PAC) configuration

A proxy auto-config (PAC) file defines how web browsers can choose a proxy server for receiving HTTP content. PAC files include the FindProxyForURL(url, host) JavaScript function that returns a string with one or more access method specifications. These specifications cause the web browser to use a particular proxy server or to connect directly. To configure PAC for explicit web proxy users, you can use the port that PAC traffic from client web browsers use to connect to the explicit web proxy. explicit web proxy users must configure their web browsers PAC proxy settings to use the PAC port.
PAC File Content

You can edit the default PAC file from the web-based manager or use the following command to upload a custom PAC file: config web-proxy explicit set pac-file-server-status enable set pac-file data <pac_file_str> end Where <pac_file_str> is the contents of the PAC file. Enter the contents of the PAC file. Enclose the PAC file text in quotes. You can copy the contents of a PAC text file and paste the contents into the CLI using this option. Enter the command followed by two sets of quotes then place the cursor between the quotes and paste the file content. The maximum PAC file size is 256 kbytes. If your FortiGate unit is operating with multiple VDOMs each VDOM has its own PAC file. The total amount of FortiGate memory available to store all of these PAC files 2 MBytes. If this limit is reached you will not be able to load any additional PAC files. You can use any PAC file syntax that is supported by your userss browsers. The FortiGate unit does not parse the PAC file. To use PAC, users must add an automatic proxy configuration URL (or PAC URL) to their web browser proxy configuration. The default PAC file URL is: http://<interface_ip>:<PAC_port_int>/<pac_file_str> For example, if the interface with the explicit web proxy has IP address 172.20.120.122, the PAC port is the same as the default HTTP explicit web proxy port (8080) and the PAC file name is proxy.pac the PAC file URL would be: http://172.20.120.122:8080/proxy.pac
From the CLI you can use the following command to display the PAC file urls:
get web-proxy explicit
Unknown HTTP version

You can select the action to take when the proxy server must handle an unknown HTTP version request or message. Set unknown HTTP version to Reject or Best Effort. Best Effort attempts to handle the HTTP traffic as best as it can. Reject treats known HTTP traffic as malformed and drops it. The Reject option is more secure.
Authentication realm
You can enter an authentication realm to identify the explicit web proxy. The realm can be any text string of up to 63 characters. If the realm includes spaces enclose it in quotes. When a user authenticates with the explicit web proxy the HTTP authentication dialog includes the realm so you can use the realm to identify the explicitly web proxy for your users.
150
Proxy chaining
Other explicit web proxy options

You can change the following explicit web proxy options as required by your configuration. The TCP port that web browsers use to connect to the explicit proxy for HTTP, HTTPS, FTP and PAC services. The default port is HTTP port, HTTPS 8080 for all services. By default HTTPS, FTP. and PAC use the port, FTP port, PAC same port as HTTP. You can change any of these ports as port required. Users configuring their web browsers to use the explicit web proxy should add the same port numbers to their browser configurations. Proxy FQDN Enter the fully qualified domain name (FQDN) for the proxy server. This is the domain name to enter into browsers to access the proxy server.
Max HTTP request Enter the maximum length of an HTTP request in Kbytes. Larger length requests will be rejected. Max HTTP message length Add headers to Forwarded Requests Client IP Header Via Header X-forwarded-for Header Front-end HTTPS Header Enter the maximum length of an HTTP message in Kbytes. Larger messages will be rejected. The web proxy server will forward HTTP requests to the internal network. You can include the following headers in those requests: Enable to include the Client IP Header from the original HTTP request. Enable to include the Via Header from the original HTTP request. Enable to include the X-Forwarded-For (XFF) HTTP header. The XFF HTTP header identifies the originating IP address of a web client or browser that is connecting through an HTTP proxy, and the remote addresses it passed through to this point. Enable to include the Front-end HTTP Header from the original HTTPS request.
Proxy chaining
For the explicit web proxy you can configure web proxy forwarding servers to use proxy chaining to redirect web proxy sessions to other proxy servers. Proxy chaining can be used to forward web proxy sessions from the FortiGate unit to one or more other proxy servers on your network or on a remote network. You can use proxy chaining to integrate the FortiGate explicit web proxy with an already existing web proxy solution. A FortiGate unit can forward sessions to most web proxy servers including a remote FortiGate unit with the explicit web proxy enabled. No special configuration of the explicit web proxy on the remote FortiGate unit is required. You can deploy the explicit web proxy with proxy chaining in an enterprise environment consisting of small satellite offices and a main office. If each office has a FortiGate unit, users at each of the satellite offices can use their local FortiGate unit as an explicit web proxy server. The satellite office FortiGate units can forward explicit web proxy sessions to an explicit web proxy server at the central office. From here the sessions can connect to web servers on the Internet. FortiGate proxy chaining does not support authenticating with the remote forwarding server.
151
Proxy chaining
Adding a web proxy forwarding server

You add forwarding servers from the web-based manager by going to System > Network > Explicit Proxy and adding them. For each server you can define its address as a numeric IP address or fully qualified domain name. You can also specify the TCP port to use to connect to the proxy server. Use the following CLI command to add a web proxy forwarding server named fwd-srv at address proxy.example.com and port 8080. config web-proxy forward-server edit fwd-srv set addr-type fqdn set fqdn proxy.example.com set port 8080 end
Web proxy forwarding server monitoring and health checking

By default, a FortiGate unit monitors web proxy forwarding server by forwarding a connection to the remote server every 10 seconds. If the remote server does not respond it is assumed to be down. Checking continues and when the server does send a response the server is assumed to be back up. If you configure health checking, every 10 seconds the FortiGate unit attempts to get a response from a web server by connecting through the remote forwarding server. You can configure health checking for each remote server and specify a different website to check for each one. If the remote server is found to be down you can configure the FortiGate unit to block sessions until the server comes back up or to allow sessions to connect to their destination, bypassing the remote forwarding server. You cannot configure the FortiGate unit to fail over to another remote forwarding server. Configure the server down action and enable health monitoring from the web-based manager by going to System > Network > Explicit Proxy, selecting a forwarding server, and changing the server down action and changing the health monitor settings. Use the following CLI command to enable health checking for a web proxy forwarding server and set the server down option to bypass the forwarding server if it is down. config web-proxy forward-server edit fwd-srv set healthcheck enable set monitor http://example.com set server-down-option pass end
Adding proxy chaining to an explicit web proxy security policy

You enable proxy chaining for web proxy sessions by adding a web proxy forwarding server to an explicit web proxy security policy. In a policy you can select one web proxy forwarding server. All explicit web proxy traffic accepted by this security policy is forwarded to the specified web proxy forwarding server. To add an explicit web proxy forwarding server - web-based manager 1 Go to Policy > Policy > Policy and select Create New.
152
Explicit web proxy authentication
2 Configure the security policy: Source Interface/Zone Source Address Destination Interface/Zone Destination Address Schedule Service Action Web Proxy Forwarding Server web-proxy Internal_subnet wan1 all always webproxy ACCEPT Select, fwd-srv
3 Select OK to save the security policy. To add an explicit web proxy forwarding server - CLI 1 Use the following command to add a security policy that allows all users on the 10.31.101.0 subnet to use the explicit web proxy for connections through the wan1 interface to the Internet. The policy forwards web proxy sessions to a remote forwarding server named fwd-srv config firewall policy edit 2 set srcintf web-proxy set dstintf wan1 set scraddr Internal_subnet set dstaddr all set action accept set schedule always set service webproxy set webproxu-forward-server fwd-srv end

You can add identity-based policies to apply authentication to explicit web proxy sessions. You can use authentication to control access to the explicit web proxy. You can also use identity-based policies to identify users and apply different UTM features to different users. Authentication of web proxy sessions uses HTTP basic and digest authentication as described in RFC 2617 (HTTP Authentication: Basic and Digest Access Authentication) and prompts the user for credentials from the browser allowing individual users to be identified by their web browser instead of IP address. HTTP authentication allows the FortiGate unit to identify multiple users accessing services from a shared IP address. You can also select IP-based authentication to authenticate users according to their source IP address.
153
IP-Based authentication
IP-based authentication applies authentication by source IP address. Once a user authenticates, all sessions to the explicit web proxy from that IP address are assumed to be from that user and are accepted until the authentication timeout ends or the session times out. This method of authentication is similar to standard (non-web proxy) firewall authentication and may not produce the desired results if multiple users share IP addresses (such as in a network that uses virtualization solutions or includes a NAT device between the users and the explicit web proxy). To configure IP-based authentication, add a security policy for the explicit web proxy, set the source interface/zone to web-proxy, select Enable Identify Based Policy, and make sure IP Based is selected before adding identity-based policies. You can also set the authentication method to basic, digest, NTLM or FSAE. Use the following CLI command to add IP-based authentication to a web proxy security policy. IP-based authentication is selected by setting ip-based to enable. config firewall policy edit 3 set srcintf web-proxy set dstintf port1 set scraddr User_network set dstaddr all set action accept set identity-based enable set ip-based enable config identity-based-policy edit 1 set groups Internal_users set service ANY set schedule always end end
Per session authentication

If you dont select IP Based the FortiGate unit applies HTTP authentication per session. This authentication is browser-based (see Figure 38 on page 155). When a user enters a user name and password in their browser to authenticate with the explicit web proxy, this information is stored by the browser in a session cookie. Each new session started by the same web browser uses the session cookie for authentication. When the session cooke expires the user has to re-authenticate. If the user starts another browser on the same PC or closes and then re-opens their browser they have to authenticate again. Since the authentication is browser-based, multiple clients with the same IP address can authenticate with the proxy using their own credentials. HTTP authentication provides authentication for multiple user sessions from the same source IP address. This can happen if there is a NAT device between the users and the FortiGate unit. HTTP authentication also supports authentication for other configurations that share one IP address among multiple users. These includes Citrix products and Windows Terminal Server and other similar virtualization solutions. To configure per session authentication, add a security policy for the explicit web proxy, set the source interface/zone to web-proxy, select Enable Identify Based Policy, and make sure IP Based is not selected before adding identity-based policies. You can also set the authentication method to basic, digest, NTLM or FSAE.
154
UTM features and the explicit web proxy
Use the following CLI command to add per session authentication to a security policy. Per session authentication is selected by setting ip-based to disable. config firewall policy edit 5 set srcintf web-proxy set dstintf port1 set scraddr User_network set dstaddr all set action accept set identity-based enable set ip-based disable config identity-based-policy edit 1 set groups Internal_users set service ANY set schedule always end end Figure 38: Per session HTTP authentication
User
Web Browser
1. User Starts New Session
FortiGate E li it proxy tiG t Explicit
2. Web Browser Starts New Session with Explicit Proxy
4. Web Browser Prompts the User to Authenticate
3. Explicit Web Proxy Requests Authentication
5. User Enters Credentials 6. Web Browser Stores Credentiats as a session cookie 7. Web browser sends session cookie to Explicit Proxy
8. User Starts Another New Session
9. Web Browser Starts New Session with Explicit Proxy
10. Explicit Web Proxy gets authenticaiton credentials from session cookie

You can apply protocol options, antivirus, web filtering, FortiGuard Web Filtering and data leak prevention (DLP) including DLP archiving to explicit web proxy sessions. UTM features are applied by selecting them in a web proxy security policy or an identity based policy in a web proxy security policy. You cannot apply intrusion protection (IPS), email filtering, application control, or VoIP UTM features to explicit web proxy sessions.
155
To apply intrusion protection to explicit web proxy traffic you can add DoS policies to the FortiGate interfaces that receive and send explicit web proxy traffic. However, you cannot apply application control to explicit web proxy traffic, so you cannot filter explicit web proxy traffic by application and explicit web proxy traffic does not contribute to application control monitoring or reporting.
Explicit web proxy sessions and flow-based scanning

Flow-based scanning cannot be applied to explicit web proxy sessions. This includes: IPS Application control Flow-based virus scanning Flow-based web filtering Flow-based FortiGuard web filtering Flow-based Data leak prevention (DLP)
Explicit web proxy sessions and protocol options

Since the traffic accepted by the explicit web proxy is known to be either HTTP, HTTPS, or FTP over HTTP and since the ports are already known by the proxy, the explicit web proxy does not use the HTTP or HTTPS port protocol options settings. When adding UTM features to a web proxy security policy, you must select a protocol options profile. In most cases you can select the default protocol options profile. You could also create a custom protocol options profile. The explicit web proxy supports the following protocol options: Enable chunked bypass HTTP oversized file action and threshold The explicit web proxy does not support the following protocol options: Client comforting Server comforting Monitor content information from dashboard. URLs visited by explicit web proxy users are not added to dashboard usage and log and archive statistics widgets.
Explicit web proxy sessions web filtering and FortiGuard web filtering
For explicit web proxy sessions, the FortiGate unit applies web filtering to an HTTP request when it receives the headers of the request. If web filtering allows the HTTP request, it is forwarded to the web server. If web filtering blocks the HTTP request is, the request is dropped and a blocking HTTP response is generated by the FortiGate unit and returned to the client web browser. The explicit web proxy completely supports all web filtering and FortiGuard web filtering options and their configuration settings. The web page displayed when FortiGuard Web Filtering blocks a web page through the explicit web proxy may be different than the page displayed through a normal firewall session.
Explicit web proxy sessions and HTTPS deep scanning

HTTPS explicit web proxy sessions are subject to web filtering and FortiGuard web filtering if you select HTTPS scanning in the web filtering profile applied to the explicit web proxy HTTPS sessions.
156
Web Proxy Services
However, HTTPS deep scanning (also called SSL content scanning and inspection) is not supported for explicit web proxy HTTPS sessions. This means that web filtering of HTTPS sessions will only be done based on the URL in the session certificate. The following features are also not supported for explicit web proxy HTTPS sessions: Virus scanning Data leak prevention (DLP) Enabling deep scanning in a protocol options profile
Explicit web proxy sessions and antivirus

For explicit web proxy sessions, the FortiGate unit applies antivirus scanning to HTTP POST requests and HTTP responses. The FortiGate unit starts virus scanning a file in an HTML session when it receives a file in the body of an HTML request. The explicit web proxy can receive HTTP responses from either the originating web server or the FortiGate web cache module. Flow-based virus scanning is not available for explicit web proxy sessions. Even if the FortiGate unit is configured to use flow-based antivirus, explicit web proxy sessions use the regular virus database.
Web Proxy Services

Use the Web Proxy Service menu to configure multiple web proxy services for the web proxy feature. Web proxy services can only be selected in a security policy when webproxy is selected as the source interface. Web proxy services are similar to standard firewall services. You can configure web proxy services to define one or more protocols and port numbers that are associated with each web proxy service. Web proxy services can also be grouped into web proxy service groups. The following are web proxy service configuration settings in Firewall Objects > Service > Web Proxy Service. Name Protocol Source Port Low High Low High Enter a name for the web proxy service. Select a protocol from the drop-down list. Enter the low and high source ports. Enter the lowest source port. Enter the highest source port. Enter the lowest destination port. Enter the highest destination port.
Destination Port Enter the low and high destination ports.
157
Example: users on an internal network browsing the Internet through the explicit web proxy with web caching, RADIUS
Web Proxy Service Groups

In Firewall Objects > Service > Web Proxy Service Group, you can configure groups of web proxy services. By using service groups, you can efficiently apply several web proxy services to a security policy. This feature is applicable only when web-proxy is selected as the source interface in a security policy. Group Name Available Services Enter the name of the group. The web proxy services that can be members of the group. Select a web proxy service and use the -> arrow to move it to Members. Repeat for each service that you want to be a member in the group. The members of a group. Members To remove a member from Members, select the service and then use the <- arrow to move it back to Available Services.
Example: users on an internal network browsing the Internet through the explicit web proxy with web caching, RADIUS authentication, web filtering and virus scanning
This example describes how to configure the explicit web proxy for the example network shown in Figure 39. In this example, users on the internal network connect to the explicit web proxy through the Internal interface of the FortiGate-51B unit. The explicit web proxy is configured to use port 8888 so users must configure their web browser proxy settings to use port 8888 and IP address 10.31.101.100. Figure 39: Example explicit web proxy network topology
0.
12
r ve er 0 S 20 S 1. IU 0 D .1 A 1 R 0.3 1
w 17 a n 2. 1 20 .1 2
in 10 ter .3 na 1. l 10 1. 1 eb xy W ro r P 00 se r s .1 U se ting 01 w t 8 ro e .1 8 B S .31 88 0 rt: :1 o IP P
00 B y 51 ox e- p r e at b th ce e tiG w on rfa or i t F lic led inte xp ab l E n a E ern t In
two Ne te 01.0 va 1 Pri 0.31. 1
rk
158
Example: users on an internal network browsing the Internet through the explicit web proxy with
In this example, explicit web proxy users must authenticate with a RADIUS server before getting access to the proxy. To apply authentication, the security policy that accepts explicit web proxy traffic includes an identity based policy that applies per session authentication to explicit web proxy users and includes a user group with the RADIUS server in it. The identity based policy also applies UTM web filtering and virus scanning.

This section breaks down the configuration for this example into smaller procedures. For best results, follow the procedures in the order given: 1 Enable the explicit web proxy for HTTP and HTTPS and change the HTTP and HTTPS ports to 8888. 2 Enable the explicit web proxy on the internal interface. 3 Add a RADIUS server and user group for the explicit web proxy. 4 Add web filtering and antivirus profiles for the explicit web proxy. 5 Add a security policy for the explicit web proxy. Enable web caching in the security policy. Add an identity based policy to the security policy to support authentication. Enable antivirus, web filter, and DLP UTM features for the identity-based policy.
Configuring the explicit web proxy - web-based manager

Use the following steps to configure the explicit web proxy from FortiGate web-based manager. To enable and configure the explicit web proxy - web-based manager 1 Go to System > Network > Explicit Proxy and change the following settings: Enable Explicit Web Proxy Listen on Interfaces HTTP Port HTTPS Port Realm Default Firewall Policy Action 2 Select Apply. To enable the explicit web proxy on the Internal interface - web-based manager 1 Go to System > Network > Interface. 2 Edit the internal interface. 3 Select Enable Explicit Web Proxy. 4 Select OK. To add a RADIUS server and user group for the explicit web proxy - web-based manager 1 Go to User > Remote > RADIUS. Select HTTP/HTTPS. No change. This field will eventually show that the explicit web proxy is enabled for the Internal interface. 8888 8888 You are authenticating with the explicit web proxy. Deny
159
2 Select Create New to add a new RADIUS server: Name Type Primary Server Name/IP Primary Server Secret RADIUS_1 Query 10.31.101.200 RADIUS_server_secret
3 Go to User > User Group > User Group and select Create New. Name Type Members 4 Select OK. To add a security policy for the explicit web proxy - web-based manager 1 Go to Firewall Objects > Address > Address and select Create New. 2 Add a firewall address for the internal network: Address Name Type Interface Internal_subnet Subnet / IP Range Any Explict_proxy_user_group Firewall RADIUS_1
Subnet / IP Range 10.31.101.[1-255]
3 Go to Policy > Policy > Policy and select Create New. 4 Configure the explicit web proxy security policy. Source Interface/Zone Source Address Destination Interface/Zone Destination Address Action web-proxy Internal_subnet wan1 all ACCEPT
5 Select Enable web cache to enable web caching for the explicit web proxy. 6 Select Enable Identity Based Policy, make sure IP Based is not selected and Auth Method is set to Basic. 7 Select Add and configure the following settings for the identity based policy: User Group Service UTM Enable Antivirus Enable Web Filter Enable DLP Sensor Protocol Options Explicit_policy webproxy Select default default default default
You can also create custom antivirus, web filter, and DLP profiles instead of using the defaults. 8 Select OK.
160
Example: users on an internal network browsing the Internet through the explicit web proxy with
Configuring the explicit web proxy - CLI

Use the following steps to configure the example explicit web proxy configuration from the CLI. To enable the explicit web proxy on the Internal interface - CLI 1 Enter the following command to enable the explicit web proxy on the internal interface. config system interface edit internal set explicit-web-proxy enable end To enable and configure the explicit web proxy - CLI 1 Enter the following command to enable the explicit web proxy and set the TCP port that proxy accepts HTTP and HTTPS connections on to 8888. config web-proxy explicit set status enable set http-incoming-port 8888 set https-incoming-port 8888 set realm "You are authenticating with the explicit web proxy" set sec-default-action deny end To add a RADIUS server and user group for the explicit web proxy - CLI 1 Enter the following command to add a RADIUS server: config user radius edit RADIUS_1 set server 10.31.101.200 set secret RADIUS_server_secret end 2 Enter the following command to add a user group for the RADIUS server. config user group edit Explicit_proxy_user_group set group-type firewall set member RADIUS_1 end To add a security policy for the explicit web proxy - CLI 1 Enter the following command to add a firewall address for the internal subnet: config firewall address edit Internal_subnet set type iprange set start-ip 10.31.101.1 set end-ip 10.31.101.255 end 2 Enter the following command to add the explicit web proxy security policy: config firewall policy edit 0 set srcintf web-proxy
161
set dstintf wan1 set srcaddr Internal_subnet set dstaddr all set action accept set schedule always set webcache enable set identity-based enable set ipbased disable set auth-method basic config identity-based-policy edit 1 set groups Explicit_Proxy_user_group set schedule always set service explicit-web set utm-status enable set av-profile Explicit_av_pro set webfilter-profile Explicit_wf_pro set dlp-sensor default set profile-protocol-options default end end

You can use the following steps to verify that the explicit web proxy configuration is working as expected: To test the explicit web proxy configuration 1 Configure a web browser on the internal subnet to use a web proxy server at IP address 10.31.101.100 and port 8888. 2 Browse to an Internet web page. The web browser should pop up an authentication window that includes the phrase that you added to the Realm option. 3 Enter the username and password for an account on the RADIUS server. If the account is valid you should be allowed to browse web pages on the Internet. 4 Close the browser and clear its cache and cookies. 5 Restart the browser and connect to the Internet. You could also start a second web browser on the same PC. Or you could start a new instance of the same browser as long as the browser asks for a user name and password again. You should have to authenticate again because identity-based policies are set to session-based authentication. 6 If this basic functionality does not work, check your FortiGate and web browser configuration settings. 7 Browse to a URL on the URL filter list and confirm that the web page is blocked. 8 Browse to http://eicar.org and attempt to download an anti-malware test file. The antivirus configuration should block the file. Sessions for web-proxy security policies do not appear on the Top Sessions dashboard widget and the count column for security policies does not display a count for explicit web proxy security policies.
162
Explicit proxy sessions and user limits
9 You can use the following command to display explicit web proxy sessions get test wad 60 IP based users: Session based users: user:0x9c20778, username:User1, vf_id:0, ref_cnt:9 Total allocated user:1 Total user count:3, shared user quota:50, shared user count:3 This command output shows one explicit proxy user with user name User1 authenticated using session-based authentication.

Web browsers and web servers open and close multiple sessions with the explicit web proxy. Some sessions open and close very quickly. HTTP 1.1 keepalive sessions are persistent and can remain open for long periods of time. Sessions can remain on the explicit web proxy session list after a user has stopped using the proxy (and has, for example, closed their browser). If an explicit web proxy session is idle for more than 3600 seconds it is torn down by the explicit web proxy. See RFC 2616 for information about HTTP keepalive/persistent HTTP sessions. This section describes proxy sessions and user limits for both the explicit web proxy and the explicit FTP proxy. Session and user limits for the two proxies are counted and calculated together. However, in most cases if both proxies are active there will be many more web proxy sessions than FTP proxy sessions. The FortiGate unit adds two sessions to its session table for every explicit proxy session started by a web browser and every FTP session started by an FTP client. An entry is added to the session table for the session from the web browser or client to the explicit proxy. All of these sessions have the same destination port as the explicit web proxy port (usually 8080 for HTTP and 21 for FTP). An entry is also added to the session table for the session between the exiting FortiGate interface and the web or FTP server destination of the session. All of these sessions have a FortiGate interface IP address and the source address of the session and usually have a destination port of 80 for HTTP and 21 for FTP. Proxy sessions that appear in the Top sessions dashboard widget do not include the Policy ID of the web-proxy or ftp-proxy security policy that accepted them. However, the explicit proxy sessions appear in the Top Sessions dashboard widget with a destination port that matches the explicit proxy port number (usually 8080 for the web proxy and 21 for the FTP proxy). The proxied sessions from the FortiGate unit have their source address set to the IP address of the FortiGate unit interface that the sessions use to connect to their destinations (for example, for connections to the Internet the source address would be the IP address of the FortiGate interface connected to the Internet). FortiOS limits the number of explicit proxy users. This includes both explicit FTP proxy and explicit web proxy users. The number of users varies by FortiGate model from as low as 10 to up to 18000 for high end models. You can use the following command to display the limit on the number of explicit web proxy users for a FortiGate unit: get test wad 62 Total user count:1, shared user quota:500, shared user count:1 form_auth_keepalive=0 vd=root max=0 guarantee=0 used=1
163
This command output shows that the explicit proxy user limit (the shared user quota) for this FortiGate unit is 500 users. You cannot change this limit. If your FortiGate unit is configured for multiple VDOMs this limit must be shared by all VDOMs. You can also use VDOM resource limiting to limit the number of explicit proxy users for the FortiGate unit and for each VDOM. To limit the number of explicit proxy users for the FortiGate unit from the web-based manager enable multiple VDOMs and go to System > VDOM > Global Resources set the number of Concurrent explicit proxy users or use the following command: config global config system resource-limits set proxy 50 end end To limit the number of explicit proxy users for a VDOM, from the web-based manager enable multiple VDOMs and go to System > VDOM > VDOM and edit a VDOM or use the following command to change the number of explicit web proxy users for VDOM_1: config global config system vdom-property edit VDOM_1 set proxy 25 end end The VDOM resource limit pages on the web-based manager also display the current number of explicit web proxy users. You can also use the get test wad 60 CLI command to view the number of explicit web proxy users. For example: get test wad 60 IP based users: user:0x9ab8350 username:User1, vf_id:0, ip_addr:10.31.101.10, ref_cnt:9 Session based users: user:0x9ac3c40, username:User2, vf_id:0, ref_cnt:3 user:0x9ab94f0, username:User3, vf_id:0, ref_cnt:1 Total allocated user:3 Total user count:3, shared user quota:50, shared user count:3 Users may be displayed with this command even if they are no longer actively using the proxy. All idle sessions time out after 3600 seconds. The command output shows three explicit proxy users. The user named User1 has authenticated with a security policy that includes IP-based authentication and the users source IP address is 10.31.101.10. The users named User2 and User3 have authenticated with a security policy that includes session-based authentication. You can use the following command to flush all current explicit proxy users. This means delete information about all users and force them re-authenticate. get test wad 61 Users that authenticate with explicit web-proxy or ftp-proxy security policies do not appear in the User > Monitor > Firewall list and selecting De-authenticate All Users has no effect on explicit proxy users.
164
Explicit web proxy configuration options
How the number of concurrent explicit proxy users is determined depends on their authentication method: For session-based authenticated users, each authenticated user is counted as a single user. Since multiple users can have the same user name, the proxy attempts to identify users according to their authentication membership (based upon whether they were authenticated using RADIUS, LADAP, FSAE, local database etc.). If a user of one session has the same name and membership as a user of another session, the explicit proxy assumes this is one user. For IP Based authentication, or no authentication, or if no web-proxy security policy has been added, the source IP address is used to determine a user. All sessions from a single source address are assumed to be from the same user. The explicit proxy does not limit the number of active sessions for each user. As a result the actual explicit proxy session count is usually much higher than the number of explicit web proxy users. If an excessive number of explicit web proxy sessions is compromising system performance you can limit the amount of users if the FortiGate unit is operating with multiple VDOMs.

Use the explicit web proxy to enable explicit HTTP and HTTPS proxying on one or more Fortinet interfaces. The explicit web proxy also supports proxying FTP sessions sent from a web browser and proxy auto-config (PAC) to provide automatic proxy configurations for explicit web proxy users. From the CLI, you can also configure the explicit web proxy to support SOCKS sessions sent from a web browser. See Explicit web proxy configuration overview on page 147. To configure the explicit web proxy, go to System > Network > Explicit Proxy > Explicit Web Proxy Options: For explicit FTP proxy options, see Explicit FTP proxy options on page 182.
Explicit Web Proxy Options

Use the following options to configure the explicit web proxy. Enable Explicit Web Proxy Enable the explicit web proxy server for HTTP/ HTTPS, FTP and proxy auto-config PAC sessions. You must select this option for the explicit web proxy to accept and forward packets. FTP and PAC is only supported from a web browser and not a standalone client. Displays the interfaces that are being monitored by the explicit web proxy. If VDOMs are enabled, only interfaces that belong to the current VDOM and have explicit web proxy enabled will be displayed. If you enable the web proxy on an interface that has VLANs on it, the explicit web proxy will not be enabled for those VLAN interfaces. You must use the CLI to enable the explicit proxy for VLAN interfaces.
Listen on Interfaces
165
HTTP Port HTTPS Port FTP Port PAC Port
Enter the port number that traffic from client web browsers use to connect to the explicit proxy for the specific protocol. Explicit proxy users must configure their web browsers protocols proxy settings to use this port. The default value of 0 means use the same port as the configured HTTP port. Select the Edit icon to change the contents in a PAC file, or import a PAC file. The maximum PAC file size is 8192 bytes. You can use any PAC file syntax that is supported by your userss browsers. The FortiGate unit does not parse the PAC file. To use PAC, users must add an automatic proxy configuration URL (or PAC URL) to their web browser proxy configuration. The default PAC file URL is:
PAC File Content http://<interface_ip>:<PAC_port_int>/<pac_file_str> For example, if the interface with the explicit web proxy has IP address 172.20.120.122, the PAC port is the same as the default HTTP explicit proxy port (8080) and the PAC file name is proxy.pac the PAC file URL would be: http://172.20.120.122:8080/proxy.pac From the CLI you can use the following command to display the PAC file url: get web-proxy explicit Proxy FQDN Max HTTP request length Max HTTP message length Unknown HTTP version Enter the fully qualified domain name (FQDN) for the proxy server. This is the domain name to enter into browsers to access the proxy server. Enter the maximum length of an HTTP request. Larger requests will be rejected. Enter the maximum length of an HTTP message. Larger messages will be rejected. Select the action to take when the proxy server must handle an unknown HTTP version request or message. Best Effort attempts to handle the HTTP traffic as best as it can. Reject treats known HTTP traffic as malformed and drops it.
166
Realm
Enter an authentication realm to identify the explicit web proxy. The realm can be any text string of up to 63 characters. If the ream includes spaces enclose the name in quotes. When a user authenticates with the explicit proxy the HTTP authentication dialog includes the realm so you can use the realm to identify the explicitly web proxy for your users. Configure the explicit web proxy to block (deny) or accept sessions if security policies have note been added for the explicit web proxy. To add security policies for the explicit web proxy add a security policy and set the source interface to web-proxy. The default setting (or Deny) blocks access to the explicit web proxy before adding a security policy. If you set this option to Accept the explicit web proxy server accepts sessions even if you havent defined a security policy.
Default Firewall Policy Action
Web Proxy Forwarding Servers Options

Use the following options to configure web proxy forwarding servers. Create New Service Name Address Port Health Check Server Down Ref. Select to create a new forwarding server. The name of the forwarding server. The IP address of the forwarding server. The port number of the forwarding server. Indicates whether the health check is disabled or enabled for that forwarding server. A green checkmark indicates health check is enabled; a gray x indicates that health check is disabled. The action that the FortiGate unit will taken when the server is down. Displays the number of times the object is referenced to other objects.
Adding Web Proxy Forwarding Servers

To add a forwarding server, select Create New in the Web Proxy Forwarding Servers section of the Explicit Proxy page by going to System > Network > Explicit Proxy. Server Name Proxy Address Proxy Address Type Port Server Down action Enable Health Monitor Health Check Monitor Site Enter the name of the forwarding server. Enter the IP address of the forwarding server. Select the type of IP address of the forwarding server. A forwarding server can have an FQDN or IP address. Enter the port number. Select what action the FortiGate unit will take if the forwarding server is down. Select to enable health check monitoring. Enter the URL address of the health check monitoring site.
167
168
FortiOS Handbook

You can use the FortiGate explicit FTP proxy to enable explicit FTP proxying on one or more FortiGate interfaces. The explicit web and FTP proxies can be operating at the same time on the same or on different FortiGate interfaces. Explicit FTP proxies are configured for each VDOM when multiple VDOMs are enabled.
In most cases you would configure the explicit FTP proxy for users on a network by enabling the explicit FTP proxy on the FortiGate interface connected to that network. Users on the network would connect to and authenticate with the explicit FTP proxy before connecting to an FTP server. In this case the IP address of the explicit FTP proxy is the IP address of the FortiGate interface on which the explicit FTP proxy is enabled. Enabling the explicit FTP proxy on an interface connected to the Internet is a security risk because anyone on the Internet who finds the proxy could use it to hide their source address. If the FortiGate unit is operating in Transparent mode, users would configure their browsers to use a proxy server with the FortiGate unit management IP address. The FTP proxy receives FTP sessions to be proxied at FortiGate interfaces with the explicit FTP proxy enabled. The FTP proxy uses FortiGate routing to route sessions through the FortiGate unit to a destination interface. Before a session leaves the exiting interface, the explicit FTP proxy changes the source addresses of the session packets to the IP address of the exiting interface. When the FortiGate unit is operating in Transparent mode the explicit web proxy changes the source addresses to the management IP address. Figure 40: Example explicit FTP proxy topology
To allow anyone to anonymously log into explicit FTP proxy and connect to any FTP server you can set the explicit FTP proxy default firewall proxy action to accept. When you do this, users can log into the explicit FTP proxy with any username and password.
it lic xy xp ro E p P T F
Pri v N ate etw ork
169
How to use the explicit FTP proxy to connect to an FTP server
In most cases you would want to use security policies to control explicit FTP proxy traffic and apply security features such as access control/authentication, UTM, and traffic logging. You can do this by keeping the default explicit FTP proxy firewall policy action to deny and then adding ftp-proxy security policies. In most cases you would also want users to authenticate with the explicit FTP proxy. By default an anonymous FTP login is required. Usually you would add authentication, in the form of identity based policies, to ftp-proxy security policies. Users can then authenticate with the explicit FTP proxy according to user groups added to the identity based policies. User groups added to FTP proxy identity based policies can use any authentication method supported by FortiOS including the local user database and RADIUS and other remote servers. If you leave the default firewall policy action set to deny and add ftp-proxy security policies, all connections to the explicit FTP proxy must match an ftp-proxy security policy or else they will be dropped. Sessions that are accepted are processed according to the ftp-proxy security policy settings. You can also change the explicit FTP proxy default firewall policy action to accept and add explicit FTP proxy security policies. If you do this, sessions that match ftp-proxy security policies are processed according to the security policy settings. Connections to the explicit FTP proxy that do not match an ftp-proxy security policy are allowed and the users can authenticate with the proxy anonymously user any username and password. There are some limitations to the UTM features that can be applied to explicit web proxy sessions. See UTM features and the explicit FTP proxy on page 175. You cannot configure IPsec, SSL VPN, or Traffic shaping for explicit FTP proxy traffic. Security policies for the FTP proxy can only include firewall addresses not assigned to a FortiGate unit interface or with interface set to any. (On the web-based manager you must set the interface to Any. In the CLI you must unset the associated-interface.) This section describes: How to use the explicit FTP proxy to connect to an FTP server Explicit FTP proxy configuration overview UTM features and the explicit FTP proxy Example: users on an internal network connecting to FTP servers on the Internet through the explicit FTP with RADIUS authentication and virus scanning Explicit FTP proxy sessions and user limits Explicit FTP proxy options

To connect to an FTP server using the explicit FTP proxy, users must run an FTP client and connect to the IP address of a FortiGate interface on which the explicit FTP proxy is enabled. This connection attempt must use the configured explicit FTP proxy port number (default 21). The explicit FTP proxy is not compatible with using a web browser as an FTP client. To use web browsers as FTP clients configure the explicit web proxy to accept FTP sessions.
170
The following steps occur when a user starts an FTP client to connect to an FTP server using the explicit FTP proxy. Any RFC-compliant FTP client can be used. This example describes using a command-line FTP client. Some FTP clients may require a custom FTP proxy connection script. 1 The user enters a command on the FTP client to connect to the explicit FTP proxy. For example, if the IP address of the FortiGate interface on which the explicit FTP proxy is enabled is 10.31.101.100, enter: ftp 10.31.101.100 2 The explicit FTP proxy responds with a welcome message and requests the users FTP proxy user name and password and a username and address of the FTP server to connect to: Connected to 10.31.101.100. 220 Welcome to Fortigate FTP proxy Name (10.31.101.100:user): You can change the message by editing the FTP Proxy replacement message. 3 At the prompt the user enters their FTP proxy username and password and a username and address for the FTP server. The FTP server address can be a domain name or numeric IP address. This information is entered using the following syntax: <proxy-user>:<proxy-password>:<server-user>@<server-address> For example, if the proxy username and password are p-name and p-pass and a valid username for the FTP server is s-name and the servers IP address is ftp.example.com the syntax would be: p-name:p-pass:s-name@ftp.example.com If the FTP proxy accepts anonymous logins p-name and p-pass can be any characters.
4 The FTP proxy forwards the connection request, including the user name, to the FTP server. 5 If the user name is valid for the FTP server it responds with a password request prompt. 6 The FTP proxy relays the password request to the FTP client. 7 The user enters the FTP server password and the client sends the password to the FTP proxy. 8 The FTP proxy relays the password to the FTP server. 9 The FTP server sends a login successful message to the FTP proxy. 10 The FTP proxy relays the login successful message to the FTP client. 11 The FTP client starts the FTP session. All commands entered by the client are relayed by the proxy to the server. Replies from the server are relayed back to the FTP client.
171
Explicit FTP proxy configuration overview
Figure 41: Explicit FTP proxy session
User FTP client
Explicit FTP proxy

1. FTP client connects to explicit FTP proxy. 2. Explicit FTP proxy sends Welcome message and connection prompt.
FTP server
3. FTP client sends authentication and server address to the FTP proxy.
4. FTP proxy forwards the connection request to the FTP server. 5. FTP server sends password request to FTP proxy.
6. FTP proxy relays password request to the FTP client. 7. FTP client sends FTP server password to FTP proxy.
8. FTP proxy relays the password to FTP server. 9. FTP server sends login successful to FTP proxy.
10. FTP proxy relays login successful to FTP client. 11. FTP client starts FTP session.
From a simple command line FTP client connecting to an the previous sequence could appear as follows: ftp 10.31.101.100 21 Connected to 10.31.101.100. 220 Welcome to Fortigate FTP proxy Name (10.31.101.100:user): p-name:p-pass:s-name@ftp.example.com 331 Please specify the password. Password: s-pass 230 Login successful. Remote system type is UNIX Using binary mode to transfer files. ftp>

You can use the following general steps to configure the explicit FTP proxy. To enable the explicit FTP proxy - web-based manager 1 Go to System > Network > Explicit Proxy > Explicit FTP Proxy Options. Select Enable Explicit FTP Proxy to turn on the explicit FTP proxy.
172
2 Select Apply. The default explicit FTP proxy configuration has Default Firewall Policy Action set to Deny and requires you to add a security policy to allow access to the explicit FTP proxy. This configuration is recommended and is a best practice because you can use security policies to control access to the explicit web proxy and also apply security features such as logging, UTM, and authentication (by adding identity-based policies). 3 Go to System > Network > Interface and select one or more interfaces for which to enable the explicit web proxy. Edit the interface configuration and select Enable Explicit FTP Proxy. Enabling the explicit FTP proxy on an interface connected to the Internet is a security risk because anyone on the Internet who finds the proxy could use it to hide their source address. If you enable the proxy on such an interface make sure authentication is required to use the proxy. 4 Go to Policy > Policy > Policy and select Create New and set the Source Interface/Zone to ftp-proxy. You can add multiple ftp-proxy security policies. 5 Configure the security policy as required to accept the traffic that you want to be processed by the explicit web proxy. The source address of the policy should match client source IP addresses. The firewall address selected as the source address cannot be assigned to a FortiGate interface. The Interface field of the firewall address must be blank or it must be set to Any. The destination address of the policy should match the IP addresses of FTP servers that clients are connecting to. The destination address could be all to allow connections to any FTP server. If Default Firewall Policy Action is set to Deny, traffic sent to the explicit FTP proxy that is not accepted by an ftp-proxy security policy is dropped. If Default Firewall Policy Action is set to Allow then all web-proxy sessions that dont match with a security policy are allowed. For example the following security policy allows users on an internal network to access FTP servers on the Internet through the wan1 interface of a FortiGate unit. Source Interface/Zone Source Address Destination Interface/Zone Destination Address Action ftp-proxy Internal_subnet wan1 all ACCEPT
6 You can select other security policy options as required. For example, you can apply UTM protection to web proxy sessions and log allowed ftp proxy traffic. 7 You can also select Enable Identity Based Policy to apply authentication to explicit web proxy sessions. To add identity based policies you must first add user groups to the FortiGate authentication configuration.
173
8 You can add multiple identity based policies to apply different authentication for different user groups and also apply different UTM and logging settings for different user groups. To enable the explicit web proxy - CLI 1 Enter the following command to turn on the explicit FTP proxy. This command also changes the explicit FTP proxy port to 2121. config ftp-proxy explicit set status enable set incoming-port 2121 end The default explicit FTP proxy configuration has sec-default-action set to deny and requires you to add a security policy to allow access to the explicit FTP proxy. 1 Enter the following command to enable the explicit FTP proxy for the internal interface. config system interface edit internal set explicit-ftp-proxy enable end end 2 Use the following command to add a firewall address that matches the source address of users who connect to the explicit FTP proxy. config firewall address edit Internal_subnet set type iprange set start-ip 10.31.101.1 set end-ip 10.31.101.255 end The source address for a ftp-proxy security policy cannot be assigned to a FortiGate unit interface. 3 Use the following command to add a security policy that allows all users on the 10.31.101.0 subnet to use the explicit web proxy for connections through the wan1 interface to the Internet. config firewall policy edit 2 set srcintf ftp-proxy set dstintf wan1 set scraddr Internal_subnet set dstaddr all set action accept set identity-based enable set schedule always config identity-based-policy edit 1 set groups Internal_users set utm-status enable set profile-protocol-options default set av-profile Scan set logtraffic enable set schedule always set service ANY
174
UTM features and the explicit FTP proxy
end end The firewall address selected as the source address cannot be assigned to a FortiGate unit interface. Either the field must be blank or it must be set to Any.
Restricting the IP address of the explicit FTP proxy

You can use the following command to restrict access to the explicit FTP proxy from only one IP address. The IP address that you specify must be the IP address of an interface that the explicit FTP proxy is enabled on. You might want to use this option if the explicit FTP proxy is enabled on an interface with multiple IP addresses. For example, to require uses to connect to the IP address 10.31.101.100 to connect to the explicit FTP proxy: config ftp-proxy explicit set incoming-ip 10.31.101.100 end
Restricting the outgoing source IP address of the explicit FTP proxy

You can use the following command to restrict the source address of outgoing FTP proxy packets to a single IP address. The IP address that you specify must be the IP address of an interface that the explicit FTP proxy is enabled on. You might want to use this option if the explicit FTP proxy is enabled on an interface with multiple IP addresses. For example, to restrict the outgoing packet source address to 172.20.120.100: config ftp-proxy explicit set outgoing-ip 172.20.120.100 end
UTM features and the explicit FTP proxy

You can apply protocol options, antivirus, and data leak prevention (DLP) including DLP archiving to explicit FTP proxy sessions. UTM features are applied by selecting them in a ftp proxy security policy or an identity based policy in a FTP proxy security policy. You cannot apply intrusion protection (IPS), or application control to explicit FTP proxy sessions. To apply intrusion protection to explicit FTP proxy traffic you can add DoS policies to the FortiGate interfaces that receive and send explicit FTP proxy traffic. However, you cannot apply application control to explicit FTP proxy traffic, so you cannot filter explicit FTP proxy traffic by application and explicit FTP proxy traffic does not contribute to application control monitoring or reporting.
Explicit FTP proxy sessions and protocol options

Since the traffic accepted by the explicit FTP proxy is known to be FTP and since the ports are already known by the proxy, the explicit FTP proxy does not use the FTP port protocol options settings. When adding UTM features to an FTP proxy security policy, you must select a protocol options profile. In most cases you can select the default protocol options profile. You could also create a custom protocol options profile. The explicit FTP proxy supports the following protocol options: FTP oversized file action and threshold The explicit FTP proxy does not support the following protocol options:
175
Example: users on an internal network connecting to FTP servers on the Internet through the explicit FTP with RADIUS
Client comforting Server comforting Monitor content information from dashboard. URLs visited by explicit FTP proxy users are not added to dashboard usage and log and archive statistics widgets.
Explicit FTP proxy sessions and antivirus

For explicit FTP proxy sessions, the FortiGate unit applies antivirus scanning to FTP file GET and PUT requests. The FortiGate unit starts virus scanning a file in an FTP session when it receives a file in the body of an FTP request. Flow-based virus scanning is not available for explicit FTP proxy sessions. Even if the FortiGate unit is configured to use flow-based antivirus, explicit FTP proxy sessions use the regular virus database.
Example: users on an internal network connecting to FTP servers on the Internet through the explicit FTP with RADIUS authentication and virus scanning
This example describes how to configure the explicit FTP proxy for the example network shown in Figure 42. In this example, users on the internal network connect to the explicit FTP proxy through the Internal interface with IP address 10.31.101.100 of the FortiGate-51B unit. The explicit web proxy is configured to use port 2121 so to connect to an FTP server on the Internet users must first connect to the explicit FTP proxy using IP address 10.31.101.100 and port 2121. Figure 42: Example explicit FTP proxy network topology
0.
12
r ve er 0 S 20 S 1. IU 0 D .1 A 1 R 0.3 1
w 17 a n 2. 1 20 .1 2
10 ter .3 na 1. l 10 1. 1
in
00 B y 51 ox e- pr e at P t h c e tiG FT on a 0 rf 10 or it F lic led inte 1. 0 xp ab l 1 1 E En rna 1. 12 3 t e 0. : 2 In : 1 ort IP P
In this example, explicit FTP proxy users must authenticate with a RADIUS server before getting access to the proxy. To apply authentication, the security policy that accepts explicit FTP proxy traffic includes an identity based policy that applies per session authentication to explicit FTP proxy users and includes a user group with the RADIUS server in it. The identity based policy also applies UTM virus scanning and DLP.
ith w nts rs lie o 00 se C t t .1 U P ec 01 1 T F nn 1.1 12 co .3 : 2 0 rt :1 o IP P
ork etw0 N . ate 01 riv 31.1 P 0. 1
176
Example: users on an internal network connecting to FTP servers on the Internet through the

This section breaks down the configuration for this example into smaller procedures. For best results, follow the procedures in the order given: 1 Enable the explicit FTP proxy and change the FTP port to 2121. 2 Enable the explicit FTP proxy on the internal interface. 3 Add a RADIUS server and user group for the explicit FTP proxy. 4 Add a security policy for the explicit FTP proxy. Add an identity based policy to the security policy to support authentication. Enable antivirus and DLP UTM features for the identity-based policy.
Configuring the explicit FTP proxy - web-based manager

Use the following steps to configure the explicit FTP proxy from FortiGate web-based manager. To enable and configure the explicit FTP proxy - web-based manager 1 Go to System > Network > Explicit Proxy > Explicit FTP Proxy Options and change the following settings: Enable Explicit FTP Proxy Listen on Interface FTP Port Default Firewall Policy Action 2 Select Apply. To enable the explicit FTP proxy on the Internal interface - web-based manager 1 Go to System > Network > Interface. 2 Edit the internal interface. 3 Select Enable Explicit FTP Proxy. 4 Select OK. To add a RADIUS server and user group for the explicit FTP proxy - web-based manager 1 Go to User > Remote > RADIUS. 2 Select Create New to add a new RADIUS server: Name Type Primary Server Name/IP Primary Server Secret RADIUS_1 Query 10.31.101.200 RADIUS_server_secret Select. No change. This field will eventually show that the explicit web proxy is enabled for the Internal interface. 2121 Deny
3 Go to User > User Group > User Group and select Create New. Name Type Members Explict_proxy_user_group Firewall RADIUS_1
177
4 Select OK. To add a security policy for the explicit FTP proxy - web-based manager 1 Go to Firewall Objects > Address > Address and select Create New. 2 Add a firewall address for the internal network: Address Name Type Interface Internal_subnet Subnet / IP Range Any
Subnet / IP Range 10.31.101.[1-255]
3 Go to Policy > Policy > Policy and select Create New. 4 Configure the explicit FTP proxy security policy. Source Interface/Zone Source Address Destination Interface/Zone Destination Address Action ftp-proxy Internal_subnet wan1 all ACCEPT
5 Select Enable Identity Based Policy, make sure IP Based is not selected and Auth Method is set to Basic. 6 Select Add and configure the following settings for the identity based policy: User Group UTM Enable Antivirus Enable DLP Sensor Protocol Options 7 Select OK. Explicit_policy Select default default default
Configuring the explicit FTP proxy - CLI

Use the following steps to configure the example explicit web proxy configuration from the CLI. To enable and configure the explicit FTP proxy - CLI 1 Enter the following command to enable the explicit FTP proxy and set the TCP port that proxy accepts FTP connections on to 2121. config ftp-proxy explicit set status enable set incoming-port 2121 set sec-default-action deny end To enable the explicit FTP proxy on the Internal interface - CLI 1 Enter the following command to enable the explicit FTP proxy on the internal interface. config system interface
178
edit internal set explicit-ftp-proxy enable end To add a RADIUS server and user group for the explicit FTP proxy - CLI 1 Enter the following command to add a RADIUS server: config user radius edit RADIUS_1 set server 10.31.101.200 set secret RADIUS_server_secret end 2 Enter the following command to add a user group for the RADIUS server. config user group edit Explicit_proxy_user_group set group-type firewall set member RADIUS_1 end To add a security policy for the explicit FTP proxy - CLI 1 Enter the following command to add a firewall address for the internal subnet: config firewall address edit Internal_subnet set type iprange set start-ip 10.31.101.1 set end-ip 10.31.101.255 end 2 Enter the following command to add the explicit FTP proxy security policy: config firewall policy edit 0 set srcintf web-proxy set dstintf wan1 set srcaddr Internal_subnet set dstaddr all set action accept set schedule always set identity-based enable set ipbased disable set auth-method basic config identity-based-policy edit 1 set groups Explicit_Proxy_user_group set schedule always set utm-status enable set av-profile default set dlp-sensor default set profile-protocol-options default end end
179

You can use the following steps to verify that the explicit web proxy configuration is working as expected: 1 The user enters a command on the FTP client to connect to the explicit FTP proxy. For example, if the IP address of the FortiGate interface on which the explicit FTP proxy is enabled is 10.31.101.100, enter: ftp 10.31.101.100 2 The explicit FTP proxy responds with a welcome message and requests the users FTP proxy user name and password and a username and address of the FTP server to connect to: Connected to 10.31.101.100. 220 Welcome to Fortigate FTP proxy Name (10.31.101.100:user): You can change the message by editing the FTP Proxy replacement message. 3 At the prompt the user enters their FTP proxy username and password and a username and address for the FTP server. The FTP server address can be a domain name or numeric IP address. This information is entered using the following syntax: <proxy-user>:<proxy-password>:<server-user>@<server-address> For example, if the proxy username and password are p-name and p-pass and a valid username for the FTP server is s-name and the servers IP address is ftp.example.com the syntax would be: p-name:p-pass:s-name@ftp.example.com If the FTP proxy accepts anonymous logins p-name and p-pass can be any characters.
4 The FTP proxy forwards the connection request, including the user name, to the FTP server. 5 If the user name is valid for the FTP server it responds with a password request prompt. 6 The FTP proxy relays the password request to the FTP client. 7 The user enters the FTP server password and the client sends the password to the FTP proxy. 8 The FTP proxy relays the password to the FTP server. 9 The FTP server sends a login successful message to the FTP proxy. 10 The FTP proxy relays the login successful message to the FTP client. 11 The FTP client starts the FTP session. All commands entered by the client are relayed by the proxy to the server. Replies from the server are relayed back to the FTP client. To test the explicit web proxy configuration 1 From a system on the internal network start an FTP client and enter the following command to connect to the FTP proxy: ftp 10.31.101.100 The explicit FTP proxy should respond with a message similar to the following: Connected to 10.31.101.100.
180
220 Welcome to Fortigate FTP proxy Name (10.31.101.100:user): 2 At the prompt enter a valid username and password for the RADIUS server followed by a user name for an FTP server on the Internet and the address of the FTP server. For example, if a valid username and password on the RADIUS server is ex_name and ex_pass and you attempt to connect to an FTP server at ftp.example.com with user name s_name, enter the following at the prompt: Name (10.31.101.100:user):ex_name:ex_pass:s_name@ftp.example.com 3 You should be prompted for the password for the account on the FTP server. 4 Enter the password and you should be able to connect to the FTP server. 5 Attempt to explore the FTP server file system and download or upload files. 6 To test UTM functionality, attempt to upload or download an ECAR test file. Or upload or download a tex file containing text that would be matched by the DLP sensor. For eicar test files, go to http://eicar.org. 7 You can use the following command to display explicit web proxy sessions. The following output shows one explicit web proxy user with user name user_1 authenticated using IP-based authentication. get test wad 60 users: user:user_1@10.31.101.20(0x40d1b170), type:IP, vfid:0, ref_cnt:2, user:1(0x40f18020), user_ip:1(0x40db70f0), timeout:alive, id: 1 Total allocated user:1 Total user count:1, shared user quota:500, shared user count:1 form_auth_keepalive=0 Explicit proxy authentication timeout: 300 sec, timeout precision: 30000 msec The following output shows one explicit web proxy user with user name user2 authenticated using IP-based authentication. get test wad 60 users: user:user2@10.31.101.20(0x40d1b170), type:SESSION, vfid:0, ref_cnt:2, user:1(0x40f18020), user_ip:1(0x40db70f0), timeout:alive, id: 2 Total allocated user:1 Total user count:1, shared user quota:500, shared user count:1 form_auth_keepalive=0 Explicit proxy authentication timeout: 300 sec, timeout precision: 30000 msec
181
Explicit FTP proxy sessions and user limits
Explicit FTP proxy sessions and user limits

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

To configure the explicit FTP proxy, go to System > Network > Explicit Proxy > Explicit FTP Proxy Options and configure explicit FTP proxy options. For more information about the explicit FTP proxy, see Explicit FTP proxy configuration overview on page 172. Enable Explicit FTP Proxy Listen on Interface FTP Port Default Firewall Policy Action Select to enable the explicit FTP proxy. Select Edit to select the interface that the FortiGate unit will use to listen on. If None displays, you need to go to the interface that you want to use to listen on and select Enable FTP Proxy. Enter the port number for the FTP server. apply the action that the default security policy will take with regards to the explicit FTP proxy activity.
182
FortiOS Handbook
FortiGate WCCP
The Web Cache Communication Protocol (WCCP) can be used to provide web caching with load balancing and fault tolerance. In a WCCP configuration, a WCCP server receives HTTP requests from users web browsers and redirects the requests to one or more WCCP clients. The clients either return cached content or request new content from the destination web servers before caching it and returning it to the server which in turn returns the content to the original requestor. If a WCCP configuration includes multiple WCCP clients, the WCCP server load balances traffic among the clients and can detect when a client fails and failover sessions to still operating clients. WCCP is described by the Web Cache Communication Protocol internet draft. The sessions that are cached by WCCP depend on the configuration of the WCCP clients. If the client is a FortiGate unit, you can configure the port numbers and protocol number of the sessions to be cached. For example, to cache HTTPS traffic on port 443 the WCCP client port must be set to 443 and protocol must be set to 6. If the WCCP client should also cache HTTPS traffic on port 993 the client ports option should include both port 443 and 993. WCCP sessions are accepted by a security policy before being cached. If the security policy that accepts sessions that do not match the port and protocol settings in the WCCP clients the traffic is dropped. WCCP is configured per-VDOM. A single VDOM can operate as a WCCP server or client (not both at the same time). FortiGate units are compatible with third-party WCCP clients and servers. If a FortiGate unit is operating as an Internet firewall for a private network, you can configure it to cache and serve some or all of the web traffic on the private network using WCCP by adding one or more WCCP clients, configuring WCCP server settings on the FortiGate unit and adding WCCP to security policies that accept HTTP session from the private network. FortiGate units support WCCPv1 and WCCPv2. A FortiGate unit in NAT/Route or transparent mode can operate as a WCCP server. To operate as a WCCP client a FortiGate unit must be in NAT/Route mode. FortiGate units communicate between WCCP servers and clients uses UDP port 2048. This communication can be encapsulated in a GRE tunnel or just use layer 2 forwarding. A WCCP server can also be called a WCCP router. A WCCP client can also be called a WCCP cache engine. This section describes: WCCP service groups, service numbers, service IDs and well known services WCCP configuration overview Example: caching HTTP sessions on port 80 using WCCP Example: caching HTTP sessions on port 80 and HTTPS sessions on port 443 using WCCP WCCP packet flow Configuring the forward and return methods and adding authentication
183
WCCP service groups, service numbers, service IDs and well known services
FortiGate WCCP
WCCP Messages Troubleshooting WCCP
A FortiGate unit configured as a WCCP server or client can include multiple server or client configurations. Each of these configurations is called a WCCP service group. A service group consists of one or more WCCP servers (or routers) and one or more WCCP clients working together to cache a specific type of traffic. The service group configuration includes information about the type of traffic to be cached, the addresses of the WCCP clients and servers and other information about the service. A service group is identified with a numeric WCCP service ID (or service number) in the range 0 to 255. All of the servers and clients in the same WCCP service group must have service group configurations with the same WCCP service ID. The value of the service ID provides some information about the type of traffic to be cached by the service group. Service IDs in the range 0 to 50 are reserved for well known services. A well known service is any service that is defined by the WCCP standard as being well known. Since the service is well known, just the service ID is required to identify the traffic to be cached. Even though the well known service ID range is 0 to 50, at this time only one well known service has been defined. Its service ID 0, which is used for caching HTTP (web) traffic. So to configure WCCP to cache HTTP sessions you can add a service group to the WCCP router and WCCP clients with a service ID of 0. No other information about the type of traffic to cache needs to be added to the service group. Since service IDs 1 to 50 are reserved for well know services and since these services are not defined yet, you should not add service groups with IDs in the range 1 to 50. FortiOS does allow you to add service groups with IDs between 1 and 50. Since these service groups have not been assigned well known services; however, they will not cache any sessions. Service groups with IDs 51 to 255 allow you to set the port numbers and protocol number of the traffic to be cached. So you can use service groups with IDs 51 to 255 to cache different kinds of traffic based on port numbers and protocol number of the traffic. Service groups 1 to 50; however, do not allow you to set port numbers or protocol numbers so cannot be used to cache any traffic. To cache traffic other than HTTP traffic you must add service groups with IDs in the range 51 to 255. These service group configurations must include the port numbers and protocol number of the traffic to be cached. It is the port and protocol number configuration in the service group that determines what traffic will be cached by WCCP.
Example WCCP server and client configuration for caching HTTP sessions (service ID = 0)
Enter the following command to add a WCCP service group to a WCCP server that caches HTTP sessions. The IP address of the server is 10.31.101.100 and the WCCP clients are on the 10.31.101.0 subnet. The service ID of this service group is 0. config system wccp edit 0 set router-id 10.31.101.100
184
FortiGate WCCP
set server-list 10.31.101.0 255.255.255.0 end Enter the following commands to configure a FortiGate unit to operate as a WCCP client and add a service group that configures the client to cache HTTP sessions. The IP address of the server is 10.31.101.100 and IP address of this WCCP clients is 10.31.101.1 subnet. The service ID of this service group is 0. config system settings set wccp-cache-engine enable end config system wccp edit 0 set cache-id 10.31.101.1 set router-list 10.31.101.100 end You cannot enter the wccp-cache-engine enable command if you have already added a WCCP service group. When you enter this command an interface named w.<vdom_name> is added to the FortiGate configuration (for example w.root). All traffic redirected from a WCCP router is considered to be received at this interface of the FortiGate unit operating as a WCCP client. A default route to this interface with lowest priority is added.
Example WCCP server and client configuration for caching HTTPS sessions
Enter the following command to add a service group to a WCCP server that caches HTTPS content on port 443 and protocol 6. The IP address of the server is 10.31.101.100 and the WCCP clients are on the 10.31.101.0 subnet. The service ID of this service group is 80. config system wccp edit 80 set router-id 10.31.101.100 set server-list 10.31.101.0 255.255.255.0 set ports 443 set protocol 6 end Enter the following commands to configure a FortiGate unit to operate as a WCCP client and add a service group that configures client to cache HTTPS sessions on port 443 and protocol 6. The IP address of the server is 10.31.101.100 and IP address of this WCCP clients is 10.31.101.1 subnet. The service ID of this service group must be 80 to match the service ID added to the server. config system settings set wccp-cache-engine enable end config system wccp edit 80 set cache-id 10.31.101.1 set router-list 10.31.101.100 set ports 443 set protocol 6 end
185
FortiGate WCCP
Example WCCP server and client configuration for caching HTTP and HTTPS sessions
You could do this by configuring two WCCP service groups as described in the previous examples. Or you could use the following commands to configure one service group for both types of traffic. The example also caches HTTP sessions on port 8080. Enter the following command to add a service group to a WCCP server that caches HTTP sessions on ports 80 and 8080 and HTTPS sessions on port 443. Both of these protocols use protocol number 6. The IP address of the server is 10.31.101.100 and the WCCP clients are on the 10.31.101.0 subnet. The service ID of this service group is 90. config system wccp edit 90 set router-id 10.31.101.100 set server-list 10.31.101.0 255.255.255.0 set ports 443 80 8080 set protocol 6 end Enter the following commands to configure a FortiGate unit to operate as a WCCP client and add a service group that configures client to cache HTTP sessions on port 80 and 8080 and HTTPS sessions on port 443. The IP address of the server is 10.31.101.100 and IP address of this WCCP clients is 10.31.101.1 subnet. The service ID of this service group must be 90 to match the service ID added to the server. config system settings set wccp-cache-engine enable end config system wccp edit 90 set cache-id 10.31.101.1 set router-list 10.31.101.100 set ports 443 80 8080 set protocol 6 end
Other WCCP service group options

In addition to using WCCP service groups to define the types of traffic to be cached by WCCP the following options are available for servers and clients.
Server configuration options

The server configuration must include the router-id, which is the WCCP server IP address. This is the IP address of the interface that the server uses to communicate with WCCP clients. The group-address is used for multicast WCCP configurations to specify the multicast addresses of the clients. The server-list defines the IP addresses of the WCCP clients that the server can connect to. Often the server list can be the address of the subnet that contains the WCCP clients. The authentication option enables or disables authentication for the WCCP service group. Authentication must be enabled on all servers and clients in a service group and members of the group must have the same password.
186
FortiGate WCCP
WCCP configuration overview
The forward-method option specifies the protocol used for communication between the server and clients. The default forwarding method is GRE encapsulation. If required by your network you can also select to use unencapsulated layer-2 packets instead of GRE or select any to allow both. The return-method allows you to specify the communication method from the client to the server. Both GRE and layer-2 are supported. The assignment-method determines how the server load balances sessions to the clients if there are multiple clients. Load balancing can be done using hashing or masking.
Client configuration options

The client configuration includes the cache-id which is the IP address of the FortiGate interface of the client that communicates with WCCP server. The router-list option is the list of IP addresses of the WCCP servers in the WCCP service group. The ports option lists the port numbers of the sessions to be cached by the client and the protocol sets the protocol number of the sessions to be cached. For TCP sessions the protocol is 6. The service-type option can be auto, dynamic or standard. Usually you would not change this setting. The client configuration also includes options to influence load balancing including the primary-hash, priority, assignment-weight and assignment-bucket-format.
WCCP configuration overview

To configure WCCP you must create a service group that includes WCCP servers and clients. WCCP servers intercept sessions to be cached (for example, sessions from users browsing the web from a private network). To intercept sessions to be cached the WCCP server must include a security policy that accepts sessions to be cached and WCCP must be enabled in this security policy. The server must have an interface configured for WCCP communication with WCCP clients. That interface sends and receives encapsulated GRE traffic to and from WCCP clients. The server must also include a WCCP service group that includes a service ID and the addresses of the WCCP clients as well as other WCCP configuration options. To use a FortiGate unit as a WCCP client, the FortiGate unit must be set to be a WCCP client (or cache engine). You must also configure an interface on the client for WCCP communication. The client sends and receives encapsulated GRE traffic to and from the WCCP server using this interface. The client must also include a WCCP service group with a service ID that matches a service ID on the server. The client service group also includes the IP address of the servers in the service group and specifies the port numbers and protocol number of the sessions that will be cached on the client. When the client receives sessions from the server on its WCCP interface, it either returns cached content over the WCCP interface or connects to the destination web servers using the appropriate interface depending on the client routing configuration. Content received from web servers is then cached by the client and returned to the WCCP server over the WCCP link. The server then returns the received content to the initial requesting user web browser.
187
Example: caching HTTP sessions on port 80 using WCCP
FortiGate WCCP
Finally you may also need to configure routing on the server and client FortiGate units and additional security policies may have to be added to the server to accept sessions not cached by WCCP.

In this example configuration (shown in Figure 43), a FortiGate unit with host name WCCP_srv is operating as an Internet firewall for a private network is also configured as a WCCP server. The port1 interface of WCCP_srv is connected to the Internet and the port2 interface is connected to the internal network. All HTTP traffic on port 80 that is received at the port2 interface of WCCP_srv is accepted by a port2 to port1 security policy with WCCP enabled. All other traffic received at the port2 interface is allowed to connect to the Internet by adding a general port2 to port1 security policy below the HTTP on port 80 security policy. A WCCP service group is added to WCCP_srv with a service ID of 0 for caching HTTP traffic on port 80. The port5 interface of WCCP_srv is configured for WCCP communication. A second FortiGate unit with host name WCCP_client is operating as a WCCP client. The port1 interface of WCCP_client is connected to port5 of WCCP_srv and is configured for WCCP communication. WCCP_client is configured to cache HTTP traffic because it also has a WCCP service group with a service ID of 0. WCCP_client connects to the Internet through WCCP_srv. To allow this, a port5 to port1 security policy is added to WCCP_srv. Figure 43: FortiGate WCCP server and client configuration
b we nt rs e Cli wse ro b
po 10 rt2 .3 1. 10
1.
10
0 er rv se srv P _ C P C C W C W 0. po 17 rt1 2. 20 .1 2 1. 10 0 10 20 nc tr ap af s fic u la G R E -e

188 WAN Optimization, Web Cache, Explicit Proxy, and WCCP for FortiOS 4.0 MR3 01-433-96996-20120113 http://docs.fortinet.com/
te d 0 ttt5 .1 orr 51 po .5 0 10 1. 0 tt1 ..1 or 51 po .5 10 10 nt lie t C ien P cl C _ C P W CC W
FortiGate WCCP
Configuring the WCCP server (WCCP_srv)

Use the following steps to configure WCCP_srv as the WCCP server for the example network. The example steps only describe the WCCP-related configuration. To configure WCCP_srv as a WCCP server 1 Add a port2 to port1 security policy that accepts HTTP traffic on port 80 and is configured for WCCP: config firewall policy edit 0 set srtintf port2 set dstintf port1 set srcaddr all set dstaddr all set action accept set schedule always set service HTTP set wccp enable set nat enable end 2 Add another port2 to port1 security policy to allow all other traffic to connect to the Internet. .config firewall policy edit 0 set srtintf port2 set dstintf port1 set srcaddr all set dstaddr all set action accept set schedule always set service ANY set nat enable end 3 Move this policy below the WCCP policy in the port2 to port1 policy list. 4 Enable WCCP on the port5 interface. config system interface edit port5 set wccp enable end 5 Add a WCCP service group with service ID 0. config system wccp edit 0 set router-id 10.51.101.100 set server-list 10.51.101.0 255.255.255.0 end 6 Add a firewall address and security policy to allow the WCCP_client to connect to the internet. config firewall address edit WCCP_client_addr set subnet 10.51.101.10 end
189
Example: caching HTTP sessions on port 80 and HTTPS sessions on port 443 using WCCP
FortiGate WCCP
config firewall policy edit 0 set srtintf port5 set dstintf port1 set srcaddr WCCP_client_addr set dstaddr all set action accept set schedule always set service ANY set nat enable end
Configuring the WCCP client (WCCP_client)

Use the following steps to configure WCCP_client as the WCCP client for the example network. The example steps only describe the WCCP-related configuration. To configure WCCP_client as a WCCP client 1 Configure WCCP_client to operate as a WCCP client. config system settings set wccp-cache-engine enable end You cannot enter the wccp-cache-engine enable command if you have already added a WCCP service group. When you enter this command an interface named w.<vdom_name> is added to the FortiGate configuration (for example w.root). All traffic redirected from a WCCP router is considered to be received at this interface of the FortiGate unit operating as a WCCP client. A default route to this interface with lowest priority is added. 2 Enable WCCP on the port1 interface. config system interface edit port1 set wccp enable end 3 Add a WCCP service group with service ID 0. config system wccp edit 0 set cache-id 10.51.101.10 set router-list 10.51.101.100 end
This example configuration is the same as that shown in Figure 43 and described in Example: caching HTTP sessions on port 80 using WCCP on page 188 except that WCCP now also cached HTTPS traffic on port 443. To cache HTTP and HTTPS traffic the WCCP service group must have a service ID in the range 51 to 255 and you must specify port 80 and 443 and protocol 6 in the service group configuration of the WCCP client. Also the security policy on the WCCP_srv that accepts sessions from the internal network to be cached must accept HTTP and HTTPS sessions.
190
FortiGate WCCP
Configuring the WCCP server (WCCP_srv)

Use the following steps to configure WCCP_srv as the WCCP server for the example network. The example steps only describe the WCCP-related configuration. To configure WCCP_srv as a WCCP server 1 Add a port2 to port1 security policy that accepts HTTP traffic on port 80 and HTTPS traffic on port 443 and is configured for WCCP: config firewall policy edit 0 set srtintf port2 set dstintf port1 set srcaddr all set dstaddr all set action accept set schedule always set service HTTP HTTPS set wccp enable set nat enable end 2 Add another port2 to port1 security policy to allow all other traffic to connect to the Internet. .config firewall policy edit 0 set srtintf port2 set dstintf port1 set srcaddr all set dstaddr all set action accept set schedule always set service ANY set nat enable end 3 Move this policy below the WCCP policy in the port2 to port1 policy list. 4 Enable WCCP on the port5 interface. config system interface edit port5 set wccp enable end 5 Add a WCCP service group with service ID 90 (can be any number between 51 and 255). config system wccp edit 90 set router-id 10.51.101.100 set server-list 10.51.101.0 255.255.255.0 end 6 Add a firewall address and security policy to allow the WCCP_client to connect to the internet. config firewall address edit WCCP_client_addr set subnet 10.51.101.10
191
WCCP packet flow
FortiGate WCCP
end .config firewall policy edit 0 set srtintf port5 set dstintf port1 set srcaddr WCCP_client_addr set dstaddr all set action accept set schedule always set service ANY set nat enable end
Configuring the WCCP client (WCCP_client)

Use the following steps to configure WCCP_client as the WCCP client for the example network. The example steps only describe the WCCP-related configuration. To configure WCCP_client as a WCCP client 1 Configure WCCP_client to operate as a WCCP client. config system settings set wccp-cache-engine enable end You cannot enter the wccp-cache-engine enable command if you have already added a WCCP service group. When you enter this command an interface named w.<vdom_name> is added to the FortiGate configuration (for example w.root). All traffic redirected from a WCCP router is considered to be received at this interface of the FortiGate unit operating as a WCCP client. A default route to this interface with lowest priority is added. 2 Enable WCCP on the port1 interface. config system interface edit port1 set wccp enable end 3 Add a WCCP service group with service ID 90. This service group also specifies to cache sessions on ports 80 and 443 (for HTTP and HTTPS) and protocol number 6. config system wccp edit 90 set cache-id 10.51.101.10 set router-list 10.51.101.100 ports 80 443 set protocol 6 end
WCCP packet flow

The following packet flow sequence assumes you have configured a FortiGate unit to be a WCCP server and one or more FortiGate units to be WCCP clients. 1 A users web browser sends a request for web content.
192
FortiGate WCCP
Configuring the forward and return methods and adding authentication
2 The FortiGate unit configured as a WCCP server includes a security policy that intercepts the request and forwards it to a WCCP client. The security policy can apply UTM features to traffic accepted by the policy. 3 The WCCP client receives the WCCP session. 4 The client either returns requested content to the WCCP server if it is already cached, or connects to the destination web server, receives and caches the content and then returns it to the WCCP server. 5 The WCCP server returns the requested content to the users web browser. 6 The WCCP router returns the request to the client web browser. The client we browser is not aware that all this is taking place and does not have to be configured to use a web proxy.
Configuring the forward and return methods and adding authentication

The WCCP forwarding method determines how intercepted traffic is transmitted from the WCCP router to the WCCP cache engine. There are two different forwarding methods: GRE forwarding (the default) encapsulates the intercepted packet in an IP GRE header with a source IP address of the WCCP router and a destination IP address of the target WCCP cache engine. The results is a tunnel that allows the WCCP router to be multiple hops away from the WCCP cache server. L2 forwarding rewrites the destination MAC address of the intercepted packet to match the MAC address of the target WCCP cache engine. L2 forwarding requires that the WCCP router is Layer 2 adjacent to the WCCP client. You can use the following command on a FortiGate unit configured as a WCCP router to change the forward and return methods to L2: config system wccp edit 1 set forward-method L2 set return-method L2 end You can also set the forward and return methods to any in order to match the cache server configuration. By default the WCCP communication between the router and cache servers is unencrypted. If you are concerned about attackers sniffing the information in the WCCP stream you can use the following command to enable hash-based authentication of the WCCP traffic. You must enable authentication on the router and the cache engines and all must have the same password. config system wccp edit 1 set authentication enable set password <password> end
193
WCCP Messages
FortiGate WCCP
WCCP Messages
When the WCCP service is active on a web cache server it periodically sends a WCCP HERE I AM broadcast or unicast message to the FortiGate unit operating as a WCCP router. This message contains the following information: Web cache identity (the IP address of the web cache server). Service info (the service group to join). If the information received in the previous message matches what is expected, the FortiGate unit replies with a WCCP I SEE YOU message that contains the following details: Router identity (the FortiGate units IP address. Sent to IP (the web cache IP addresses to which the packets are addressed) When both ends receive these two messages the connection is established, the service group is formed and the designated web cache is elected.
Troubleshooting WCCP
Two types of debug commands are available for debugging or troubleshooting a WCCP connection between a FortiGate unit operating as a WCCP router and its WCCP cache engines.
Real time debugging

The following commands can capture live WCCP messages: diag debug en diag debug application wccpd <debug level>
Application debugging
The following commands display information about WCCP operations: get test wccpd <integer> diag test application wccpd <integer> Where <integer> is a value between 1 and 5: 1 Display WCCP stats 2 Display WCCP config 3 Display WCCP cache servers 4 Display WCCP services 5 Display WCCP assignment Enter the following command to view debugging output: diag test application wccpd 3 Sample output from a successful WCCP connection: service-0 in vdom-root: num=1, usable=1 cache server ID: len=44, addr=172.16.78.8, weight=4135, status=0 rcv_id=6547, usable=1, fm=1, nq=0, dev=3(k3), to=192.168.11.55 ch_no=0, num_router=1: 192.168.11.55
194
FortiGate WCCP
Sample output from the same command from an unsuccessful WCCP connection (because of a service group password mismatch): service-0 in vdom-root: num=0, usable=0 diag debug application wccpd -1 Sample output: wccp_on_recv()-98: vdom-root recv: num=160, dev=3(3), 172.16.78.8->192.168.11.55 wccp2_receive_pkt()-1124: len=160, type=10, ver=0200, length=152 wccp2_receive_pkt()-1150: found component:t=0, len=20 wccp2_receive_pkt()-1150: found component:t=1, len=24 wccp2_receive_pkt()-1150: found component:t=3, len=44 wccp2_receive_pkt()-1150: found component:t=5, len=20 wccp2_receive_pkt()-1150: found component:t=8, len=24 wccp2_check_security_info()-326: MD5 check failed
195
FortiGate WCCP
196
FortiOS Handbook
WAN optimization, web cache, explicit proxy and WCCP get and diagnose commands
The following get and diagnose commands are available for troubleshooting WAN optimization, web cache, explicit proxy and WCCP. get test {wa_cs | wa_dbd | wad | wad_diskd | wccpd} <test_level> diagnose wad diagnose wacs diagnose wadbd diagnose debug application {wa_cs | wa_dbd | wad | wad_diskd | wccpd} [<debug_level>]
get test {wa_cs | wa_dbd | wad | wad_diskd | wccpd} <test_level>

Display usage information about WAN optimization and web-cache-related applications. Use <test_level> to display different information. get test wa_cs <test_level> get test wa_dbd <test_level> get test wad <test_level> get test wad_diskd <test_level> get test wccpd <test_level> Variable Description wad wa_cs wa_dbd wad_diskd wccpd Display information about WAN optimization, web caching, the explicit web proxy, and the explicit FTP proxy. Display information about the WAN optimization web cache server. Display information about the WAN optimization storage server application. Display information about the WAN optimization disk access daemon application. Display information about the WCCP application.
Examples
Enter the following command to display WAN optimization tunnel protocol statistics. The http tunnel and tcp tunnel parts of the command output below shows that WAN optimization has been processing HTTP and TCP packets. get test wad 11 wad tunnel protocol stats: http tunnel
197
get test {wa_cs | wa_dbd | wad | wad_diskd | wccpd} <test_level> WAN optimization, web cache, explicit proxy and WCCP get and
bytes_in=1751767 bytes_out=325468 ftp tunnel bytes_in=0 bytes_out=0 cifs tunnel bytes_in=0 bytes_out=0 mapi tunnel bytes_in=0 bytes_out=0 tcp tunnel bytes_in=3182253 bytes_out=200702 maintenance tunnel bytes_in=11800 bytes_out=15052 Enter the following command to display the current WAN optimization peers. You can use this command to make sure all peers are configured correctly. The command output shows one peer with IP address 172.20.120.141, peer name Web_servers, with 10 active tunnels. get test wad 26 peer name=Web_servers ip=172.20.120.141 vd=0 version=1 tunnels(active/connecting/failover)=10/0/0 sessions=0 n_retries=0 version_valid=true Enter the following command to restart the WAN optimization web cache server. get test wa_cs 99 Enter the following command to display all test options: get test wad WAD Test Usage 1: display total memory usage 3: display proxy status 4: display all stats and connections 5: toggle AV conserve mode(for debug purpose). 8: display all fix-sized advanced memory stats 10: toggle cifs read-ahead 11: display tunnel protocol stats 12: flush tunnel protocol stats 13: display http protocol stats 14: flush http protocol stats 15: display cifs protocol stats 16: flush cifs protocol stats 17: display ftp protocol stats 18: flush ftp protocol stats 19: display mapi protocol stats 20: flush mapi protocol stats 21: display tcp protocol stats 22: flush tcp protocol stats 23: display all protocols stats 24: flush all protocols stats 25: display all listeners 26: display all peers 27: display DNS stats 28: display security profile mapping for regular firewall policy 30: display Byte Cache DB state 31: flush Byte Cache DB stats
198
WAN optimization, web cache, explicit proxy and WCCP get and diagnose commands get test {wa_cs | wa_dbd | wad | wad_diskd |
32: display Web Cache DB state 33: flush Web Cache DB stats 35: display tunnel compressor state 36: flush tunnel compressor stats 37: discard all wad debug info that is currently pending 38: display rules 39: display video cache rules (patterns) 40: display cache state 41: flush cache stats 42: display all fix-sized advanced memory stats in details 45: display memory cache state 46: flush memory cache stats 47: display SSL stats 48: flush SSL stats 49: display SSL mem stats 50: display Web Cache stats 51: flush Web Cache stats 52: flush idle Web cache objects 53: display firewall policies 54: display WAD tunnel stats. 55: display WAD fsae state. 56yxxx: set xxx concurrent Web Cache session for object storage y. 57yxxx: set xxxK(32K, 64K,...) unconfirmed write/read size per Web Cache object for object storage y. 58yxxxx: set xxxxK maximum ouput buffer size for object storage y. 59yxx: set lookup lowmark(only if more to define busy status) to be xx for object storage y. 60: display current web proxy users 61: flush current web proxy users 62: display current web proxy user summary 63: display web cache cache sessions 65: display cache exemption patterns 66: toggle dumping URL when daemon crashes. 67: list all used fqdns. 68: list all current ftpproxy sessions. 69: display ftpproxy stats. 70: clear ftpproxy stats. 600000..699999 cmem bucket stats (699999 for usage) 70yxxx: set xxxK maximum ouput buffer size for byte storage y. 71yxxx: set number of buffered add requests to be xxx for byte storage y. 72yxxxx: set number of buffered query requests to be xxxx for byte storage y. 73yxxxxx: set number of concurrent query requests to be xxxxx for byte storage y. 79xxxx: set xxxxMiB maximum AV memory.(0: set to default. 80: display av memory usage 81: toggle av memory protection 800..899: mem_diag commands (800 for help & usage) 800000..899999: mem_diag commands with 1 arg (800 for help & usage)
199
diagnose wad
80000000..89999999: mem_diag commands with 2 args (800 for help & usage) 90: set to test disk failure 91: unset to test disk failure 92: trigger a disk failure event 98: gracefully stopping wad proxy 99: restart proxy
diagnose wad
Display diagnostic information about the WAN optimization daemon (wad).
diagnose wad console-log {disable | enable) diagnose wad filter {clear | dport | dst | list | negate | protocol | sport | src | vd} diagnose wad history diagnose wad session diagnose wad stats {cache | cifs | clear | crypto | ftp | http | list | mapi | mem | scan | scripts | summary | tcp | tunnel} diagnose wad tunnel {clear | list} Variable Description console-log Enable or disable displaying WAN optimization log messages on the CLI console. filter Set a filter for listing WAN optimization daemon sessions or tunnels. clear reset or clear the current log filter settings. dport enter the destination port range to filter by. dst enter the destination address range to filter by. list display the current log filter settings history session stats Display statistics for one or more WAN optimization protocols for a specified period of time (the last 10 minutes, hour, day or 30 days). Display diagnostics for WAN optimization sessions or clear active sessions. Display statistics for various parts of WAN optimization such as cache statistics, CIFS statistics, MAPI statistics, HTTP statistics, tunnel statistics etc. You can also clear WAN optimization statistics and display a summary. Display diagnostic information for one or all active WAN optimization tunnels. Clear all active tunnels. Clear all active tunnels.
tunnel
Examples
Enter the following command to list all of the running WAN optimization tunnels and display information about each one. The command output shows 10 tunnels all created by peer-to-peer WAN optimization rules (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=172.20.120.141 SSL-secured-tunnel=no auth-grp=
200
diagnose wad
bytes_in=348 bytes_out=384 Tunnel: id=99 type=manual vd=0 shared=no uses=0 state=3 peer name=Web_servers id=99 ip=172.20.120.141 SSL-secured-tunnel=no auth-grp= bytes_in=348 bytes_out=384 Tunnel: id=98 type=manual vd=0 shared=no uses=0 state=3 peer name=Web_servers id=98 ip=172.20.120.141 SSL-secured-tunnel=no auth-grp= bytes_in=348 bytes_out=384 Tunnel: id=39 type=manual vd=0 shared=no uses=0 state=3 peer name=Web_servers id=39 ip=172.20.120.141 SSL-secured-tunnel=no auth-grp= bytes_in=1068 bytes_out=1104 Tunnel: id=7 type=manual vd=0 shared=no uses=0 state=3 peer name=Web_servers id=7 ip=172.20.120.141 SSL-secured-tunnel=no auth-grp= bytes_in=1228 bytes_out=1264 Tunnel: id=8 type=manual vd=0 shared=no uses=0 state=3 peer name=Web_servers id=8 ip=172.20.120.141 SSL-secured-tunnel=no auth-grp= bytes_in=1228 bytes_out=1264 Tunnel: id=5 type=manual vd=0 shared=no uses=0 state=3 peer name=Web_servers id=5 ip=172.20.120.141 SSL-secured-tunnel=no auth-grp= bytes_in=1228 bytes_out=1264 Tunnel: id=4 type=manual vd=0 shared=no uses=0 state=3 peer name=Web_servers id=4 ip=172.20.120.141 SSL-secured-tunnel=no auth-grp= bytes_in=1228 bytes_out=1264 Tunnel: id=1 type=manual vd=0 shared=no uses=0 state=3 peer name=Web_servers id=1 ip=172.20.120.141 SSL-secured-tunnel=no auth-grp= bytes_in=1228 bytes_out=1264 Tunnel: id=2 type=manual vd=0 shared=no uses=0 state=3 peer name=Web_servers id=2 ip=172.20.120.141 SSL-secured-tunnel=no auth-grp=
201
diagnose wacs
bytes_in=1228 bytes_out=1264 Tunnels total=10 manual=10 auto=0
diagnose wacs
Display diagnostic information for the web cache database daemon (wacs).
diagnose diagnose diagnose diagnose Variable clear recents restart stats
wacs clear wacs recents wacs restart wacs stats Description Remove all entries from the web cache database. Display recent web cache database activity. Restart the web cache daemon and reset statistics. Display web cache statistics.
diagnose wadbd
Display diagnostic information for the WAN optimization database daemon (waddb). diagnose wadbd {check | clear | recents | restart | stats} Variable check clear recents restart stats Description Check WAN optimization database integrity. Remove all entries from the WAN optimization database. Display recent WAN optimization database activity. Restart the WAN optimization daemon and reset statistics. Display WAN optimization statistics.
diagnose debug application {wa_cs | wa_dbd | wad | wad_diskd | wccpd} [<debug_level>]

View or set the debug level for displaying WAN optimization and web cache-related daemon debug messages. Include a <debug_level> to change the debug level. Leave the <debug_level> out to display the current debug level. Default debug level is 0. diagnose debug application wa_cs [<debug_level>] diagnose debug application wa_dbd [<debug_level>] diagnose debug application wad [<debug_level>] diagnose debug application wccpd [<debug_level>] Variable Description wa_cs wa_dbd wad wccpd Set the debug level for the web cache server. Set the debug level for the WAN optimization database server. Set the debug level for the WAN optimization daemon. Set the debug level for the WCCP daemon.
202
diagnose debug application {wa_cs |
203
diagnose debug application {wa_cs | wa_dbd | wad | wad_diskd | wccpd} [<debug_level>]
WAN optimization, web cache, explicit
204
FortiOS Handbook
Appendix
Document conventions
Fortinet technical documentation uses the conventions described below.
IPv4 IP addresses
To avoid publication of public IPv4 IP addresses that belong to Fortinet or any other organization, the IP addresses used in Fortinet technical documentation are fictional and follow documentation guidelines specific to Fortinet. The addresses used are from the private IP address ranges defined in RFC 1918: Address Allocation for Private Internets, available at http://ietf.org/rfc/rfc1918.txt?number-1918. Most of the examples in this document use the following IP addressing: IP addresses are made up of A.B.C.D: A - can be one of 192, 172, or 10 - the private addresses covered in RFC 1918. B - 168, or the branch / device / virtual device number. Branch number can be 0xx, 1xx, 2xx - 0 is Head office, 1 is remote, 2 is other. Device or virtual device - allows multiple FortiGate units in this address space (VDOMs). Devices can be from x01 to x99. C - interface - FortiGate units can have up to 40 interfaces, potentially more than one on the same subnet 001 - 099- physical address ports, and non -virtual interfaces 100-255 - VLANs, tunnels, aggregate links, redundant links, vdom-links, etc. D - usage based addresses, this part is determined by what the device is doing. The following gives 16 reserved, 140 users, and 100 servers in the subnet. 001 - 009 - reserved for networking hardware, like routers, gateways, etc. 010 - 099 - DHCP range - users 100 - 109 - FortiGate devices - typically only use 100 110 - 199 - servers in general (see later for details) 200 - 249 - static range - users 250 - 255 - reserved (255 is broadcast, 000 not used) The D segment servers can be farther broken down into: 110 - 119 - Email servers 120 - 129 - Web servers 130 - 139 - Syslog servers 140 - 149 - Authentication (RADIUS, LDAP, TACACS+, FSAE, etc) 150 - 159 - VoIP / SIP servers / managers 160 - 169 - FortiAnalyzers 170 - 179 - FortiManagers 180 - 189 - Other Fortinet products (FortiScan, FortiDB, etc.) 190 - 199 - Other non-Fortinet servers (NAS, SQL, DNS, DDNS, etc.) Fortinet products, non-FortiGate, are found from 160 - 189.
205
Appendix
Example Network
Variations on network shown in Figure 44 are used for many of the examples in this document. In this example, the 172.20.120.0 network is equivalent to the Internet. The network consists of a head office and two branch offices. Figure 44: Example network
WLAN: 10.12.101.100 SSID: example.com Password: supermarine DHCP range: 10.12.101.200-249
Linux PC 10.11.101.20
FortiWiFi-80CM Windows PC 10.11.101.10 Internal network
IN 10 T .11 .10
1.1
01
10
.11
.10 Po 1.1 rt 2 02 P 17 ort 1 2.2 (s 0 . 1 n i ff 20 er FortiGate-82C .14 mo 1 de
FortiAnalyzer-100B
P 10 ort 2 .11 .10 1.1
30 10 .11 .10 Por 1.1 t 1 10
Switch
10
.11
.10 Po 1.1 rt 2 00 P 17 ort 1 2.2 0.1 20
FortiGate-620B HA cluster FortiMail-100C
.14
Po an rt 2 d3 Po rt 1
Switch
f rt 8 r o Po mirro (
rt po
s2
an
d3
H ea d of fic e
P 10 ort 1 .21 .10 1.1 FortiGate-3810A
01
Linux PC 10.21.101.10
17
2.2
0.1
20 WAN .12 1 2 I 10 ntern .31 al .10 1.1 FortiGate-51B 0
B ra nc h of fic e B ra nc h
of fic e
1. rt 1 10 Po 0.21. 1
16
Windows PC 10.31.101.10
FortiManager-3000B
10
.2
rt 4 Po .100 1 .10 2
Cluster
Port 1: 10.21.101.102
FortiGate-5005FA2
Port 1: 10.21.101.102
FortiGate-5005FA2
Port 1: 10.21.101.103
FortiSwitch-5003A
Port 1: 10.21.101.161
FortiGate-5050-SM
Port 1: 10.21.101.104
Engineering network 10.22.101.0
206
Appendix
Table 1: Example IPv4 IP addresses Location and device Head Office, one FortiGate Head Office, second FortiGate Branch Office, one FortiGate Office 7, one FortiGate with 9 VDOMs Internal 10.11.101.100 10.12.101.100 10.21.101.100 10.79.101.100 Dmz 10.11.201.100 10.12.201.100 10.21.201.100 10.79.101.100 10.31.201.110 n/a External 172.20.120.191 172.20.120.192 172.20.120.193 172.20.120.194 n/a n/a
Office 3, one FortiGate, web n/a server Bob in accounting on the corporate user network (DHCP) at Head Office, one FortiGate Router outside the FortiGate 10.0.11.101.200
n/a
n/a
172.20.120.195
Tips, must reads, and troubleshooting

A Tip provides shortcuts, alternative approaches, or background information about the task at hand. Ignoring a tip should have no negative consequences, but you might miss out on a trick that makes your life easier. A Must Read item details things that should not be missed such as reminders to back up your configuration, configuration items that must be set, or information about safe handling of hardware. Ignoring a must read item may cause physical injury, component damage, data loss, irritation or frustration.
A Troubleshooting tip provides information to help you track down why your configuration is not working.
Typographical conventions
Table 2: Typographical conventions in Fortinet technical documentation Convention Button, menu, text box, field, or check box label CLI input Example From Minimum log level, select Notification.
CLI output
config system dns set primary <address_ipv4> end FGT-602803030703 # get system settings comments : (null) opmode : nat
207
Registering your Fortinet product
Appendix
Table 2: Typographical conventions in Fortinet technical documentation Emphasis HTTP connections are not secure and can be intercepted by a third party. <HTML><HEAD><TITLE>Firewall Authentication</TITLE></HEAD> <BODY><H4>You must authenticate to use this service.</H4> Visit the Fortinet Technical Support web site, https://support.fortinet.com. Type a name for the remote VPN peer or client, such as Central_Office_1. Go to VPN > IPSEC > Auto Key (IKE). For details, see the FortiOS Handbook.
File content
Hyperlink Keyboard entry Navigation Publication
Registering your Fortinet product

Access to Fortinet customer services, such as firmware updates, support, and FortiGuard services, requires product registration. You can register your Fortinet product at http://support.fortinet.com.
Training Services
Fortinet Training Services offers courses that orient you quickly to your new equipment, and certifications to verify your knowledge level. Fortinet training programs serve the needs of Fortinet customers and partners world-wide. Visit Fortinet Training Services at http://campus.training.fortinet.com, or email training@fortinet.com.
Technical Documentation
Visit the Fortinet Technical Documentation web site, http://docs.fortinet.com, for the most up-to-date technical documentation. The Fortinet Knowledge Base provides troubleshooting, how-to articles, examples, FAQs, technical notes, and more. Visit the Fortinet Knowledge Base at http://kb.fortinet.com.
Comments on Fortinet technical documentation

Send information about any errors or omissions in this or any Fortinet technical document to techdoc@fortinet.com.
Customer service and support

Fortinet is committed to your complete satisfaction. Through our regional Technical Assistance Centers and partners worldwide, Fortinet provides remedial support during the operation phase of your Fortinet product's development life cycle. Our Certified Support Partners provide first level technical assistance to Fortinet customers, while the regional TACs solve complex technical issues that our partners are unable to resolve. Visit Customer Service and Support at http://support.fortinet.com.
Fortinet products End User License Agreement

See the Fortinet products End User License Agreement.
208
FortiOS Handbook
Index
A
accept any peer, 35 active-passive WAN optimization rules, 43 always revalidate, 91 antivirus explicit FTP proxy, 175 explicit web proxy, 155 application control explicit FTP proxy, 175 explicit web proxy, 155 authentication, 44 authentication method, 38 Citrix, 154 explicit web proxy, 153, 154 HTTP, 154 NAT device, 154 peer, 36 proxy, 154 WAN optimization peer authentication, 35 web proxy, 154 Windows Terminal Server, 154 authentication group authentication method, 38 certificate, 38 password, 38 pre-shared key, 38 authentication realm explicit web proxy, 150 CIDR, 48 CIFS protocol optimization, 27 Citrix authentication, 154 client WCCP, 183 configuring WAN optimization peer, 37 conventions, 205 customer service, 208
D
default TTL web cache, 92 disk space byte cache, 32 web cache, 32 DLP explicit FTP proxy, 175 explicit web proxy, 155 documentation conventions, 205 Fortinet, 208
E
E Reload, 93 exempt web cache, 90 expired objects cache, 93 explicit FTP proxy, 169 antivirus, 175 application control, 175 DLP, 175 incoming IP address, 175 intrusion protection, 175 outgoing IP address, 175 protocol options, 175 replacement message, 171, 180 reverse, 19 UTM, 173 explicit mode WAN optimization, 44, 50
B
byte cache, 11 changing the relative amount of disk space, 32
C
cache exempting from web caching, 90 cache engine WCCP, 183 cache expired objects, 93 certificate authentication group, 38 certification, 208
209
Index
explicit web proxy, 145, 156 antivirus, 155 application control, 155 authentication, 153, 154 authentication realm, 150 DLP, 155 flow-based scanning, 156 FortiGuard web filtering, 155 FTP, 145, 165 HTTPS, 145, 165, 169 intrusion protection, 155 IPS, 155, 175 PAC, 145, 165 protocol options, 155 proxy auto-config, 145, 165 proxy chaining, 151 realm, 150 SOCKS, 145, 165 SSL content scanning and inspection, 157 unknown HTTP version, 150 UTM, 148, 155 web filtering, 155
host ID peer, 24 HTTP, 92 authentication, 154 protocol optimization, 27 unknown HTTP sessions, 52 WCCP service ID, 184 HTTP 1.1 conditionals, 92 HTTP port web cache, 74 HTTP rule non-HTTP sessions, 52 HTTPS explicit web proxy, 145, 165, 169 HTTPS deep scanning explicit web proxy.explicit web proxy HTTPS deep scanning, 157
I
identity-based security policies, 44 if-modified-since, 92 ignore web cache setting, 92 incoming-ip explicit FTP proxy, 175 insert policy before security policy, 46 introduction Fortinet documentation, 208 intrusion protection explicit FTP proxy, 175 explicit web proxy, 155 IP address peer, 24 private network, 205 IPS explicit web proxy, 155, 175
F
firewall load balancing, 44 flow-based scanning, 156 format hard disk, 31 FortiClient peer, 25 FortiGuard Antivirus, 208 FortiGuard web filtering explicit web proxy, 155 Fortinet Technical Documentation, conventions, 205 Technical Support, 208 Technical Support, registering with, 208 Training Services, 208 Fortinet customer service, 208 Fortinet documentation, 208 fresh factor web cache, 91 FTP explicit web proxy, 145, 165 protocol optimization, 27 FTP proxy, 169 antivirus, 175 change the prompt, 171, 180 DLP, 175 protocol options, 175 UTM, 173
L
load balancing, 44
M
MAPI, 11 protocol optimization, 27 matching security policy, 46 max cache object size web cache, 91 Max HTTP message length web cache, 92 Max HTTP request length web cache, 92 max TTL web cache, 92 memory usage WAN Optimization, 28 web caching, 28 min TTL web cache, 92
H
hard disk byte cache storage, 31 formatting, 31 Wan optimization storage, 31 health monitor proxy forwarding, 152
210
Index
monitoring proxy forwarding, 152 WAN Optimization, 41 WAN optimization, 28 web caching, 93 moving a WAN optimization rule, 47
N
NAT, 44 NAT device authentication, 154 NAT/Route mode, 25 negative response duration web cache, 91 non-HTTP sessions HTTP rule, 52
proxy antivirus, 155, 175 DLP, 155, 175 explicit web proxy authentication, 154 FortiGuard web filtering, 155 protocol options, 155, 175 web filtering, 155 proxy auto-config explicit web proxy, 145, 165 proxy chaining explicit web proxy, 151 health monitoring, 152 proxy forwarding server explicit web proxy, 151 health checking, 152 proxy FQDN web cache, 92
O
out of path topology, 13 outgoing-ip explicit FTP proxy, 175
R
realm explicit web proxy, 150 registering with Fortinet Technical Support, 208 replacement message explicit FTP proxy, 171, 180 revalidated pragma-no-cache, 93 reverse explicit FTP proxy, 19 reverse proxy web cache, 20, 128, 134 RFC 1918, 205 router WCCP, 183 routing configuring, 145, 169 rule, 43 active-passive, 43 changing the position in the rule list, 47 move, 47 moving, 47 non-HTTP sessions, 52 peer-to-peer, 43 unknown HTTP sessions, 52 WAN optimization, 43
P
PAC explicit web proxy, 145, 165 password authentication group, 38 peer accept any peer, 35 host ID, 24 IP address, 24 monitoring WAN optimization, 41 WAN optimization, 35 peer authentication, 36 WAN optimization, 35 peer-to-peer WAN optimization rules, 43 policy insert policy before, 46 matching, 46 security, 23 traffic priority, 45 pragma-no-cache, 93 pre-shared key authentication group, 38 product registration, 208 protocol optimization, 11 CIFS, 27 FTP, 27 HTTP, 27 MAPI, 27 TCP, 27 protocol options explicit FTP proxy, 175 explicit web proxy, 155
S
secure tunnelling, 11 security policy matching, 46 security policy, 23, 43 identity-based, 44 insert policy before, 46 matching, 46 traffic priority, 45 server WCCP, 183 service group WCCP, 184 service ID WCCP, 184
FortiOS Handbook v3: WAN Optimization, Web Cache, Explicit Proxy, and WCCP 01-433-96996-20120113 http://docs.fortinet.com/ Feedback
211
Index
service number WCCP, 184 sharing WAN optimization tunnels, 26 SOCKS explicit web proxy, 145, 165 SSL content scanning explicit web proxy, 157 SSL offloading, 11 status, 45
virus explicit web proxy, 155, 175
W
WAN optimization and virtual IPs, 44 explicit mode, 50 memory usage, 28 monitoring, 28 peer authentication, 35 peers, 35 storage, 31 transparent mode, 50 WAN optimization peer configuring, 37 monitoring, 41 WAN Optimization rule, 45 changing the position in the rule list, 47 moving, 47 status, 45 WAN optimization traffic log, 30 wanopt-traffic, 30 WCCP, 183 cache engine, 183 client, 183 router, 183 server, 183 service group, 184 service ID, 184 service number, 184 topology, 11, 22 well known service, 184 WCCP service ID HTTP, 184 web cache, 11, 91 active-passive WAN optimization, 82 adding to passive WAN optimization rule, 82 always revalidate, 91 changing the relative amount of disk space, 32 client/server WAN optimization, 82 default TTL, 92 exempt, 90 fresh factor, 91 HTTP port, 74 max cache object size, 91 max HTTP message length, 92 max HTTP request length, 92 maximum TTL, 92 minimum TTL, 92 monitoring, 93 negative response duration, 91 non-standard ports, 79 peer to peer WAN optimization, 86 proxy FQDN, 92 reverse proxy, 20, 128, 134 storage, 31 TCP port, 74 Web Cache Communication Protocol See WCCP, 183 web caching memory usage, 28 web filtering explicit web proxy, 155 WAN Optimization, Web Cache, Explicit Proxy, and WCCP for FortiOS 4.0 MR3 01-433-96996-20120113 http://docs.fortinet.com/
T
TCP protocol optimization, 27 TCP port WAN optimization tunnels, 25 web cache, 74 technical documentation conventions, 205 support, 208 technical support, 208 topology out of path, 13 Traffic Priority, 45 traffic priority security policy, 45 traffic shaping, 45 traffic shaping, 44 traffic priority, 45 Training Services, 208 Transparent mode, 25 transparent mode WAN optimization, 44, 50 TTL web cache default, 92 web cache maximum, 92 web cache minimum, 92 tunnel sharing WAN optimization tunnels, 26 TCP port, 25 WAN optimization, 25 tunnel request, 36 tunnel-non-http, 52
U
unknown HTTP sessions, 52 unknown HTTP version explicit web proxy, 150 UTM, 43 explicit FTP proxy, 173 explicit web proxy, 148, 155 ftp proxy, 173 web proxy, 148
V
VDOMs, 25 virtual domains, 25 virtual IP WAN optimization, 44
212
Index
web proxy, 145 antivirus, 155 authentication, 153, 154 DLP, 155 FortiGuard web filtering, 155 HTTPS deep scanning, 157 protocol options, 155 UTM, 148 web filtering, 155
webcache-storage-percentage, 33 well known service WCCP, 184 Windows Terminal Server authentication, 154
X
X-Forwarded-For (XFF), 151
213
Index
214
Index
215
Index
216
Index
217

Fortigate Wanopt Cache Proxy 40 Mr3

Uploaded by

Document Information

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Fortigate Wanopt Cache Proxy 40 Mr3

Uploaded by

Copyright:

Available Formats

WAN Optimization, Web Cache, Explicit Proxy, and WCCP

FortiOS Handbook v3 for FortiOS 4.0 MR3

WAN optimization and Web cache storage

WAN optimization peers and authentication groups

Configuring WAN optimization rules

WAN optimization configuration examples

Advanced configuration example

SSL offloading for WAN optimization and web caching

133 134 135 136 139

FortiClient WAN optimization

The FortiGate explicit web proxy

158 159 159 161 162

Explicit proxy sessions and user limits . . . . . . . . . . . . . . . . . . . . . . . . . 163

165 165 167 167

The FortiGate explicit FTP proxy

176 177 177 178 180

WAN optimization, web cache, explicit proxy, and WCCP concepts

WAN optimization topologies

WAN optimization, web cache, explicit proxy, and WCCP concepts

WAN optimization topologies

Basic WAN optimization topologies

d n an atio ity iz ur tim ec p S o N A W A W io at iz tim el op nn N tu n

d n an atio ity iz ur tim ec p S o N A W

WAN optimization, web cache, explicit proxy, and WCCP concepts

WAN optimization topologies

S ec ur ity op A W at iz tim el op nn N tu io n N on A ti W iza tim

N on A ti W iza tim S ec ur ity

WAN optimization topologies

WAN optimization, web cache, explicit proxy, and WCCP concepts

Figure 3: Out-of-path WAN optimization

th pa on of- ati ut- timiz O p o AN W

ath n f-p tio t-o miza Ou pti o AN W

WAN optimization, web cache, explicit proxy, and WCCP concepts

WAN optimization topologies

Topology for multiple networks

WAN optimization tunnels N WA ation iz tim

d n an atio ity i z ur tim ec p S o N A W

d an ion ty uri izat c Se ptim o AN W

th pa on of- ati ut- timiz O p No WA Pr iv

WAN optimization topologies

WAN optimization, web cache, explicit proxy, and WCCP concepts

WAN optimization with web caching

d n an atio ity iz ur tim ec p S o N A W io at iz tim el op nn N u A t W n

, ion ity at g ur iz hin ec im c S pt ca o b N e A w W nd a

rk two Ne te va th Pri wi rvers e bs we

WAN optimization, web cache, explicit proxy, and WCCP concepts

WAN optimization topologies

WAN optimization and web caching with FortiClient peers

WAN, LAN, or Internet

Explicit Web proxy topologies

WAN optimization, web cache, explicit proxy, and WCCP concepts

Explicit Web proxy topologies

WAN optimization, web cache, explicit proxy, and WCCP concepts

Explicit FTP proxy topologies

Explicit FTP proxy topologies

WAN, LAN, or Internet

Web caching topologies

WAN optimization, web cache, explicit proxy, and WCCP concepts

Web caching topologies

WAN, LAN, or Internet

WAN optimization, web cache, explicit proxy, and WCCP concepts

Web caching topologies

Figure 12: Reverse proxy web caching topology

WAN, LAN, or Internet