Riverbed Steelhead 1020 & FortiGate MR5 Compatibility Testing

FortiVerified FortiVerified

High Performance Multi-Threat Security Solutions

Corporate Headquarters 1090 Kifer Road, Sunnyvale, Ca 94086 USA http://www.fortinet.com Tel: +1 408 235 7700 Fax: +1 408 235 7737

Contents
Part 1: Introduction

Chapter 1: Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-1 Purpose . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-2 Main Features and Functionality Tested . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-2 Topology Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-3 In-Path Transparent . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-3 In-Path PBR w/NAT and VPN . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-4 Part 2: Unpacking

Chapter 2: Packaging Review . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-1 Operations Tasks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-1 Inside The Box . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-2 Initial Impressions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-2 Part 3: Tests

Chapter 3: Testing Conditions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-1 Operations Tasks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-1 Requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-2 Hardware . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-2 Software . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-2 Topologies and Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-3 In-Path Transparent . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-3 In-Path Transparent Configurations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-4 General Optimization Testing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-9 In-Path Policy Based Routing (PBR) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-13 In-Path PBR w/NAT and VPN Configurations . . . . . . . . . . . . . . . . . . . . . . . . 3-16 Proving the Fortinet-Riverbed PBR Concept . . . . . . . . . . . . . . . . . . . . . . . . 3-29 Chapter 4: Steelhead Features . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-1 Operations Tasks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-1 Features . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-2 Part 4: Summary

Chapter 5: Evaluation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-1

Part 1

Introduction

This part gives an overview of meshing Riverbed and Fortinet together in order to create a more robust and secure network. This part consists of the following chapters: Chapter 1, Overview

Chapter 1

Overview

Riverbed Steelhead appliances provide WAN acceleration and optimization for data and application. Steelhead appliances decrease the amount of traffic that traverse WAN links when there are two or more remote appliances working together. Data that can be accelerated and optimized is LZ compressed and sent to a neighboring Steelhead to be decompressed. Once the initial optimization has been completed, requests for the same data across WAN links will be accelerated between appliances. Acceleration occurs when requests for remote data results in sending 16-byte index references that point to the same data on the local Steelhead. If the accelerated data has been modified, the new data bits will be considered a cold start and go through the optimization process. The warm bits that were previously optimized will be accelerated. For example, if it takes 2 seconds to download an 18 megabyte word document that has been optimized and accelerated; adding an additional 1 megabyte to the file will add an additional 5 seconds to the initial download time. This is because 18 of the 19 megabytes have been accelerated while the extra 1 megabyte has not completed optimization. Speed will vary depending on WAN link conditions. The overall impact is a smarter way of transferring data across WAN links with lower bandwidth consumption which leads to lower costs. Fortinet offers an array of multi-threat security solutions that help businesses of all sizes meet their security challenges and enable a safe and clean communications environment. Fortinet built its comprehensive security platform from the ground up to provide multiple layers of threat protection and management. This translates into increased deployment flexibility and enhanced security through integration -- a "future-proof" solution that can easily scale with business requirements. Using Fortinet's ASIC innovation and performance acceleration capabilities, FortiGate systems detect and eliminate the most damaging, content-based threats from email and Web traffic such as viruses, worms, intrusions, inappropriate Web content and more in real time, without degrading network performance. FortiGate systems integrate the industry's broadest suite of security protection - including firewall, VPN, antivirus, intrusion prevention (IPS), Web filtering, antispam, and traffic shaping - that can be deployed individually or combined for a comprehensive unified threat management (UTM) solution. This document outlines compatibility testing and deployment scenarios of FortiGate UTM firewalls in conjunction with Riverbed Steelhead 1020 appliances. This chapter includes the following sections: Purpose 1-1

Introduction

Purpose
The main purpose of this document is to ensure interoperability between Fortinet and Riverbed technologies. FortiGate UTM Firewalls will be used to protect LAN networks while Steelhead appliances will be used to optimize and accelerate clean, filtered traffic. This document should also be used as guidance to configure real-world deployment scenarios.

Main Features and Functionality Tested

The primary focus of testing involves verification of Steelhead acceleration and optimization through FortiGate firewalls in various modes with different features enabled. This rigorous process serves to ensure full compatibility between the two devices. A list of additional Steelhead FortiVerified results can be found in chapter 5.

Steelhead Modes: In-Path Appliance-to-Appliance IPSEC Steelhead Acceleration and Optimization Features: FTP HTTP CIFS SMTP (TCP) FortiGate Topologies: Transparent Routed + Policy Based Routing NAT + IPSEC + Policy Based Routing FortiGate Features: Firewall Only Firewall + Antivirus Firewall + IPS Firewall + Antispam VDOM Policy Based Routing IPSEC

Introduction

1-2

Topology Overview
For the purpose of proving compatibility, two topologies are shown below. Each of which consists of FortiGate devices and Steelhead Optimization appliances. Both scenarios will be discussed in greater detail in later chapters. To reduce complexity, the Steelhead is configured as in-path for all shown topologies.

In-Path Transparent
In the following topology, the term in-path refers to the Steelhead being in the direct path of traffic. The term transparent refers to the mode in which a FortiGate has been configured. Once in transparent mode, the FortiGate acts as a bridge between two network devices while retaining the ability to provide Fortinets full line of UTM defenses. This type of deployment reduces complexities when introducing FortiGates to existing networks because it does not require another layer of routing. In Fortinet terms, Steelhead appliances also function as transparent devices. This allows for both complex technologies to coexists and be easily deployed into an existing network with minimal downtime.

Introduction

1-3

In-Path PBR w/NAT and VPN

In the following topology, many key features of the FortiGate are put to work. The key features consist of virtualization (VDOMs), Inter-VDOM routing, policy based routing, VPN, NAT and the full line of UTM defenses: antivirus, antispam, intrusion detection, intrusion prevention and web content filtering -- all wrapped around the Steelheads WAN optimization and acceleration technology. Essentially, this topology provides a solid, clean and optimized network that allows for network scalability in cases where Internet traffic is exceeds Steelhead performance thresholds.

Introduction

1-4

Part 2

Unpacking

This part provides an overview of the Riverbed Steelhead 1020 packaging upon delivery. This part consists of the following chapters: Chapter 2, Packaging Review

Chapter 2

Packaging Review

This chapter describes the perception and packaging quality of the Steelhead appliance, offering an initial impression of the product care and quality. This chapter includes the following sections: Operations Tasks

Operations Tasks
This section includes the following topics: Inside The Box Initial Impressions

Unpacking

2-1

Inside The Box

Server is wrapped inside plastic and double-boxed Packaging included the following: o A set of four (4) Post Rack Mounts o Crossover, Straight Through, Console and Power Cable o Product Information, License Agreement, Rack Installation, Safety and Compliance Guide o Information on How to Obtain an SSL License Key o Documentation CD o August 2007 Getting Started Guide o Support Documentation

Initial Impressions
Steelheads appliances are well-packaged and double boxed for extra protection. Reviewing the included documentation and pamphlets gives the impression that Riverbed stands behind their products with an eager-to-support attitude. The support documentation provides a very clear understanding of the contact points, different support packages, the expected response time, and an overview of the RMA process.

Unpacking

2-2

Part 3

Tests

This part provides an overview of the testing environment and additional Steelhead Features. This part consists of the following chapters: Chapter 3, Testing Conditions Chapter 4, Steelhead Features

Chapter 3

Testing Conditions

This chapter describes the requirements, tasks, and commands used to administer, configure, and duplicate the test topologies and scenarios. This chapter includes the following sections: Operations Tasks

Operations Tasks
This section includes the following topics: Requirements Topologies and Configuration

Tests

3-1

Requirements
Hardware
FortiGate 3600A, Firmware 3.0 Build 572 FortiGate 3016B, Firmware 3.0 Build 572 FortiGate 1000, Functions as a Router Only 2 Steelhead 1020, Version 3.0.10c 3 Physical Computers Network Nightmare (Wan Simulation) 3 Cisco 3750 Switches

Software
Windows 2003 Server w/File Sharing (CIFS) Flash FXP (FTP) MDaemon 9.6.2 (SMTP) VMWare Server (Installed on Windows 2003 Server) Ubuntu Server 7.10 (VMware Image) Windows XP (VMware Image) Apache MRTG ProFTPD Serv-u FTP Outlook Express 6.00.3790.3959 Firefox 2.0.0.6 IE 7.0.5730.11

Tests

3-2

Topologies and Configuration

It is important to understand key facts of the FortiGate UTM Firewalls and Steelhead WAN optimization appliances. Fortinet offers a broad range of devices that target SMB environments to large enterprise deployments where speed and performance are major design considerations. In networks with high-end FortiGates, the traffic throughput could easily exceed the throughput limit of any Steelhead models. Steelhead appliances function in pairs, at a minimum. Optimization occurs only between Steelhead devices and/or Steelhead mobile software. The Riverbed Sizing Guide shows the WAN Capacity throughput rate of Steelhead devices which indicates the maximum throughput of optimized traffic. Un-optimized traffic will pass through the Steelhead at a higher throughput, but the maximum rate of this traffic is unknown. The Riverbed Sizing Guide shows the WAN Optimized TCP Connections limit of Steelhead devices which specifies the optimized connection limit. Un-optimized (bypass) traffic connections do not apply to this value. The Primary interface on the Steelhead is used only for management. Management can also be performed via the virtual in-path interface through the LAN or WAN interfaces. However, restarting the optimization service will bring down the in-path interface, causing a management outage. Hence, it is recommended to use the primary interface for management. Steelhead appliances store data that has been optimized onto a hard drive. If more space for new data is needed, the Steelhead discards least-used data to free up storage for the new data. Steelhead licenses are stored within configuration files. Erasing a configuration file will remove all licenses within the configuration and disable optimization. Keep a copy of the license information before erasing configurations. Specific data within files or specific files cannot be cleared from the data store. Clearing data from the data store is an all-or-nothing option.

In-Path Transparent
The in-path transparent topology is very easy to deploy and understand. Both devices are in the direct path of traffic. LAN-to-WAN and WAN-to-LAN throughput requirements should be taken into consideration and matched appropriately with both devices. If network throughput is more than a Steelhead can handle, but less than a single FortiGate, consider going with In-Path PBR deployments. In this topology, all traffic that is sent to the FortiGate 3600A from the LAN is first scanned, cleaned, and sent to the Steelhead for WAN optimization. If traffic can be optimized, the Steelhead flags an autodiscovery bit in the TCP header which will be used to locate another Steelhead and forwards the traffic on the WAN interface. If the traffic cannot be optimized, it will pass through the Steelhead unmodified. Once optimized traffic is sent to the neighboring Steelhead as depicted, it is decompressed and forwarded to the FortiGate 3016B for sanitization. The clean traffic is then sent to a host on the LAN. By scanning traffic bi-directionally, the FortiGates ensures that only clean traffic is passed from LAN to LAN, Internet to LAN, and LAN to Internet.

Tests

3-3

In-Path Transparent Configurations

FortiGate configurations can be implemented using either the WebUI, CLI, or both. However, the configuration for this topology will be shown using the CLI, while the configuration for the In-Path PBR w/NAT and VPN topology will be shown using the WebUI and CLI. This is done to demonstrate both user interfaces. Please refer to each vendors guide for management access methods. Since the configurations are identical and mirror one another, only half of the topology configuration will be outlined but the full configurations for both sides can be found in the documents below.

fgt_system-3600A-in-path-trans.conf

fgt_system-3810B-in-path-trans.conf

steelhead-01-in-path-trans.conf

steelhead-02-in-path-trans.conf

Tests

3-4

FG3600A Set the FortiGate into transparent mode with a management IP address. config system settings set opmode transparent set manageip 10.0.0.3/255.255.255.0 end Configure a default gateway on the FortiGate so that the management IP address is reachable. config router static edit 1 set gateway 10.0.0.1 next end Set port 1 through 3 on the FortiGate to be reachable via ICMP with HTTPS and SSH access. config system interface edit "port1" set vdom "root" set allowaccess ping https ssh set type physical next edit "port2" set vdom "root" set allowaccess ping https ssh set type physical next edit "port3" set vdom "root" set allowaccess ping https ssh set type physical next end Create a firewall protection profile to scan and log for AV and IPS attacks. config firewall profile edit "protect" set log-ips enable set log-av-virus enable set log-av-block enable set log-av-oversize enable set log-web-ftgd-err enable set ftp block scan splice set http block scan rangeblock unset https set imap fragmail spamfssubmit

Tests

3-5

set pop3 block scan fragmail spamfssubmit set smtp block scan fragmail spamfssubmit splice set pop3-spamtagtype subject set imap-spamtagtype subject set filepattable 1 set nntp no-content-summary set ips-signature info low medium high critical set ips-anomaly info low medium high critical unset im set comment " " set ftgd-wf-options strict-blocking set ftgd-wf-https-options strict-blocking next end Allow traffic to traverse between the following ports: 1 and 2, 3 and 2, 2 and 3. The firewall protection profiles protect is applied to each firewall policy. The FortiGate is set to protect bi-directionally, bad traffic is neither allowed out nor into the LAN. During this test, the FortiGate is not setup to block traffic at the networking layer. Instead, the proxies will be used to distinguish between good traffic versus bad traffic. config firewall policy edit 1 set srcintf "port1" set dstintf "port2" set srcaddr "all" set dstaddr "all" set action accept set schedule "always" set service "ANY" set profile-status enable set profile "protect" next edit 2 set srcintf "port2" set dstintf "port1" set srcaddr "all" set dstaddr "all" set action accept set schedule "always" set service "ANY" set profile-status enable set profile "protect" next

Tests

3-6

edit 3 set srcintf "port2" set dstintf "port3" set srcaddr "all" set dstaddr "all" set action accept set schedule "always" set service "ANY" set profile-status enable set profile "protect" next edit 4 set srcintf "port1" set dstintf "port3" set srcaddr "all" set dstaddr "all" set action accept set schedule "always" set service "ANY" set profile-status enable set profile "protect" next end

Steelhead 1020 Steelhead appliances come with a CLI wizard that can be used to initially create a working configuration. Run the following commands to activate the CLI wizard. config terminal configuration jump-start The inpath0_0 interface is a virtual interface that exists between the WAN and LAN physical interface. It is used for traffic optimization. The primary interface is used for management only. Set IP addresses on the inpath0_0 and primary interfaces to enable optimization and management respectively. ## ## Network interface configuration ## no interface inpath0_0 dhcp interface inpath0_0 duplex "auto" interface inpath0_0 ip address 10.0.0.2 /24 interface inpath0_0 mtu "1500" no interface inpath0_0 shutdown interface inpath0_0 speed "auto" interface inpath0_0 txqueuelen "100" no interface primary dhcp interface primary ip address 10.0.0.4 /24

Tests

3-7

Set the default gateway for both interfaces. ## ## Routing configuration ## ip default-gateway "10.0.0.1" ip in-path-gateway inpath0_0 "10.0.0.1" ## ## Other IP configuration ## hostname "sh1020-01" ip name-server 66.80.130.23 Enable in-path support. Making configuration changes to the in-path interface requires a restart of the optimization service. To do so, type restart. This command does not reboot the entire appliance. ## ## General Service ## in-path enable Set email options to receive notifications of events and failures. Include any SNMP settings that may be needed. ## ## Network management configuration ## email mailhub "mail.fortinet.com" email notify events recipient "test@fortinet.com" email notify failures recipient "test@fortinet.com" license install LK1-SH10BASE-0000-0000-1-6251-9323-24AF license install LK1-SH10CIFS-0000-0000-1-EF0F-CFD1-F9B6 license install LK1-SH10EXCH-0000-0000-1-74B0-25C6-80A5 license install LK1-SH40SSL-0000-0000-1-6C8C-D443-A36F snmp-server community "riverbed" snmp-server contact "fortinet" snmp-server listen enable snmp-server location "fortilab" username admin password 7 $1$3Gnqafpr$Ew54XJGW415bHCOtczyTz. ## ## Miscellaneous other settings ## internal set modify - /snmp/listen/interface/inpath0_0 string inpath0_0

Tests

3-8

General Optimization Testing

An FTP and HTTP connection was made from 10.0.1.10 to 10.0.0.11. The Steelhead Current Connections under the report section show that optimization is occurring between both Steelheads. Yellow/orange triple arrows indicate an optimized connection has been established.

The Steelhead sends only the modified bytes within a previously optimized file. Zipping the file or renaming it will not affect the optimization process, as it is still considered the same file. When adding a previously-optimized file to an archive with a non-optimized file, the file within the archive that was already optimized will be accelerated. While the new file within the archive will be subject to the initial optimization phase, also known as a cold start. CIFS Transfer Test Retrieving an 18 megabyte file via CIFs from 10.0.1.10 to 10.0.0.10 shows optimization and acceleration functioning properly. The initial pre-optimized transfer took a few minutes to complete. The optimized transfer with the same file took less than a second.

FTP Transfer Test Retrieving an 18.92 megabyte file via FTP through the Steelhead unit required about 2 minutes and 15 seconds on a cold start. After optimization, retrieving the same file on a warm start took 23 seconds. [R] RETR f3.doc [R] 150 Opening BINARY mode data connection for f3.doc (20615168 bytes) [R] 226 Transfer complete.

Tests

3-9

Transferred: f3.doc 19.66 MB in 1 minute 54 seconds (176.3 KB/s) Transfer queue completed Transferred 1 file totaling 19.66 MB in 2 minutes 15 seconds (176.3 KB/s) [R] PASV [R] 227 Entering Passive Mode (10,0,0,11,187,71) [R] Opening data connection IP: 10.0.0.11 PORT: 47943 [R] RETR f3.doc [R] 150 Opening BINARY mode data connection for f3.doc (20615168 bytes) [R] 226 Transfer complete. Transferred: f3.doc 19.66 MB in 2.24 seconds (8.77 MB/s) Transfer queue completed Transferred 1 file totaling 19.66 MB in 23.10 seconds (8.77 MB/s) It is worth mentioning that if a previously-seen file becomes infected with a virus, the FortiGate will detect the virus and prevent the changed bits to be sent from Steelhead to Steelhead. Transferring an infected file eicar_com.zip through the FTP connection from 10.0.1.10 to 10.0.0.11 resulted in the FortiGate quarantining the file before it reached the sh1020-02 Steelhead.

Tests

3-10

Enabling File Pattern on the FortiGate to block *.out extensions performed as designed. Notice the .out file was blocked by the FortiGate when an FTP transfer was attempted from 10.0.1.10 to 10.0.0.11.

SMTP Transfer Test Mail transfer testing showed that the FortiGate scanned and blocked infected files sent via SMTP. In this test, an infected attachment is being sent from 10.0.1.10 to the server, 10.0.0.12.

Tests

3-11

The FortiGate reports the quarantined file in its log.

The Steelhead registered that an optimized SMTP (port 25) connection was attempted (see the triple yellow arrows below). However, the data was never optimized since the FortiGate blocked the transfer.

The various tests performed proved that the FortiGate played a critical role in providing a clean pipe for the Steelhead, while the Steelhead provided a faster mechanism to deliver the clean data over the WAN link. Sending only clean data out of the LAN will also play a role in reducing WAN congestion.

Tests

3-12

In-Path Policy Based Routing (PBR)

PBR allows for a network to sustain higher throughput thresholds by bypassing the Steelhead and maintaining a more granular way to route traffic. Clean traffic that can be optimized is sent towards the Steelhead, while normal traffic will bypass the device and be routed directly by the FortiGate. This policybased routing configuration is implemented only on the FortiGate. Do not confuse this setup with the Steelhead policy-based routing configuration found in the Steelhead deployment and configuration guide. The Steelhead 1020 is depicted as hanging off the side of the FortiGate; it is still configured in in-path mode. Optimized traffic traverses the wan0_0 interface through to the lan0_0 interface of the Steelhead 1020 and vice versa.

Tests

3-13

To further understand this topology, lets take a closer look at the right side of the network.

The FortiGate is diagrammed as two separate devices for the ease of understanding. In reality, it is a single physical unit with two VDOMs (virtual domains) configured. Each VDOM has its own separate routing table, routing protocols, firewall policies, protection profiles and more. VDOM traffic is separated through the use of VLAN tagging and/or assigning physical interfaces to a VDOM. In this topology, the ROOT VDOM provides many services and serves to protect the Steelhead from the Internet, NAT traffic from the LAN to the Internet, terminate VPN connections, use policy-based routing to route optimized traffic through the Steelhead, and use static routes to route un-optimized traffic to the LAN bypassing the Steelhead. The LAN VDOM performs bi-directional firewall and content filtering functions, policy-based routing, and static routing. The topology also shows the configuration of inter-VDOM routing. Inter-VDOM routing allows traffic to be passed from one virtual firewall to another virtual firewall without the use of an external routing device.

Tests

3-14

In this topology, routing traffic between VDOMs is occurring in two ways. 1. Fortinets inter-VDOM routing technology is used as a mechanism to virtually route from the LAN VDOM to ROOT VDOM and vice versa. This Inter-VDOM link exists between the virtual bypass0 and bypass1 port. 2. Establish an Ethernet connection to a port on the FortiGate that belongs to the Root VDOM and another port that belongs to the LAN VDOM. Port3 of the ROOT VDOM has a physical connection that goes through the Steelheads wan0_0 interface and ends up on the LAN VDOM port4 by traversing the Steelheads lan0_0 interface. The inter-VDOM link is used to pass un-optimized traffic from the LAN to the Internet and vice versa. The physical bypass link between port3 and port4 of the FortiGate is used to pass optimized traffic from the LAN to another LAN network, perhaps through a VPN tunnel. Looking at the original topology diagram, the site-to-site VPN tunnel is terminated on the ROOT VDOM. Optimized and un-optimized WAN-to-WAN traffic traverses the tunnel. As traffic from the LAN is sent to the LAN VDOM, a routing decision is made to take the inter-VDOM path or the Steelhead path. If traffic is destined for the Internet, it is cleaned and routed out the bypass1 port towards the ROOT VDOM. If traffic is destined for another LAN, it is cleaned and routed out port4 towards the Steelhead for optimization and forwarded to the ROOT VDOM. The ROOT VDOM determines whether traffic should be sent to the Internet or through the VPN tunnel and routes it to the next hop. Bi-directional content filtering happens on the LAN VDOM between port2 to port1, port2 to port4, and vice versa. The following simplified diagram shows where firewall and content filtering policies are applied. The blue bar in the ROOT VDOM indicates that firewall and NAT takes place between bypass0 and port1.

Tests

3-15

In-Path PBR w/NAT and VPN Configurations

Since the configurations are mirrors of each other, except for IP address differences, only half of the topology configuration will be described. However, full configurations for both sides are included below as attachments.

fgt_system-3600A-in-path-pbr.conf

fgt_system-3810B-in-path-pbr.conf

steelhead-01-in-path-pbr.conf

steelhead-02-in-path-pbr.conf

All CLI configuration commands are shown, starting with the initial login prompt. Type end a few times to return to the initial login prompt. FG3810B-root VDOM On the initial Status page, click on the Enabled link next to Virtual Domain to enable VDOM features.

Log into the CLI and create the lan VDOM. The root VDOM is the default VDOM and doesnt need to be created. config vdom edit lan Enable inter-VDOM routing and create an inter-VDOM interface. Set each interface to the appropriate VDOM to which it belongs.

Tests

3-16

config global config system vdom-link edit "bypass" next end config system interface edit "bypass0" set vdom "root" set ip 10.0.7.1 255.255.255.0 set allowaccess ping set type vdom-link next edit "bypass1" set vdom "lan" set ip 10.0.7.2 255.255.255.0 set allowaccess ping set type vdom-link next end Configure port1 with the proper IP address and administrative access.

Tests

3-17

Configure ports 2-4 with IP addresses and access rights as shown.

Switch to the root VDOM.

Create an interface-based VPN tunnel to the FG3600A by clicking Create Phase 1.

Tests

3-18

Set the parameters for Phase 1. The Local Interface should be port1 -- the WAN port. Enable IPSEC Interface Mode.

Create a phase 2 by clicking on Create Phase 2.

Tests

3-19

Associate the phase 2 to the phase 1.

Create the following firewall policies by clicking on Create New. Real-world policies should be more specific to the actual source and destination IP addresses.

Tests

3-20

Here is a detailed configuration example of every firewall policy except for policy 5. Protection profiles are not enabled for any firewall policies.

Policy 5 has NAT enabled from bypass0 to port1 for Internet traffic.

Routing decisions are made based upon static routes and policy routes. Policy routes override static routes. When implementing policy-based routing, it is important to understand that the FortiGate verifies where the originating interface of the source IP address in its routing table before routing can occur across interfaces. The technical name for this check is reverse-path verify. If the FortiGate cannot verify in its routing table where the source IP address came from, it will drop the packet. To further understand this, follow the next steps.

Tests

3-21

Click on Create New to add a default route for Internet traffic, a static route to direct optimized traffic for the LAN through port3, and one to send un-optimized traffic through the bypass0 port. Additional routes are added to send traffic through the VPN tunnel towards the remote LAN. Pay attention to the pair of 10.0.1.0/24 routes. They both have the same distance of 10 but point to different gateways. Setting equal distances injects both routes into the routing table. If the distances are different, the route with the lower distance will be injected into the routing table.

Although both routes are injected into the routing table, the bypass path should still be preferred over the Steelhead path for un-optimized traffic. Setting priorities within the static routes will allow for one path to be preferred. This can be done via the CLI. Lower priorities are preferred over higher priorities. config vdom edit root config router static edit 2 set device "bypass0" set dst 10.0.1.0 255.255.255.0 set gateway 10.0.7.2 set priority 100 next edit 3 set device "port3" set dst 10.0.1.0 255.255.255.0 set gateway 10.0.5.3 set priority 110 next end The route table shows that both routes have been injected but the path with a lower priority is preferred. config vdom edit root FGT3KB3407600041 (root) # diagnose ip route list tab=254 vf=0 scope=0 type=1 proto=11 prio=100 0.0.0.0/0.0.0.0/0->10.0.1.0/24 pref=0.0.0.0 gwy=10.0.7.2 dev=22(bypass0) tab=254 vf=0 scope=0 type=1 proto=11 prio=110 0.0.0.0/0.0.0.0/0->10.0.1.0/24 pref=0.0.0.0 gwy=10.0.5.3 dev=4(port3)

Tests

3-22

To create a policy route that overrides the static route, click on the Policy Route tab, Create New and add the following policy route: protocol 0 matches every protocol. If a more specific policy route is needed, change the protocol number and destination ports. Besides the extra fields, the policy route looks similar to the static route in that both rules route traffic to 10.0.5.3. However, the policy route does not inject routes into the routing table. Only the static routes inject routes into the routing table. This is the reason why the second static route with a higher priority was added. In order to grasp the idea of reversepath verify; it is very important to understand that static routes inject routes into the routing table while policy-based routes do not inject routes into the routing table.

The following diagram illustrates the behavior of the FortiGate when it receives a packet from a foreign host on port3. It verifies that the source address is reachable through port3 by looking up the route table. If the route table does not reflect a path to the foreign host out of port3, the packet will be dropped.

Tests

3-23

Log into the CLI and set the IPSEC phase2 tunnel to automatically come up. conf vdom edit root config vpn ipsec phase2-interface edit "p2-1-3600a" set auto-negotiate enable next end

Tests

3-24

FG3810B-lan VDOM Switching to a different VDOM requires one to be in the Global configuration screen.

Switch to the LAN VDOM.

Create a firewall protection profile named protect to scan for AV and IPS threats. Other features can also be added such as anti-spam and web content filtering.

Tests

3-25

Tests

3-26

Add the following firewall policies shown below. Real-world policies should be more specific to source and destination IP addresses. All policies have NAT disabled and protection profiles enabled.

Create static routes.

Create a policy route.

Tests

3-27

Steelhead SH1020-02 Only the inpath interface is used in this scenario. The primary interface can be plugged into another port on the FortiGate for management. ## ## Network interface configuration ## no interface inpath0_0 dhcp interface inpath0_0 duplex "auto" interface inpath0_0 ip address 10.0.5.2 /24 interface inpath0_0 mtu "1500" no interface inpath0_0 shutdown interface inpath0_0 speed "auto" interface inpath0_0 txqueuelen "100" no interface lan0_0 dhcp interface lan0_0 duplex "auto" interface lan0_0 mtu "0" no interface lan0_0 shutdown interface lan0_0 speed "auto" interface lan0_0 txqueuelen "100" no interface primary dhcp no interface wan0_0 dhcp interface wan0_0 duplex "auto" interface wan0_0 mtu "0" no interface wan0_0 shutdown interface wan0_0 speed "auto" interface wan0_0 txqueuelen "100" There is a static route to force traffic destined for 10.0.1.0/24 towards the LAN VDOM. ## ## Routing configuration ## ip in-path route inpath0_0 10.0.1.0 255.255.255.0 10.0.5.3 ip in-path-gateway inpath0_0 "10.0.5.1" ## ## Other IP configuration ## hostname "sh1020-02" ## ## General Service ## in-path enable

Tests

3-28

## ## Network management configuration ## license install LK1-SH10BASE-0000-0000-1-2E65-3AB1-43AE license install LK1-SH10CIFS-0000-0000-1-9ED5-DE6E-FCE7 license install LK1-SH10EXCH-0000-0000-1-812B-C20D-1408 license install LK1-SH40SSL-0000-0000-1-710B-D6F3-6F4E username admin password 7 $1$W36wauUo$Ukm.7I2CptNpBeVJ/X39d/ web auto-logout "0"

Proving the Fortinet-Riverbed PBR Concept

To see how PBR affects traffic flow with the configurations previously outlined, packets passing through the FortiGate 3016B will be sniffed using the its built-in sniffer. Pings from 10.0.1.10 to 10.0.0.10 reveals that ICMP packets enter port2 of the LAN VDOM. The policybased route sends it out port4 toward the Steelhead and into port3 on the ROOT VDOM. The packet then heads out the VPN tunnel interface p1-3600a towards the FG-3600A. A reply from host 10.0.0.10 is received coming into the VPN tunnel interface in the ROOT VDOM, sent out port3 toward the Steelhead, received on port4 of the LAN VDOM and sent out port2 towards the requesting host 10.0.0.10. FGT3KB3407600041 (root) # diagnose sniffer packet any 'icmp and host 10.0.1.10' 4 interfaces=[any] filters=[icmp and host 10.0.1.10] 85.936009 port2 in 10.0.1.10 -> 10.0.0.10: icmp: echo request 85.936204 port4 out 10.0.1.10 -> 10.0.0.10: icmp: echo request 85.936273 port3 in 10.0.1.10 -> 10.0.0.10: icmp: echo request 85.936290 p1-3600a out 10.0.1.10 -> 10.0.0.10: icmp: echo request 85.990461 p1-3600a in 10.0.0.10 -> 10.0.1.10: icmp: echo reply 85.990491 port3 out 10.0.0.10 -> 10.0.1.10: icmp: echo reply 85.990553 port4 in 10.0.0.10 -> 10.0.1.10: icmp: echo reply 85.990582 port2 out 10.0.0.10 -> 10.0.1.10: icmp: echo reply Ping from 10.0.1.10 to 10.0.9.1 reveals that ICMP packets enter port2 of the LAN VDOM, follows the preferred static route out the bypass0 port and NAT out port1 of the Root VDOM. A reply is sent back into port1, forwarded to the bypass1 port, and sent out port2 of the LAN VDOM. FGT3KB3407600041 (root) # diagnose sniffer packet any 'icmp and host 10.0.9.1' 4 interfaces=[any] filters=[icmp and host 10.0.9.1] 2.061304 port2 in 10.0.1.10 -> 10.0.9.1: icmp: echo request 2.061304 bypass0 in 10.0.1.10 -> 10.0.9.1: icmp: echo request 2.061354 port1 out 10.0.3.2 -> 10.0.9.1: icmp: echo request 2.112901 port1 in 10.0.9.1 -> 10.0.3.2: icmp: echo reply 2.112901 bypass1 in 10.0.9.1 -> 10.0.1.10: icmp: echo reply 2.112930 port2 out 10.0.9.1 -> 10.0.1.10: icmp: echo reply

Tests

3-29

The following screenshot shows two FTP sessions established to 10.0.1.10, one session from 10.0.0.101 and one from 10.0.0.11. This time, 10.0.0.101 actually came through the Internet while 10.0.0.11 traversed the VPN.

Although the FTP sessions were established, notice only the 10.0.0.11 session was optimized. The 10.0.0.101 session is inter-VDOM routed through to the server by the FortiGate and does not show up in the Steelhead Current Connections table.

All previous tests from the In-Path Transparent topology were retested against the In-Path PBR topology. Results from the test are not shown since the results were consistent.

Tests

3-30

Chapter 4

Steelhead Features & Troubleshooting

This chapter includes the following sections: Operations Tasks

Operations Tasks
This section includes the following topics: Features Troubleshooting

Steelhead Features

4-1

Features
Connectivity Ref 0001 0002 0003 0004 0005 0006 0007 0008 0010 0011 0012 0013 0020 0021 0022 0023 Product Dependencies Does the DUT support XFP transceivers? Comment: There is an option for a two port Fiber card. Does the DUT fiber Ethernet? Comment: There is an option for a two port Fiber card. Does the DUT support 10/100 connectivity? Comment: Does the DUT support 10/100 connectivity? Comment: Does the DUT support gigabit connectivity? Comment: Does the DUT support 10 gigabit connectivity? Comment: 10 gigabit connectivity is not a requirement. Does the DUT support tri-mode copper Ethernet 10/100/1000? Comment: Does the DUT support QoS? Comment: Is the DUT capable of operating in IPv6 networks as well as maintaining a capability to operate in todays IPv4 world? Comment: Roadmap question Is the DUT capable of being deployed in a non intrusive layer two bridge mode? Comment: Does the DUT have a bypass mode to allow traffic to pass through when a system failure occurs? Comment: Does the DUT participate in 802.3ad? Comment: Does not participate in 802.3ad Does the DUT support 802.1q? Comment: Supports 4095 VLANs 0-4094 Does the DUT support Jumbo Frames? Comment: Steelhead with a gigabit Ethernet card supports Jumbo Frames on in-path and primary ports Does the DUT participate in IP Multicast? Comment: Does the DUT support BGP? Comment: Pass/Fail/NA NA Pass Pass Pass Pass NA Pass Pass NA

Pass Pass

NA Pass Pass

NA NA

Steelhead Features

4-2

0024 0025 0026 0027 0028 0029

Does the DUT support OSPF? Comment: Does the DUT support RIP? Comment: Does support static routing? Comment: Can the DUT be a DHCP server? Comment: Can the DUT be a DHCP host? Comment: Can the DUT be a DHCP relay? Comment:

NA NA Pass NA Pass NA

Management Integration Ref Product Dependencies Does the DUT have a Command Line Interface? 0030 Comment: Can the DUT be remotely accessed via Telnet? 0031 Comment: Can the DUT be remotely accessed via SSH? 0032 Comment: Can the DUT be remotely accessed HTTP? 0033 Comment: Can the DUT be remotely accessed HTTPS? 0034 Comment: Does the DUT have local authentication policy Control? 0035 Comment: Is the DUT able to protect itself from unknown attempts through IP access restriction? 0036 Comment: The DUT has no IP restrictions mechanism. Access is either allowed or disallowed based upon username and password information.

Pass/Fail/NA Pass Pass Pass Pass Pass Pass Fail

VPN Ref 0037 0038 0039 0040 0041 0042

Product Dependencies IPSEC Site-to-Site Connectivity Comment: Does the DUT support DES? Comment: Does the DUT support 3DES? Comment: Not supported Does the DUT support AES? Comment: Not supported Can the DUT be remotely accessed HTTPS? Comment: Does the DUT support MD5 Authentication? Comment:

Pass/Fail/NA Pass Pass NA NA Pass Pass

Steelhead Features

4-3

0043 0044

Does the DUT support SHA-1 Authentication? Comment: Does the DUT support IKE Certification Authentication? Comment:

Pass NA

Authentication Ref Product Dependencies Does support Local Authentication? 0045 Comment: Does the DUT support RADIUS Authentication? 0046 Comment: Does the DUT support TACACS+ Authentication? 0047 Comment: Does the DUT support Windows Active Directory Authentication? 0048 Comment: Does the DUT support LDAP? 0049 Comment: Does the DUT support PKI Authentication? 0050 Comment: Does the DUT support RSA (X.509 Certificates)? 0051 Comment:

Pass/Fail/NA Pass Pass Pass NA NA NA NA

Log and Reporting Ref Product Dependencies Does the DUT support logging to a Syslog server? 0052 Comment: Does the DUT support SNMP v1? 0053 Comment: Does the DUT support SNMP v2c? 0054 Comment: Does the DUT support SNMP polling of Port Statistics? 0055 Comment: Does the DUT support SNMP polling of CPU Statistics? 0056 Comment: Does the DUT support SNMP polling of Memory Statistics? 0057 Comment: Does the DUT support RSA (X.509 Certificates)? 0058 Comment:

Pass/Fail/NA Pass Pass Pass Pass Pass Pass NA

Steelhead Features

4-4

Steelhead Features

4-5

Part 4

Summary

This part provides the overall experience of testing the Riverbed Steelhead 1020 appliance in conjunction with Fortinet FortiGate UTM devices. This part consists of the following chapters: Chapter 1, Evaluation

Chapter 5

Evaluation
The Riverbed Steelhead 1020 appliance operates remarkably well in conjunction with Fortinet FortiGate UTM devices. The FortiGate firewalls are leveraged to police the network by preventing malicious data from being sent to the Steelhead units while good data is optimized and accelerated. The coupling of these two technologies, notably showcased in the PBR configuration, essentially creates a smarter and faster network. Both vendors have developed a mature CLI and user-friendly WebUI management interface with excellent debugging and reporting tools to prove the technology. In lab tests, the Steelhead successfully optimized traffic as advertised. Major improvements in bandwidth savings were observed on egress traffic which equates to a significant reduction in expenditure on costly WAN links. It is important to keep in mind that under certain circumstances, WAN optimization may not play a large factor in reducing WAN congestion. For instance, if the congestion is attributed to VoIP traffic or other protocols that cannot be optimized. Riverbeds support service is first-class, boasting a knowledgeable, high English proficiency, and friendly support staff. At all hours of the day, it never took more than a minute or two for a live person to answer. After a trouble ticket had been created, a support engineer was immediately engaged.

Summary

5-1

Below is a high-level diagram of a typical deployment in enterprise networks using best-of-breed point solutions for their security and application acceleration requirements. The FortiGate and Steelhead devices consolidate this architecture by integrating the multiple features onto one platform which greatly enhances the performance while reducing the complexity of deploying, managing, and maintaining the network, thus resulting in significant CAPEX and OPEX benefits.

Traditional ROBO to Enterprise Architecture

(Point-based Solutions)
INTERNET REMOTE

ROUTER FIREWALL FIREWALL BANDWIDTH SHAPER QoS MANAGER

BANDWIDTH SHAPER QoS MANAGER

VPN

HOME OFFICE

IPS

BRANCH OFFICE

ANTIVIRUS

URL FILTERS

SALES CORPORATE LAN

ENGINEERING

CORPORATE OFFICE FINANCE SECURE VOIP

Fortinet Confidential - Internal Use Only

Summary

5-1

Below is a high-level diagram of a sample deployment of the devices configured in an in-path transparent topology. This is the most straight-forward deployment option for a two-box joint solution; however, the WAN optimization of site-to-site VPN traffic will be not be optimal since the VPN tunnels carry encrypted traffic.

ROBO to Enterprise Architecture

(Joint Fortinet + Riverbed Solution)
INTERNET REMOTE ROUTER

Riverbed devices traditionally sits at the perimeter of every deployment and optimizes the behavior of applications and protocols without using proprietary protocols to improve WAN utilization.

RIVERBED STEELHEAD 1

RIVERBED STEELHEAD 2

HOME OFFICE DMZ 1

RIVERBED STEELHEAD 3 DMZ 2

BRANCH OFFICE

WEB / EMAIL SERVERS

VOIP CALL MANAGER

FortiGate appliances deployed at the perimeter filters and blocks unwanted outbound data from being optimized by Steelhead devices.
SALES CORPORATE LAN ENGINEERING

CORPORATE OFFICE FINANCE SECURE VOIP

Fortinet Confidential - Internal Use Only

Summary

5-1

Below is a high-level diagram of a sample deployment of the devices configured in an in-path PBR topology. This is a highly-optimized and complex deployment but truly demonstrates the ability of the advanced configurations of the FortiGate to enable the full UTM security suite operating in conjunction with Riverbeds wide-area data services. This architecture provides compelling value to the customer by delivering comprehensive security features without the need for multiple security devices and allows the performance bottleneck to be shifted to the high-capacity FortiGate platforms by redirecting only optimizable traffic to the Steelhead appliance. By comprehending the two disparate technologies in painstaking detail and through weeks of rigorous and thorough testing, we have conceived and validated this scenario in a lab environment which we believe is the silver bullet that can be translated to a realworld deployment, providing the full benefits of the market-leading UTM and WDS technologies without dependence on a third-party device to support WCCP or L4 switching.

ROBO to Enterprise Architecture

(out-of-path deployment)
INTERNET REMOTE ROUTER

In this scenario, policy-based routing (PBR) is required to redirect optimizable traffic to the Steelhead unit. At the corporate office, the FG is configured as a virtual FW/VPN in front of the Steelhead device and a virtual UTM behind it, where traffic that is not optimized is passed through the inter-VDOM path.

RIVERBED STEELHEAD

RIVERBED STEELHEAD

HOME OFFICE

BRANCH OFFICE

RIVERBED STEELHEAD

SALES CORPORATE LAN

ENGINEERING

CORPORATE OFFICE FINANCE SECURE VOIP

Fortinet Confidential - Internal Use Only

Summary

5-1