Fortinet Riverbed For Ti Verified v2

High Performance Multi-Threat Security Solutions

FortiVerified FortiVerified

Riverbed Steelhead 1020 & FortiGate MR5 Compatibility Testing

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

http://www.fortinet.com/

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

Introduction 1-1

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 Fortinet’s 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 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 auto-discovery 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 "[email protected]" email notify failures recipient "[email protected]" 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 policy-based 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, let’s 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. Fortinet’s 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 Steelhead’s wan0_0 interface and ends up on the LAN VDOM port4 by traversing the Steelhead’s 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 doesn’t 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 reverse- path 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 policy-based 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

This section includes the following topics:

• Features • Troubleshooting

Steelhead Features 4-1

Features Connectivity Ref Product Dependencies Pass/Fail/NA

0001 Does the DUT support XFP transceivers? Comment: There is an option for a two port Fiber card.

NA

0002 Does the DUT fiber Ethernet? Comment: There is an option for a two port Fiber card.

Pass

0003 Does the DUT support 10/100 connectivity? Comment:

Pass

0004 Does the DUT support 10/100 connectivity? Comment:

Pass

0005 Does the DUT support gigabit connectivity? Comment:

Pass

0006 Does the DUT support 10 gigabit connectivity? Comment: 10 gigabit connectivity is not a requirement.

NA

0007 Does the DUT support tri-mode copper Ethernet 10/100/1000? Comment:

Pass

0008 Does the DUT support QoS? Comment:

Pass

0010 Is the DUT capable of operating in IPv6 networks as well as maintaining a capability to operate in today’s IPv4 world? Comment: Roadmap question

NA

0011 Is the DUT capable of being deployed in a non intrusive layer two bridge mode? Comment:

Pass

0012 Does the DUT have a bypass mode to allow traffic to pass through when a system failure occurs? Comment:

Pass

0013 Does the DUT participate in 802.3ad? Comment: Does not participate in 802.3ad

NA

0020 Does the DUT support 802.1q? Comment: Supports 4095 VLANs 0-4094

Pass

0021 Does the DUT support Jumbo Frames? Comment: Steelhead with a gigabit Ethernet card supports Jumbo Frames on in-path and primary ports

Pass

0022 Does the DUT participate in IP Multicast? Comment:

NA

0023 Does the DUT support BGP? Comment:

NA


0024 Does the DUT support OSPF? Comment:

NA

0025 Does the DUT support RIP? Comment:

NA

0026 Does support static routing? Comment:

Pass

0027 Can the DUT be a DHCP server? Comment:

NA

0028 Can the DUT be a DHCP host? Comment:

Pass

0029 Can the DUT be a DHCP relay? Comment:

NA

Management Integration Ref Product Dependencies Pass/Fail/NA

0030 Does the DUT have a Command Line Interface? Comment:

Pass

0031 Can the DUT be remotely accessed via Telnet? Comment:

Pass

0032 Can the DUT be remotely accessed via SSH? Comment:

Pass

0033 Can the DUT be remotely accessed HTTP? Comment:

Pass

0034 Can the DUT be remotely accessed HTTPS? Comment:

Pass

0035 Does the DUT have local authentication policy Control? Comment:

Pass

0036

Is the DUT able to protect itself from unknown attempts through IP access restriction? Comment: The DUT has no IP restrictions mechanism. Access is either allowed or disallowed based upon username and password information.

Fail

VPN Ref Product Dependencies Pass/Fail/NA

0037 IPSEC Site-to-Site Connectivity Comment:

Pass

0038 Does the DUT support DES? Comment:

Pass

0039 Does the DUT support 3DES? Comment: Not supported

NA

0040 Does the DUT support AES? Comment: Not supported

NA

0041 Can the DUT be remotely accessed HTTPS? Comment:

Pass

0042 Does the DUT support MD5 Authentication? Comment:

Pass


0043 Does the DUT support SHA-1 Authentication? Comment:

Pass

0044 Does the DUT support IKE Certification Authentication? Comment:

NA

Authentication Ref Product Dependencies Pass/Fail/NA

0045 Does support Local Authentication? Comment:

Pass

0046 Does the DUT support RADIUS Authentication? Comment:

Pass

0047 Does the DUT support TACACS+ Authentication? Comment:

Pass

0048 Does the DUT support Windows Active Directory Authentication? Comment:

NA

0049 Does the DUT support LDAP? Comment:

NA

0050 Does the DUT support PKI Authentication? Comment:

NA

0051 Does the DUT support RSA (X.509 Certificates)? Comment:

NA

Log and Reporting Ref Product Dependencies Pass/Fail/NA

0052 Does the DUT support logging to a Syslog server? Comment:

Pass

0053 Does the DUT support SNMP v1? Comment:

Pass

0054 Does the DUT support SNMP v2c? Comment:

Pass

0055 Does the DUT support SNMP polling of Port Statistics? Comment:

Pass

0056 Does the DUT support SNMP polling of CPU Statistics? Comment:

Pass

0057 Does the DUT support SNMP polling of Memory Statistics? Comment:

Pass

0058 Does the DUT support RSA (X.509 Certificates)? Comment:

NA


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. Riverbed’s 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.

Fortinet Confidential - Internal Use Only

Traditional ROBO to Enterprise Architecture(Point-based Solutions)

CORPORATELAN

FINANCE SECURE VOIP

ENGINEERINGSALES

INTERNET

BRANCH OFFICE

REMOTE

HOME OFFICE

ROUTER

CORPORATE OFFICE

FIREWALLFIREWALL

QoS MANAGER QoS MANAGER

BANDWIDTH SHAPER

VPN

IPS

ANTIVIRUS

URL FILTERS

BANDWIDTH SHAPER

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)

RIVERBEDSTEELHEAD 1

RIVERBEDSTEELHEAD2

RIVERBEDSTEELHEAD 3

CORPORATELAN

FINANCE SECURE VOIP

ENGINEERINGSALES

INTERNET

WEB / EMAILSERVERS

VOIP CALLMANAGER

BRANCH OFFICE

REMOTE

HOME OFFICE

ROUTER

DMZ 1 DMZ 2

CORPORATE OFFICE

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

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.

Summary 5-1

Summary

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 Riverbed’s 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 real-world 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)

RIVERBEDSTEELHEAD

RIVERBEDSTEELHEAD

RIVERBEDSTEELHEAD

CORPORATELAN

FINANCE SECURE VOIP

ENGINEERINGSALES

INTERNET

BRANCH OFFICE

REMOTE

HOME OFFICE

ROUTER

CORPORATE OFFICE

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.

5-1

Fortinet Riverbed For Ti Verified v2

Documents

Transcript of Fortinet Riverbed For Ti Verified v2