Brksec 2020

#CLUS
Firepower NGFW
Deployment
in the Data Center and Enterprise
Network Edge Using FTD
Steven Chimes, Consulting Systems Engineer
BRKSEC-2020
#CLUS
Agenda
• Deploy L3 Firewalls at the Edge
• Interfaces, Routing & NAT
• NGFW Policy Tips/SSL Decrypt
• High Availability
• Deploy L2 Firewalls in the DC

• Clustering
• Alternative Designs
• Flow Bypass
#CLUS BRKSEC-2020 © 2018 Cisco and/or its affiliates. All rights reserved. Cisco Public 3
Cisco Webex Teams
Questions?
Use Cisco Webex Teams (formerly Cisco Spark)
to chat with the speaker after the session
How
1 Find this session in the Cisco Events App
2 Click “Join the Discussion”
3 Install Webex Teams or go directly to the team space
4 Enter messages/questions in the team space
Webex Teams will be moderated cs.co/ciscolivebot#BRKSEC-2020

by the speaker until June 18, 2018.
Cisco Firepower Sessions: Building Blocks
Monday Tuesday Wednesday Thursday
BRKSEC-2031 BRKSEC-2064
08:00
08:00
08:00
13:00 10:30 08:30 08:00

ASA Fleet NGFWv and ASAv
Firepower Platform NGFW Clustering
Management at in Public Cloud
Deep Dive Deep Dive
Scale (AWS and Azure)
BRKSEC-3030
Advanced
Firepower IPS
Deployment
13:30 10:30
Dissecting Firepower Optimizing Your
Installation & Firepower/FTD
Troubleshooting Deployment
13:30
BRKSEC-2058
Firepower NGFW Firepower NGFW
Deep Dive into
Internet Edge Internet Edge
Firepower Manager
Deployment Deployment
#CLUS BRKSEC-2020 © 2018 Cisco and/or its affiliates. All rights reserved. Cisco Public
In
Depth
After the Session

Whisper Suites
or MTE
Reference
CLINET (clinet.com)
Cisco LIVE Information Networking Company
• CLINET (clinet.com) is a fictional company created for
understanding use cases in FTD firewall deployment.
• CLINET has embarked on a network/security deployment project entitled
“The Security 20/20 Project” which serves as the basis for the use case.
• There
Company are ~100
requirements and slides we examples
configuration will not are
cover
based upon
real-life customer conversations and deployments.
today
They are included for additional detail

and reference back at home
Reference
Cisco Firepower NGFW

Reference
Firepower Threat Defense (FTD) Software
Firepower (L7) Firepower Threat Defense

• Threat-Centric NGIPS
• AVC, URL Filtering for NGFW Full Feature Set Single Converged OS
• Advanced Malware Protection
ASA (L2-L4)
• L2-L4 Stateful Firewall
• Scalable CGNAT, ACL, routing Continuous Feature Firewall URL Visibility Threats
• Application inspection Migration
Firepower Management
Centre (FMC)*
* Also manages Firepower Appliances and FirePOWER Services (not ASA Software)
Reference
Cisco Firepower NGFW Product Family

Running Firepower Threat Defense (FTD)
Firepower 9300
Performance and Scalability
(SM-24, SM-36, SM-

44)
Firepower 4140
Firepower 4150
Firepower 2110
Firepower 2120
Firepower 2130 Firepower 4110
ASA 5525-X Firepower 2140 Firepower 4120
ASA 5545-X
ASA 5506H-X ASA 5516-X ASA 5555-X
ASA 5508-X ASA 5515-X
ASA 5506W-X ASA 5512-X
ASA 5506-X
FTDv
SMB & Distributed Enterprise Commercial & Enterprise Data Centre & Service Provider
FTD Initial Setup
New in 6.2.3! Reference
Single hop upgrade

Installing Firepower Threat Defense
Management Centre Smart License FTD on FP4100/FP9300
Firepower Firepower FTD 6.1

1. Management
2. Management 3.
Centre 6.1 Centre 6.2.3 FXOS 2.2.1.x
Single Hop Single Hop

Upgrade or Register Upgrade or
Install Reimage
Firepower FTD 6.2.3

Cisco Smart
Management
Software Manager
Centre 6.2.3 FXOS 2.3.1.x
FXOS 2.2.1.x
FMC Installation Guide: http://www.cisco.com/c/en/us/td/docs/security/firepower/hw/firepower_management_center/management_center/installation.html

FTD Quick Start Guides: http://www.cisco.com/c/en/us/support/security/firepower-ngfw/products-installation-guides-list.html
Management Connections
ASA 5506 – 5555 / Firepower 2100 (1 Management)
FTD Management Inside
Outside
Management interfaces can be placed
on the same subnets as data interfaces
Firepower 4100 / Firepower 9300 (2 Management)

Chassis Management Inside
Outside FTD Management
Suggested Version: FTD 6.2.3.X
FTD 6.2.3 (now 6.2.3.1) – “FTD SP1”
FTD 6.2.0.2 Policy Apply Improvements FTD 6.2.2 Policy Apply Improvements
• Introduced snort preserve-connection • Accelerated policy deployment
• Preserves existing connections on routed and • Eliminated most Snort restarts due to
transparent interfaces if the Snort process reconfiguration (e.g. changing AMP policy)
goes down
• Eliminated most Snort restarts due to memory
• Preserved connections must not be tunneled reallocation (e.g. enabling/disabling AMP)
or proxied (e.g. SSL decrypt, Safe Search)
Hardening/Extended QA Single Hop Upgrades TLS Hardware Acceleration

Warning on policy apply that will cause Snort to restart (e.g. enable HA, MTU change)
Latest Compatible FXOS Version (now 2.3.1.75)

Cisco FXOS Compatibility: https://www.cisco.com/c/en/us/td/docs/security/firepower/fxos/compatibility/fxos-compatibility.html
FTD Licensing Tips
• All licensing for FTD are installed and
enforced on the Firepower
Management Centre via Smart
Licensing
• Licenses are transferrable between
firewalls of the same model
• Licensing is enforced when the policy
is pushed
• 90 day “Evaluation Mode” applies to
all FTD devices managed by that FMC
Reference
Deploying Changes
Changes don’t take affect until you deploy the policy
Reference
Deploying Changes
Changes don’t take affect until you deploy the policy
Enable to add column to

show if traffic interruption will
occur during policy deploy
Reference
Management Connections
• FTD is managed by FMC through a management interface.
• Management interface is used only for management and eventing.
• Can be on the same subnet as a data interface or on separate subnet.
• Usually is placed on the same subnet as the inside interface.
• Management interfaces are not shown on diagrams, but are present.
Centre (FMC)
Layer-2 Switch FTD Inside

Outside
FTD Management
Chassis Management
(FP4100/FP9300)
Reference
FTD Initial Setup –
FTD Console on Firepower 2100
• Initial setup through console interface is prompted. Default
username/password is admin/Admin123
Cisco Firepower 2140 Threat Defense v6.2.1 (build 10223)
firepower login: admin
Password: Admin123
• Connect to the Firepower Threat Defense Application

firepower #: connect ftd
• Prompts to configure admin password, management (IPv4 and/or IPv6),

etc.
You must change the password for 'admin' to continue.
<snip>
You must configure the network to continue.
<snip>
Reference
FTD Initial Setup – FTD Console

• 5506 – 5555 and FP2100 include an easy to use/simplistic local manager.
• Local manager only manages local appliance (not HA pair).
• For the use case, CLINET is using FMC for central management.
Manage the device locally? (yes/no) [yes]: no
• Firewall mode is one of the few features configured locally. We will cover modes in
more detail later on.
Configure firewall mode? (routed/transparent) [routed]:
• Connection to FMC must be preconfigured on FTD, single line command.

• Registration key can be any string you want – just remember it!
configure manager add [hostname | ip address ] [registration key ]
Reference
FTD Initial Setup – Adding a Device to FMC
Either hostname
or IP address
Registration key
we used in CLI Add device
drop down
Select based upon Previously configured

subscriptions Access Control Policy
purchased or create a new one
Firewall Deployment
Mode & Interfaces
Firewall Design: Modes of Operation
• Routed Mode is the traditional mode of the firewall. Two or more 10.1.1.0/24
interfaces that separate L3 domains – Firewall is the Router and 10.1.1.1
Gateway for local hosts.
NAT
DRP
192.168.1.1
192.168.1.0/24
IP:192.168.1.100
GW: 192.168.1.1
Firewall Design: Modes of Operation 192.168.1.1
• Routed Mode is the traditional mode of the firewall. Two or more

interfaces that separate L3 domains – Firewall is the Router and VLAN192
Gateway for local hosts.
• Transparent Mode is where the firewall acts as a bridge
functioning at L2.
• Transparent mode firewall offers some unique benefits in the DC. VLAN1920
• Transparent deployment is tightly integrated with our ‘best practice’
data center designs. 192.168.1.0/24
• Integrated Routing and Bridging (IRB) allows a firewall to both

route and bridge for the same subnet. IP:192.168.1.100
GW: 192.168.1.1
• Available in Routed Mode when standalone or HA pair
• Not currently supported with Clustering
• Useful for micro-segmentation and switching between interfaces
FTD Security Zones
• True zone based firewall
• Security Zones are collections of interfaces or sub-interfaces
• Policy rules can apply to source and/or destination security zones
• Security levels are not used
Routed/Transparent Interface Types
Standalone Interface Redundant Interface EtherChannel Interface
#3 #2 #1
Choice Choice Choice
• All platforms • 5506 – 5555 only • All platforms

• No redundancy • One active, one passive • Up to 16 active links
• Simple • No special switch • Requires stack, VSS or
requirements vPC when connected to
multiple switches
Reference
Basic Interface Configuration

Just an example – Final config will be different once redundancy is added
Reference
Basic Interface Configuration

Interface in RED
Just an example – final config will be different
once redundancy is added
ISP-A ISP-B
Edge
Aggregation
DMZ Network(2)
(Public Web/DB)
G1/1
VPC VPC
Edge Aggregation
VDC
Reference
Deploying the Redundant Outside Interfaces

Edge Use Case Supported on the
5506 – 555 only
outside
ISP-A ISP-B
Edge
Aggregation
DMZ Network(2)
(Public Web/DB)
G1/1 G1/2
VPC VPC
Edge Aggregation
VDC
Reference
Deploying the Redundant DMZ Interfaces

Will use sub-interfaces to accommodate the 2 VLANs
ISP-A ISP-B
No security
Edge
zone this time Aggregation
DMZ Network(2)
(Public Web/DB)
GigabitEthernet1/3
GigabitEthernet1/4 G1/3 VLAN

VLAN 150
150
VLAN
trunk
trunk
VLAN 151
G1/4 151
VPC VPC
No IP either Edge Aggregation

VDC
Reference

ISP-A ISP-B
Edge
Aggregation
DMZ Network(2)
(Public Web/DB)
G1/3 VLAN
150
VLAN
trunk
G1/4 151
VPC VPC
Edge Aggregation
VDC
Repeat 1x for VLAN 151
Reference

ISP-A ISP-B
Edge
Aggregation
DMZ Network(2)
(Public Web/DB)
G1/3 VLAN
150
VLAN
trunk
G1/4 151
VPC VPC
Edge Aggregation
VDC
Reference
What is an EtherChannel?
• EtherChannel LAG (IEEE standard is 802.3ad) allows up
to 16 physical Ethernet links to be combined into one
logical link. 16 links can be active and forwarding data.
• Ports must be of same capabilities: duplex, speed, type, etc.
• Benefits of EtherChannel are increasing scale, load-
balancing and HA
• Load balancing is performed via a load-balancing hashing
algorithm (src-dst-ip, src-dst-ip-port, etc.) LACP Load Balance
src-dst-IP (hash)
• EtherChannel uses LACP (Link Aggregation Control
Protocol) to allow dynamic bundling and dynamic
recovery in case of failure
• Static LAG can be used on non-FXOS platforms, but should
be aware of potential traffic black holes this may cause
Reference
What is a vPC EtherChannel?

• vPC (like VSS) is known as Multi-Chassis EtherChannel
• Virtual Port Channels (vPC) are common EtherChannel
deployments, especially in the data center, and allow
multiple devices to share multiple interfaces 20G
• All links are active – no STP blocked ports
• A vPC Peer Link is used on Nexus devices to instantiate 10G

the vPC domain and allow sharing 10G
• Peer Link synchronizes state between vPC peers
• vPC can maximize throughput since each port channel is treated LACP Load Balance
src-dst-IP (hash)
as a single link for spanning-tree purposes
• Spanning Tree is not disabled, but does not affect the network
• vPC White paper:

http://www.cisco.com/c/dam/en/us/td/docs/switches/datacenter VPC PEER LINK
/sw/design/vpc_design/vpc_best_practices_design_guide.pdf
EtherChannel on FTD
• Supports 802.3ad and LACP standards
Single • Direct support for vPC/VSS
• FP2100/FP4100/FP9300 require LACP (“On” mode is not
or supported)
Stack • Up to 16 active links
• 100Mb, 1Gb, 10Gb, 40Gb are all supported – must match
• Supported in all modes (transparent and routed)

• Redundant interface and LAG on FTD are mutually
VSS exclusive
or • FXOS EtherChannels have the LACP rate set to
vPC normal by default.
• Recommended to change to fast when clustering
• https://www.cisco.com/c/en/us/td/docs/security/firepow
er/fxos/clustering/ftd-cluster-solution.html
Reference
Deploying the Inside Interfaces with EtherChannel

We will use sub-interfaces to accommodate the 3 internal VLANs
Call it bob if
you want
No security zone on
the port-channel
because we are using
sub-interfaces
No IP
Reference

Same security zone can

be assigned to multiple
different firewalls
VLAN 120
Repeat 2x for VLAN 2 and VLAN 1299
Reference

Reference

Routing on FTD
Reference
FTD Packet Processing Flow
Routing on FTD
• FTD performs L3 route lookup as part of its normal packet processing flow Outside Network
• FTD is optimized as a flow-based inspection device

FHRP 128.107.1.1
• For smaller deployments, FTD is perfectly acceptable as the router
• For larger deployments, a dedicated router (ISR, ASR, Nexus) is a much better
option. G1/1 DMZ Network
• FTD may originate routes depending on the network design Static Default
G1/3
• FTD Supports static routing and most IGP routing protocols:
• BGP-4 with IPv4 & IPv6 (aka BGPv4 & BGPv6) Static or IGP
G1/2
• OSPFv2 & OSPFv3 (IPv6)
• RIP v1/v2 Inside 10.120.1.0/24
• Multicast
• EIGRP (via FlexConfig)
• Complete IP Routing config:
http://www.cisco.com/c/en/us/td/docs/security/firepower/601/configurati Inside Network
on/guide/fpmc-config-guide-v601.pdf
BGP
• FTD supports BGPv4 with IPv4 and IPv6 for dynamic routing across all platforms
• Standard communities / all path attributes, route redistribution; up to 100K prefixes and 2K neighbors
• Null0 and Remotely-Triggered Black Hole (RTBH) support
• Confederations, route reflectors, tagging, neighbor source-interface, and BFD are not supported
• BGP RIB is replicated in failover along with other protocols
Reference
Non Stop Forwarding (NSF)

• Routing Information Base is replicated in failover mode
• Active unit or master establish dynamic routing adjacencies and keep standby up-to-date
• When the active unit fails, the failover pair continue traffic forwarding based on RIB
• New active unit re-establish the dynamic routing adjacencies and update the RIB
• Adjacent routers flush routes upon adjacency re-establishment and cause momentary traffic blackholing
• Non Stop Forwarding (NSF) and Graceful Restart (GR) support in FTD:
• Cisco or IETF compatible for OSPFv2, OSPF3; RFC 4724 for BGPv4
• FTD notifies compatible peer routers after a switchover in failover
• FTD acts as a helper to support a graceful or unexpected restart of a peer router in all modes
1. Active FTD fails over to standby; newly active 2. Router re-establishes OSPF adjacency with the
unit initiates OSPF adjacency with the router OSPF FTD while retaining the stale routes; these routes
indicating that traffic forwarding should continue. are refreshed when the adjacency reestablishes.
4. FTD continues normal traffic forwarding until the 3. Primary Route Processor undergoes a restart,
primary RP restarts or the backup takes over or the OSPF signals the peer FTD to continue forwarding while
timeout expires. Forwarding Plane the backup re-establishes adjacencies.
Reference
FTD Routing – Static Use Case

Equivalent to
route outside 0.0.0.0 0.0.0.0 128.107.1.1
Reference
FTD Routing – Dynamic Use Case

Step 1 – Enable the OSPF Process
Reference

Step 2 – Add an Area
Next slide is from

redistribution tab
Reference

Step 3 – Add Redistribution
NAT on FTD
Reference
NAT on FTD
• NAT on FTD is built around objects, with two types of NAT:
• Auto NAT – Only source is used as a match criteria
• Only used for static or dynamic NAT
• When configuring, it is configured within a network object (internally)
• Device automatically orders the rules for processing:
• Static over dynamic
• Quantity of real IP addresses – from smallest to largest
• IP address – from lowest to highest
• Name of network object – in alphabetical order
• Manual NAT – Source (and possibly destination) is used as a match criteria

• More flexibility in NAT rules (one-to-one, one-to-many, many-to-many, many-to-one)
• Supports NAT of the source and destination in a single rule
• Only the order matters for processing
NAT on FTD Processing
• Single NAT rule table (matching on a first match basis).
• Uses a simplified “Original Packet” to “Translated Packet” approach:
Manual NAT
• NAT is ordered within 3 sections.

• Section 1 – NAT Rules Before (Manual NAT)
• Section 2 – Auto NAT Rules (Object NAT)
• Section 3 – NAT Rules After (Manual NAT – Not Typically Used)
Reference
Auto NAT Use Case

Dynamic NAT translation of 10.120.1.0/24 to the using Interface PAT
Reference
Auto NAT Use Case

Static NAT translation of 172.16.25.200 to a public IP of 128.107.1.200
Reference
Auto NAT Use Case

Dynamic NAT translation of 10.120.1.0/24 to 128.107.1.10-128.107.1.20
Manual NAT Use Case
Static NAT 192.168.1.10  192.168.1.155 to 128.107.1.242  128.107.1.155
Reference
Sample NAT Policy
Easy to understand
NAT logic
Manual NAT Rules
Auto NAT Rules
FTD NGFW Policy Tips
Reference
Reference
NGFW Policy Types in FTD

Policy Type Function
Access Control Specify, inspect and log network traffic
Intrusion Inspect traffic for security violations (including block or alter)
Malware & File Detect and inspect files for malware (including block)
SSL Inspect encrypted traffic (including decrypt and block)
DNS Controls whitelisting or blacklisting of traffic based on domain
Identity Collect identity information via captive portal
Prefilter Early handling of traffic based L1-L4 criteria
Reference
Access Control Policy Overview

• Controls what and how traffic is allowed, blocked, inspected and logged
• Simplest policy contains only default action:
• Block All Traffic
• Trust All Traffic – Does not pass through Intrusion and Malware & File inspection
• Network Discovery – Discovery applications, users and devices on the network only
• Intrusion Prevention – Using a specific intrusion policy
• Criteria can includes zones, networks, VLAN tags, applications, ports, URLs and
SGT/ISE attributes
• The same Access Control Policy can be applied to one or more device
• Complex policies can contain multiple rules, inherit settings from other access
control policies and specify other policy types that should be used for inspection
Reference
Access Control Policy Use Case #1

Allow MS SQL from inside to pubdmz
Disables further inspection /

pushes rules to hardware on
FP4100/9300 if Security
Intelligence is disabled.
Rules below are

still processed
Displays block
page over HTTP
Reference

Determines if rule can be

overridden by child policy
Use zones rather than IPs

whenever possible to make
your policy more flexible
Reference
Access Control Policy Use Case #1 –
Applications
Access Control Policy Use Case #1 – Logging Tab
Logging will increase the number

of events the FMC must handle.
Be sure to consider your logging
requirements before logging
connection events to the FMC
Logging Considerations for Large Deployments
Americas – DC #1
Americas – DC #2
1 FP4150 = 200K CPS
EMEA – DC #1
Policy With Full Logging:
EMEA – DC #2 10x FP4150s = 2M EPS 1x FMC4500
Rated for 20K EPS
APJC – DC #1
Total = 10x FP4150s
Logging Design for Large Deployments
FTD FMC
Security Events Security Events SEIM
Syslog or eStreamer
Connection Events
Syslog
Uncheck - Security events

are always sent to FMC
Check to enable syslog directly from FTD
Reference
Access Control Policy Use Case #2 – Introduction

CLINET requirements:
• Allow all outbound HTTP/HTTPS traffic, regardless of port
• Perform IDS inspection of the traffic (with all Chrome rules enabled)
• Block any malware
• Block any HTTPS connections that use a self-signed certificate
• Policies we’ll need to create:

1. Intrusion Policy
2. Malware & File Policy
3. SSL Policy
Reference
For more, check out :
Intrusion Policy Overview

BRKSEC-3300
Advanced IPS Deployment
• Controls how IDS or IPS inspection is performed on network traffic

• Simple policy inherits settings from 1 of 5 Cisco Talos maintained base policies:
• Balanced Security and Connectivity – Default and recommended
• Connectivity Over Security – Fewer rules enabled, only most critical rules block
• Maximum Detection – Favors detection over rated throughput
• No Rules Active
• Security Over Connectivity – More rules enabled, deeper inspection
• Individual rules can be set to generate events, drop and generate events, or disabled
• Layers allow for grouping of settings/rules for easier management
• Complex policies can contain multiple layers and multiple levels of inheritance
Reference
Intrusion Policy for Use Case #2

Detection Only (No Inline Blocking) + Alert on Chrome Attacks
Reference
Intrusion Policy for Use Case #2

IDS  Drop when Inline unchecked

IPS  Drop when Inline checked
Reference
Intrusion Policy for Use Case #2 – Rules Menu

Freeform search
Selecting browser-chrome
populates the appropriate
filter in the filter bar
Reference

Reference

The rules are

now enabled
Reference
Malware & File Policy Overview

• Controls what and how files are allowed, blocked and inspected
• Simple policy applies the same action (e.g. Block Malware) to all files
• Actions are:
• Detect Files – Detect and log the file transfer, perform no inspection
• Block Files – Block and log the file transfer, perform no inspection
• Malware Cloud Lookup – Inspect the file to determine disposition (Malware, Unknown or
Clean) and log
• Block Malware – Inspect the file to determine disposition, log and block if Malware
• Inspection includes static analysis of the file (via Spero), dynamic analysis (via AMP
Threat Grid) and local analysis (via ClamAV)
• Complex policies can include different actions and levels of inspections for different
application protocols, directions and file types.
Reference
Malware & File Policy Overview

Blocks all files matching Stores files on
policy file type(s) sensor for further
investigation by
analyst
Detection only
(no blocking)
Reference
Malware & File Policy for Use Case #2

Block malicious Office, Executable and PDF files transferred over HTTP
Reference

Blocks all files matching

policy file type(s)
Detection only
(no blocking)
Reference

Stores files on
sensor for further
investigation by
analyst
Spero = Static Analysis via ML
Dynamic Analysis = Upload of

the file to the cloud for analysis
Capacity Handling = Store file

and resubmit if file submission
limit exceeded
Local Malware Analysis = Local

ClamAV signature scanning
Reference

Reference
Malware & File Policy for Use Case #2 – Rule
Added
Add more rules

as needed
Rule we just
created
Reference
SSL Policy Overview

• Controls how and what encrypted traffic is inspected and decrypted
• Simple policy blocks all encrypted traffic that uses a self-signed certificate
• Actions are:
• Decrypt - Resign – Used for SSL decryption of public services (Google, Facebook, etc.)
• Decrypt - Known Key – Used when you have the certificate’s private key
• Do not decrypt
• Block
• Block with reset
• Monitor
• Many actions can be taken on encrypted traffic without decryption by inspecting the
certificate, distinguished name (DN), certificate status, cipher suite and version (all
supported by FTD)
SSL Decrypt
Technically TLS, but is called SSL throughout the product
• SSL decryption consists of three
components (simplistically):
Session Setup Application Data
• TLS Proxy
Encrypt/Decrypt Encrypt/Decrypt
• Session Setup Encrypt/Decrypt (Asymmetric Key) (Symmetric Key)
• Application Data Encrypt/Decrypt
TLS Proxy
• TLS Proxy is always done in software (Software Only)
• Encrypt/Decrypt can be done in
hardware on:
Network Data
• ASA 5525-X, 5545-X, 5555-X
• Firepower 4100 series
• Firepower 9300 series
Enabling SSL Decrypt in Hardware
Not enabled by default
• If not in the FTD console on a FP4100/FP9300, connect to FTD:
Firepower-module1> connect ftd
• At the FTD CLI prompt:

> system support ssl-hw-offload enable
IMPORTANT!
If you enable SSL hardware acceleration, you cannot:
1. Decrypt passive or inline tap traffic.
2. Decrypt GRE or IP-in-IP tunnel traffic.
3. Decrypt traffic using SEED or Camellia ciphers.
4. Preserve Do Not Decrypt connections when the inspection engine restarts.
Continue? (y/n) [n]: y
Enabling or disabling SSL hardware acceleration reboots the system. Continue? (y/n) [n]: y
Setting Up an SSL Policy
Step #1 – Import Root or Certificates (If Doing Decryption)
Internal CA certs w/ private key that can be used to spoof

resign public certificates. Used for “Decrypt – Resign”.
CAs that are trusted. SSL policy can specify clients

can only connect to sites signed by these CAs
Certs that are trusted. SSL policy can specify
clients can only connect to sites with these certs
Internal certs w/ private key that can be used for decryption

without resigning. Used for “Decrypt – Known Key”.
Reference

Step #2 – Create the SSL Policy
Step #3 – Create the SSL Rule
For public servers (you don’t control)
For servers you control
Reference

Step #3 – Create the SSL Rule
Step #3 – Specify the Criteria
None of these require

decryption of traffic
Step #4 – Assign the SSL Policy to the Access Control Policy
This tab contains advanced settings

for the entire access control policy
Reference
Access Control Policy – Revisited

The glue that ties everything together
Access Control Policy
Prefilter SSL Identity

DNS Policy
Policy Policy Policy
Inspection Options
Access Control Criteria Action

Rule (to match) Intrusion Malware & File
Policy Policy
Reference
Access Control Policy Use Case #2 – Recap

Inspect Outbound HTTP/HTTPS Connections (IDS, Malware and SSL)
• CLINET requirements:
• Allow all outbound HTTP/HTTPS traffic, regardless of port
• Perform IDS inspection of the traffic (with all Chrome rules enabled)
• Block any malware
• Block any HTTPS connections that use a self-signed certificate
• Policies we just created:

1. Edge Intrusion Policy We now need to apply them
2. Edge Malware & File Policy
by creating a rule in the
3. Edge SSL Policy
Edge Access Control Policy
Note: We will do this with a single rule for time/demonstration purposes.

There are multiple ways the same result could be achieved depending on the overall policy required.
Reference
Access Control Policy Use Case #2 – Graphically

Edge Access Control Policy
Edge SSL
Policy
Inspection Options
Criteria Action
Access Control
Rule All HTTP Allow Edge Intrusion Edge Malware &
Traffic Policy File Policy
Reference

Reference
Access Control Policy Use Case #2 –
Applications
Reference
Access Control Policy Use Case #2 – Inspections

Intrusion policy we
created previously
Malware & file policy

we created previously
Reference
Access Control Policy Use Case #2 – Logging

Log Files automatically

enabled with File
policy present
Reference
Access Control Policy Use Case #2 – Rule Added

SSL Policy applies to the

entire access control
policy, not just one rule
Rule we just
created
Reference
Access Control Policy Use Case #2 – SSL Policy

This tab contains advanced settings

for the entire access control policy
Organizing Access
Control Rules
Policy Management – Categories
• All access control policies contain two categories - Mandatory and Default
• Customer categories can be created to further organize rules
• Note - After you create a category, you cannot move it. You can delete it, rename it,
and move rules into, out of, within, and around it
Present by default, can’t be deleted
User created categories
Policy Management – Inheritance
• Allows an access control policy to inherit Global Domain
the access control rules from another
policy. 2nd Level Domain
• Two types of sections in an policy: 3rd Level Domain

• Mandatory – Processed before any rules in a / Leaf Domain
child policy
• Default – Processed after all mandatory rules
and after any default rules from child policies
Example of what the Europe Data

Centre Policy will look like in the
Access Control Policy Editor
Policy Management – Multi-Domain Management
• Multitenancy for the Firepower management console
• Maximum of 50 domains and 3 level deep (2 children domains)
• Segments user access to devices, configurations and events
• Users can administer devices in that domain and below
• Devices are assigned to a domain
• Primarily for MSPs Global Domain
EMEA
Americas Domain
Domain
• Uses in the Enterprise:
• Force a policy to apply to all firewalls in a domain Edge DC
Domain Domain
• Limit user visibility to only select devices and events
• Delegate admin control while maintaining global visibility/control
Policy Management – Object Overrides
• Allows an object to be reused on multiple firewalls, but with different meanings
• Networks, Ports, VLAN Tags and URLs all support overrides
Example use cases:

• Selectively override an object
on the few devices that need a Default value, can
different value be left empty
• Create an empty object, so

Enable overrides
that an override is required for
every firewall
Overridden values
• Create a default value in the
global domain, but allow
subdomain administrators to
override the default value
FTD High Availability
Firepower Threat Defense High Availability
• Supported on all physical models and ESXi
• Stateful Active/Standby failover only
• All features are supported with failover
• Both NGFWs in pair must be identical in Primary Failover Backup

software, memory, interfaces and mode NGFW NGFW
(active) (standby)
• On FP9300, failover is only supported
State
• Across blades in different chassis

• In non-cluster mode
• Long distance LAN failover is supported if

latency is less than 250 ms
Firepower Threat Defense High Availability (Part 2)
• Two nodes connected by one or two
dedicated connections called “failover links”
• Failover and state
• Can use the same link for both
• Best practice is to use a dedicated link for each
if possible (cross-over or VLAN) Primary Failover Backup
NGFW NGFW
(active) State (standby)
• When first configured, Primary’s policies are
synchronized to Secondary
• Configuration/policy updates are sent to
current active node by FMC
• Active unit replicates policies to standby
How Failover Works
Failover link passes hellos between active
and standby units every 15 seconds
(tunable from 200msec - 15 seconds)
HELLO HELLO
Primary Failover Secondary

FTD FTD
How Failover Works
HELLO
Primary Failover Secondary

FTD HELLO
FTD
HELLO
After three missed hellos, local unit sends If no response…

hellos over all interfaces to check health of its
peer – whether a failover occurs depends on
the responses received
How Failover Works
Failover Secondary
FTD
State (active)
Local unit If no response…

becomes active
Reference
Stateful Failover Supported Features

• NAT translation table • URL With Notes:
• TCP connection states • Geolocation • Dynamic Routing Protocols
• UDP connection states • URL Filtering • AVC
• Snort connection states • TLS sessions not decrypted
• IPS Detection state
• Strict TCP enforcement • TLS URL • File malware blocking
• The ARP table • User Agent • File type detection
• The Layer 2 bridge table • ISE Session Directory • Identity/Captive Portal
• SIP signaling sessions • IP Reputation • Signature Lookup
• Snort Inspection • URL Reputation • File Storage
• Static Routes • DNS Sinkhole • File Pre-class (Local
• DHCP Server • Fragment settings Analysis)
• ARP Inspection • File Dynamic Analysis
• Archive File Support
See Chapter: Firepower Threat Defense High Availability for full details: • Custom Blacklisting
http://www.cisco.com/c/en/us/td/docs/security/firepower/601/configuration/guide/fpmc-config-
guide-v601/fpmc-config-guide-v601_chapter_01100110.html
Reference
Easier Way:
Stateful Failover Unsupported Features
• Every feature is supported, except:
• Sessions inside plaintext tunnels
• Inspection after decryption
• TLS Decryption State
• The HTTP connection table
• DHCP client
• DHCP server address leases
• Multicast routing
HA with Interface Redundancy
Before… After with redundant interfaces
Primary Failover Backup Primary Failover Backup

FTD FTD FTD FTD
(active) State (standby) (active) State (standby)
HA with Interface Redundancy
Before… After with redundant interfaces
Failures 11 - 7,
7 still
no FAILOVER
1
1 2 3
Any Causes
1 4
1
FAILOVER
Primary Failover Backup Primary Failover Backup

FTD FTD FTD FTD
(active) State (standby) (active) State (standby)
5
1
1 6 7
Port Channel feature makes this concept somewhat obsolete if switches support VSS/vPC
Reference
Deploying Active/Standby Failover

With both devices added to FMC, use “Add High Availability” dropdown
The policy that is

applied to this device
will become active
Reference
Deploying Active/Standby Failover

Whoops! Good to go!
• Fix the error and try again.
• In the example below,
policies had been changed,
but not yet deployed
Best practice - separate

interfaces/VLANs
Deploying Active/Standby Failover – Secondary IPs
Required to send hellos between data interfaces
Edit interfaces to
add standby IP
addresses for better
interface monitoring
Deploying Active/Standby Failover –
MAC Address
For stability, set virtual MAC address
Why? Traffic disruption due to MAC
address changes:
• If the secondary unit boots without
detecting the primary unit, the
secondary unit becomes the active
unit and uses its own MAC addresses.
When the primary unit becomes
available, the secondary (active) unit
changes the MAC addresses to those
of the primary.
Not required
functionally, but • If the primary unit is replaced with
best set for stability new hardware, the MAC addresses
from the new primary are used.
FTD Clustering
Overview
FTD Clustering Basics
• Designed to solve two critical issues with firewall HA:
• Aggregates firewall capacities for DC environments (bandwidth,
connections/sec, etc.)
• Provides dynamic N+1 stateful redundancy with zero packet loss
• Two types of clustering:

• Intra-chassis clustering – Supported (9300 only)
• Inter-chassis clustering – Supported (4100 or 9300)
FTD Clustering Types with FP9300
FTD Inter-Chassis Cluster
• Cluster of up to 6 modules (across 2 – 6 chassis)
• Off-chassis flow backup for complete redundancy
Switch 1 Switch 2
Nexus vPC
FP9300 Chassis 1 FP9300 Chassis 2
Supervisor Supervisor
FTD FTD FTD FTD
Cluster
FTD Cluster FTD
FTD Intra-Chassis Cluster

• Modules can be clustered within chassis
• Bootstrap configuration is applied by Supervisor
Inter-Chassis Clustering
• All NGFWs in cluster must be identical:
• 9300 – modules must be the same type
• 4100 – chassis must be the same model
• Only Spanned EtherChannel mode (L2) is

supported
• Equal-Cost Multi-Path (ECMP) mode (L3) is
not supported
• Requires at least FXOS 2.1.1 and FTD 6.2
Cluster Scalability – FTD 6.2.3 Example
54G 226G
30M 108M
Sessions Sessions
200K cps 2 6 600K cps
100% with no
Bandwidth 70% Avg.
Asymmetry*
Example 2 Firepower 9300s w/ 6 Total SM-44 Modules at 54 Gbps → 226 Gbps of throughput
Concurrent Sessions 60%

Example 2 Firepower 9300s w/ 6 Total SM-44 Modules at 30M → 108M concurrent sessions
New Connection Rate 50%

Example 2 Firepower 9300s w/ 6 Total SM-44 Modules at 300K → 900K connections/sec
Correct Use of EtherChannels When Clustering
with VPCs 1 2 3 4
CL MASTER CL SLAVE CL SLAVE CL SLAVE FTD x Node Cluster
 Data Plane of Cluster MUST use FTD Port-Channel 32

cLACP (Spanned Port-Channel)
VPC Identifier on N7K must be the
cLACP – Spanned Port Channel
same for channel consistency
N7K VPC 32
Cluster Data Plane
Cluster Control Plane VPC PEER LINK
 Control Plane [Cluster Control Link]
of Cluster MUST use standard LACP
(Local Port-Channel)
 Each VPC Identifier on Nexus 7K is N7K VPC 42
unique N7K VPC 40
N7K VPC 41
N7K VPC 43
 Port Channel Identifier on FTD LACP – Local Port Channels

defaults to 48
1 2 3 4 FTD Port-Channel 48
CL MASTER CL SLAVE CL SLAVE CL SLAVE FTD x Node Cluster
Reference
Clustering Roles
Flow Owner
• The unit that receives the connection, registers with Director
Flow Director
• Backup to the Owner and responds to lookup requests from the Forwarders.
• Maintains a copy of state for individual Owner’s flow
Forwarder
• Receives a connection but does not own it, queries Director for Owner
• Forwarders can derive Owner from SYN cookie if present (SYN-ACK) in asymmetric scenarios
or may query the Director via Multicast on CCL
Owner Forwarder Forwarder Director
Flow A
Flow B Forwarder Owner Director Forwarder

cLACP / PBR
Reference
Switch Requirements (Cisco and non-Cisco)

Requirements (must support): Recommendations (should support):
• 802.3ad compliant (LACP) • Uniform traffic distribution over the
EtherChannels individual links
• Under 45 second bundling time
• EtherChannel load-balancing algorithm
• On the cluster control link: that provides traffic symmetry
• Full unimpeded unicast and broadcast
connectivity at Layer 2 • Configurable hash using the 5-tuple,
• No limitations on IP addressing or the 4-tuple, or 2-tuple
packet format above Layer 2
• Must support an MTU above 1600
Note #1: Cisco does not support the resolution of bugs found in non-verified switches.
Note #2: Some switches, such as the Nexus series, do not support LACP rate fast when performing in-service
software upgrades (ISSUs). Cisco does not recommend using ISSUs with clustering.
FXOS Compatibility Guide: https://www.cisco.com/c/en/us/td/docs/security/firepower/fxos/compatibility/fxos-compatibility.html
Cisco Verified Switches for Clustering
Supported and Recommended: Supported but not recommended for spanned
EtherChannel mode:
• Nexus 7000 (M1, M2, F2 and F3)
• Cisco Nexus 7000 (F1)
• Cisco ASR 9000 with RSP 440
• Cisco Nexus 3000
• Cisco Nexus 9500, 9300, 6000, 5000
• Catalyst 4500-X
• Catalyst 6800 with Supervisor 2T
• Catalyst 3850
• Catalyst 6500 with Supervisor 2T, 32, 720,
and 720-10GE Reason – Asymmetric load-balancing can
cause performance degradation for data
• Catalyst 4500 with Supervisor 8-E throughput on the cluster
• Catalyst 3750-X
Note: Switches must run as a stack, vPC or VSS pair if cluster EtherChannel spans multiple switches
FXOS Compatibility Guide: https://www.cisco.com/c/en/us/td/docs/security/firepower/fxos/compatibility/fxos-compatibility.html
Cluster Connectivity Preferences
Firewall on a Stick Same Model Switches Different Model Switches
#1 #2 #3
Choice Choice Choice
• Single EtherChannel for • Two EtherChannels to • Two EtherChannels to

the inside and outside different switch pairs different switch pairs
• Same model switch • Different model switches
Using 2 Different Switches –
Switch Port Numbers Matter
Ascending
EtherChannel RBH values are sequentially Order
allocated in ascending order starting from the 1/1 1/2 1/3 1/4
lowest numeric line card and port ID.
0,4 1,5 2,6 3,7
For best cluster performance, keep traffic
symmetric and off the CCL:
• Use a symmetric hashing algorithm
• Use fixed RBH allocation for EtherChannels 0,4 1,5 2,6 3,7
e.g. “port-channel hash-distribution fixed”
on Nexus 7K and Catalyst 6500 1/7 2/1 5/7 6/1
• Links should be connected in matching Also
Ascending
ascending order on each switch
Configuring Load Balancing Using Port Channels in Nexus 7000 Series NX-OS Interfaces Configuration Guide:
https://www.cisco.com/c/en/us/td/docs/switches/datacenter/sw/nx-os/interfaces/configuration/guide/b-Cisco-Nexus-7000-Series-NX-
OS-Interfaces-Configuration-Guide-Book/configuring-port-channels.html
Reference
New TCP Connection (Symmetric Flow)

inside FTD Cluster outside
1. Attempt new
connection with 2. Become Owner, add
TCP SYN TCP SYN Cookie and
deliver to Server
Flow Owner
5. Update
3. Respond with
Director
TCP SYN ACK
through another unit
4. Deliver TCP SYN
ACK to Client
Client Server
Flow Director
Reference
New TCP Connection (Asymmetric Flow)

inside FTD Cluster outside
1. Attempt new
connection with 2. Become Owner, add
TCP SYN TCP SYN Cookie and
deliver to Server
Flow Owner
6. Update
4. Redirect to
Director
Owner based on
TCP SYN Cookie,
become Forwarder
5. Deliver TCP SYN
ACK to Client
Client Server
Flow Director
3. Respond with TCP SYN

ACK through another unit
Flow Forwarder
Reference
New UDP-Like Connection (Asymmetric Flow)

FTD Cluster
inside outside
Flow Owner
1. Attempt new UDP
or another pseudo- 4. Become Owner,
stateful connection deliver to Server
2. Query 3. Not 5. Update
Director found Director
9. Redirect to
Owner, become
10. Deliver 7. Query Forwarder
response to Client Director
Client Flow Director Server
8. Return
Owner
6. Respond through
Flow Forwarder another unit
Reference
Flow Owner Failure

FTD Cluster
inside outside
Flow Owner
3. Next packet
load-balanced to
6. Become Owner,
another member
deliver to Server
4. Query 5. Assign 7. Update
Director Owner Director
Client Server
Flow Director
1. Connection is established
through the cluster
Flow Owner
2. Owner fails
FTD Clustering
Configuration
Clustering Setup – Firepower Chassis Manager
• FP4100 and FP9300 platforms

only
• Used for:
• Managing the device hardware
• Configuring boot images
• Configuring physical (up/down)

and EtherChannel interfaces
• Cluster hardware setup
Steps Involved in Bringing up a FTD Cluster
Configure Add Create

Configure
Cluster Members Cluster
Interfaces
Members to FMC in FMC
Reference

Interface #1 – Management Interface for FTD
Type Mgmt - Used for

Centre connections and
other management
connections (e.g. SSH)
Reference

Interface #2 – Cluster Control Link
Type Cluster - Used

for the Cluster Control
Link and exchange
data between cluster
members
Reference

Interface #3 – Data Link
SVI VLAN200 172.16.25.253 SVI VLAN200 172.16.25.254
FHRP – 172.16.25.1 FHRP – 172.16.25.1
North Zone
VLAN 200
None
VPC
VLAN 200
Outside
VLAN 201
Inside
VPC BVI 172.16.25.86/24
Trunk Allowed 1,201 South Zone

VLAN 201
Server in
VLAN 201
Interfaces All Configured
Type Cluster - Used for the

Cluster Control Link and
exchange data between
cluster members
Type Mgmt - Used for
Center connections and other
management connections
Creating Cluster Member #1
Name of the
individual device,
not the cluster aka “Image Type” -
ASA or FTD
Images uploaded by the
user into the Firepower
Chassis Manager, make
sure they match across
cluster members
Be sure the data and cluster

interfaces are selected, interface for
management will not show up here
Port-channel48 is
automatically selected as the
cluster interface if configured
Chassis ID of the
unit in the cluster
(must be unique)
Key to authenticate
units joining the
Name of the cluster cluster, must be the
to join, must be the same on all devices
same on all devices
Dedicated out-of-band
management port
Key to authenticate
the management
connection from FMC
Admin password to
login to FTD locally
Needed for dc-fw.clinet.com
uploading files to
AMP, etc. Routed or
Transparent
FQDN of cluster, not

the cluster member
FTD management
IP, this must work
for communications
to the FMC
Reference

This is the cluster

configuration. Copy
this to the clipboard,
as it helps to avoid a
lot of retyping when
setting up other units
Name of the
individual device,
not the cluster
If this isn’t checked, you

will need to enter each
cluster detail manually
in the next step
Paste the config you

copied from the first
cluster member here
Must be different
than other units
Cluster Key – Enter

the same as before
Populated from the
pasted config
Key to authenticate
the management
connection from FMC
Admin password to
login to FTD
dc-fw.clinet.com
Populated from the

pasted config
Same across all units
in the cluster
Change to be
unique
Populated from the
pasted config
Wait for device to

show “in-cluster”
before adding to FMC
Clustering Setup – Firepower Management
Centre
Creating the Cluster
Each cluster member

must be individually
added to FMC before Display name of entire
you can create a cluster cluster within FMC
Cluster Successfully Added
Not a big deal,

clustering isn’t
technically live yet
Deploying FTD in
Transparent Mode
Reference
Review: Modes of Operation 192.168.1.1
• Routed Mode is the traditional mode of the firewall.

Two or more interfaces that separate L3 domains – VLAN192
Firewall is the Router and Gateway for local hosts

• Transparent Mode is where the firewall acts as a
bridge functioning at L2
VLAN1920
• Transparent mode firewall offers some unique benefits in
the DC 192.168.1.0/24
• Transparent deployment is tightly integrated with our
‘best practice’ data center designs IP:192.168.1.100
GW: 192.168.1.1
Why Deploy Transparent Mode?
• Very popular architecture in data center environments
• Existing Nexus/DC network fabric does not need to be modified to employ L2 Firewall!
• It is as simple as changing host(s) VLAN ID
• Firewall does not need to run routing protocols / become a segment gateway
• Firewalls are more suited to flow-based inspection (not packet forwarding like a
router)
• Routing protocols can establish adjacencies through the firewall
• Protocols such as HSRP, VRRP, GLBP can cross the firewall
• Multicast streams can traverse the firewall
• Non-IP traffic can be allowed (IPX, MPLS, BPDUs)
• Much faster deployment time for brown field (months vs. years)
Firewall – Transparent Mode
• Firewall functions like a bridge
• “Bump in the wire” at L2
• Only ARP packets pass without an
explicit ACL
• Full policy functionality is included –
NAT, AVC, NGIPS, AMP, etc.
• Same subnet exists on all interfaces
in the bridge-group
• Different VLANs on inside and
outside interfaces
Reference
Transparent Mode Configuration in the DC (2 interfaces)

Step 1 – Create Sub Interfaces (1 for each VLAN)
SVI VLAN200 172.16.25.253 SVI VLAN200 172.16.25.254
FHRP – 172.16.25.1 FHRP – 172.16.25.1
North Zone
VLAN 200
VPC
VLAN 200
Outside
VLAN 201
Inside
VPC BVI 172.16.25.86/24

VLAN 201
Server in
VLAN 201
Transparent Mode Configuration in the DC (2 interfaces)
Step 2 – Stitch everything together with a Bridge Group Interface
SVI VLAN200 172.16.25.253 SVI VLAN200 172.16.25.254
FHRP – 172.16.25.1 FHRP – 172.16.25.1
North Zone
VLAN 200
VPC
VLAN 200
Outside
Up to 250 bridge VLAN 201

Inside
groups and 64 VPC BVI 172.16.25.86/24
interfaces per
bridge group
VLAN 201
IP on the local subnet of

the servers, remember the Server in
correct subnet mask! VLAN 201
Set Cluster Control Link (CCL) MTU
Avoids fragmentation after encapsulation on CCL
Set MTU at 100

bytes above
highest data MTU
Reference
Now Cluster is Complete!
After deploying
changes, cluster
should turn green
Pro-Tip – Set Virtual MAC Addresses
For stability, set Active Mac address, especially if using non-interface NAT IPs
Why? Traffic disruption due to
MAC address changes:
• On boot, the MAC addresses of
the master unit are used across
/ the cluster. If the master unit
becomes unavailable, the MAC
addresses of the new master unit
Not required, but more are used across the cluster.
stable if set. For clustering,
only Active Mac Address
• Gratuitous ARP for interface IPs
needs to be set. partially mitigates this, but has no
effect on NAT IPs.
Reference
FTD L2 Mode: Local Packet

10.10.44.100
Destination 1
1
SVI VLAN200 172.16.25.253 SVI VLAN200 172.16.25.254

FHRP – 172.16.25.1 FHRP – 172.16.25.1
1 Session Request to server 172.16.25.200 from North Zone

2 4
source 10.10.44.100
2 4 VLAN 200
2 ARP request (or Lookup) for 172.16.25.200 on
VLAN 200– ARP Reply from FTD containing
local MAC (outside) on VLAN tag 200. ARP
request packet actually passes through FTD
and on return trip to the Nexus the FTD
updates its MAC table with the server MAC on
VLAN 201 (Inside). It forwards a reply to the VPC
Nexus with its server MAC and a VLAN 200 tag VLAN 200
(rewritten). This is how the Nexus knows to Outside
direct traffic thru the FTD to reach server.
3 FTD receives packet with Server destination

3
3 VLAN 201
Inside
172.16.25.200 and processes the access VPC BVI 172.16.25.86/24
control policy. If allowed, it forwards the
packet back to the Nexus with a VLAN tag of
201.
4 Since Nexus does not have an SVI for VLAN

201, it forwards packets across it local trunk
which allows VLAN 201 tag – southbound Trunk Allowed 1,201 South Zone
towards the 5K. Source MAC address is the VLAN 201
FTD
55
5 Request is delivered to Server 172.16.25.200 in Server in VLAN 201
VLAN 201 172.16.25.200
Reference
FTD L2 Mode: Remote Packet

10.10.44.100
Destination 5
SVI VLAN200 172.16.25.253 SVI VLAN200 172.16.25.254

FHRP – 172.16.25.1 FHRP – 172.16.25.1
1 Return path from server 172.16.25.200 in VLAN North Zone

201 to remote destination 10.10.44.100
4 2 VLAN 200
2 Packet received on Nexus from Server on

VLAN 201. MAC in table that processes these
packets is FTD inside interface (from
southbound example) Traffic is redirected to
FTD (inside) VLAN tag 201
VPC
3 FTD receives packet with destination VLAN 200
Outside
10.10.44.100 and processes the access control
policy. If FTD does not have MAC Address in
table, it sends an ICMP-Echo packet to
10.10.44.100 (sourced from its BVI IP Address) 3 VLAN 201
Inside
with TTL=1. FHRP on Nexus will respond with
Time Exceeded, MAC address = FHRP MAC VPC BVI 172.16.25.86/24
VLAN 200 (Outside) which will update FTD
MAC table with the MAC-IP Mapping of Nexus
on VLAN 200 (outside)
4 FTD forwards packet to Nexus SVI (FHRP)

address 172.16.25.1 on VLAN 200 for delivery Trunk Allowed 1,201 South Zone
to destination 10.10.44.100 VLAN 201
1
5 Nexus executes ARP request (if necessary) per
standard routing function. Request is Server in VLAN 201
forwarded towards destination 10.10.44.100 172.16.25.200
Alternative Designs
Interfaces Revisited: Optional Interface Modes
• By default, all interfaces are firewall interfaces (routed or transparent)
• Optionally, specific interfaces can be configured for use as IDS or IPS
• IDS Mode
• Inline Tap
• Passive
• ERSPAN
• IPS Mode
• Inline Pair
Optional FTD Interface Modes
A Routed or Transparent
F Interfaces
Passive Policy Tables
B G
Inline Pair 1
C H
Inline Set
Inline Pair 2
D I
Inline Tap
E J
Inline NGFW
Firewall without Routing or Bridging Interfaces
• Although not a “Firewall” interface,
L3/L4/L7 rules can be enforced when
using “IPS” interface types
• Useful when Routed or Transparent aren’t
possible/feasible
Inline Pair
• No subinterfaces required for trunks, use
“VLAN Tags” in ACP instead:
• Caveats:
• No NAT / No Routing
• No strict TCP state tracking
Configuration: https://www.cisco.com/c/en/us/support/docs/security/firepower-ngfw/200924-configuring-firepower-threat-defense-int.html
Out-of-Band IDS - Multichassis SPAN
When a single Firepower appliance is not enough
• Each device configured as a standalone
device
• Cluster not supported, as it requires all
firewall ports to be EtherChannels
FW: Passive
• On switch, SPAN destination configured as Interfaces
EtherChannel
• EtherChannel set to mode of “On”
SW: EtherChannel
• On firewall, each port configured as Passive without LACP
interface:
• EtherChannel load balancing distributes

traffic to different Firepower chassis
Inline IPS – Passthrough EtherChannel w/o HA
LACP EtherChannel through FTD
• Useful for scaling IPS without Clustering or VSS
or VPC
scaling IPS with total fault isolation
SW Only: Port Channel 1
• LACP EtherChannel formed between Not HA or
switches on either side of FTD Clustered
• FTD has no knowledge of EtherChannel
• Interfaces configured as Inline Pair on FW
• Each FTD appliance configured as
standalone device in FMC
SW Only: Port Channel 1
• Failover of FTD handled by LACP on SW
VSS
• EtherChannel MUST deliver symmetric or VPC
traffic for effective security
Inline IPS – Passthrough EtherChannel w/ HA
LACP EtherChannel through FTD w/o Symmetric Traffic
• Useful for IPS HA without Clustering VSS
or VPC
X X
• Same interface configuration as SW Only: Port Channel 1
Passthrough EtherChannel w/o HA Disabled
by LACP
• Traffic is automatically symmetric through
FTD, since only 1 unit is ever active
HA Pair
• Inline pair interfaces on Standby HA unit
Active Standby
are forced down when not active
• On failure of Active unit, LACP on SW: Disabled
SW Only: Port Channel 1 by LACP
X X VSS
or VPC
Inline IPS – Passthrough EtherChannel w/ HA
LACP EtherChannel through FTD w/o Symmetric Traffic
• Useful for IPS HA without Clustering VSS
or VPC
X X
• Same interface configuration as SW Only: Port Channel 1
Passthrough EtherChannel w/o HA Disabled
by LACP
• Traffic is automatically symmetric through
FTD, since only 1 unit is ever active
HA Pair
• Inline pair interfaces on Standby HA unit
Standby Active
are forced down when not active
• On failure of Active unit, LACP on SW: Disabled
SW Only: Port Channel 1 by LACP
• Detects links on old Active unit are down and
removes those ports from use in EtherChannel X X VSS
or VPC
• Detects links to new Active unit are now up and
starts sending traffic across those links
Inline IPS – EtherChannel Termination w/ Cluster
LACP EtherChannel to FTD
• Preferred method of scaling IPS w/ FTD VSS
or VPC
• Unlike previous designs, LACP
EtherChannel terminates on FTD SW+FW: Port Channel 1
• Traffic is automatically symmetric through FTD,
since Cluster handles any asymmetry
• Physical ports for both PC1and PC2 Cluster

configured in FXOS FCM
• PC1 and PC2 configured as Inline Pair SW+FW: Port Channel 2
within FMC
VSS
or VPC
FTD Flow Bypass
FTD Flow Offload
• Trusted flow processing with limited security visibility
• Maximize single-flow throughput and packet rate, minimize latency
• High performance compute, frequency trading, demanding data center applications
• Static hardware-based offload in Smart NIC for FTD
• Automatically enabled when rule in Prefilter Policy uses the Fastpath action
• 20+ Gbps per single flow (TCP/UDP) and 2.9us of 64-byte UDP latency
• Unicast IPv4 TCP/UDP/GRE and VLAN encapsulation only, no CMD/SGT
• FXOS 2.2(1) supports 4 million unidirectional or 2 million bidirectional flows
per security module
Reference
FTD Flow Offload Operation

Full Inspection Extended Offload Path (Future)
• Dynamically program Offload engine after flow establishment • Dedicated x86 cores for advanced processing
• Ability to switch between Offload and full inspection on the fly • Packet capture and extended statistics
Firepower 4100 or 9300

x86 CPU Complex
Full FTD Engine Lightweight Data Path
New and fully Offload Flow Advanced

inspected flows instructions updates Processing
Incoming Established
Flow Classifier Rewrite Engine
traffic trusted flows
Smart NIC
Flow Offload
• Limited state tracking, NAT/PAT, TCP Sequence Randomization
• 20+ Gbps per single TCP/UDP flow, 2.5us UDP latency, 4M unidirectional/2M bidirectional (6.2.2)
Reference
FTD Virtual Firewall

Deployment
Reference
Cisco Virtual FTD and FMC
VMware KVM
OVF for vSphere and ESXi Cisco FTDv qcow2 image
VMware ESXi 5.x, 6.x
Public Cloud
KVM 1.0 Virtio driver
E1000, VMXNET3
Amazon Web Services
AMI in the marketplace
Microsoft Azure
Same Feature Set As Physical Appliances
Reference
Cisco FTDv for VMware

• ESXi version 5.1 and 5.5 (FTD 6.0) and ESXi version 6.0 (FTD 6.1)
• Interfaces
• Default of 4 E1000 interfaces (1 management, 3 data)
• Minimum of 4 interfaces required – even if your use case requires less
• Maximum of 10 interfaces (1 management, 9 data)
• VMXNET3 interfaces for 10G also supported
• 4 GB default / 8 GB max (allocate more, based upon features – e.g. AMP)

• 4 vCPU default / 8 vCPU max (allocate more for better performance)
• 40GB hard disk is allocated and cannot be changed
• No web interface. You must initially configure via console CLI and manage from
Firepower Management Centre.
Reference
Virtual FTD Installation steps (vSphere)
Deploy OVF Template
Enter the details asked

for by the Setup Wizard
Add FTD to Firepower

Management Centre
Reference
Cisco FTDv for VMware

High Availability
FTDv FTDv
VM (Active) FTDv FTDv (Standby)
VM VM VM VM
VM Port-Group Failover VM VM
Port-Group A
VM VM VM VM
Port-Group B
Distributed Virtual Switch
ESXi-1 ESXi-2
• Supports Active/Standby HA for Stateful Failover. No caveats.

• A dedicated segment and failover interface is recommended. The loss of the failover
link and keep-alive messages may introduce loops (both units become Active)
• No Live Migration and other VMware High Availability tools are supported
Reference
FTDv Deployment Scenario – Passive

• Monitoring traffic between ESXi Host
Server A and Server B Management
• Dedicated FTDv per ESXi host Sensing

FTDv
• Promiscuous mode enabled in vSwitch2
ESXi for FTDv Sensing port Virtual

Server A
group Virtual
Server B
vSwitch3 | P Port Group
NIC2 NIC3
Reference
FTDv Deployment Scenario – Routed

• L3 NGFW gateway for servers ESXi Host
• Configure 2 vSwitches: Management
• One with external interface Outside Inside

FTDv
(Outside)
vSwitch2
• One with without (Inside) Virtual
Server A
• Servers connect to Inside Virtual

vSwitch Server B
• Port groups used for the vSwitch4 vSwitch3 | P Port Group
Outside interface must have NIC2 NIC4

Protected vSwitch
only 1 active uplink

Reference
FTDv Deployment Scenario – Transparent

• NGFW segmentation between hosts ESXi Host
• Bridge up to 4 segments per BVI Management
• Configure 2 vSwitches: Outside Inside

FTDv
• One with external interface (Outside) vSwitch2
• One with without (Inside) Virtual
Server A
• Servers connect to Inside vSwitch Virtual

Server B
• Promiscuous mode enabled in ESXi for
FTDv Inside port group vSwitch4 vSwitch3 | P Port Group
Protected vSwitch
• Use port channels to avoid loops – NIC2 NIC4
disable any NIC teaming
A Familiar Platform With Advanced Functionality
Output of show running-config on FTD
Security Beta Programs
Beta Software Product Access to Test Hardware Bugs Fixed for Influence
Access Training Dev Teams and Licenses Release Product Roadmap
ASA | NGFW | NGIPS | Firepower Platforms | AMP | CTA | ESA | WSA | ISE | Umbrella
Enroll Today! “I've been involved in many beta programs …

http://cs.co/security-beta-nomination I must say that this one has been the best
organized. This beta has taken a very active, hands-
on approach.” - Liberal Arts College Customer
ask-sbg-beta@cisco.com
Continuing the Discussion
•1 hour for questions after the session

• Meet the Engineer
• Email: schimes@cisco.com
Complete your online session evaluation
Give us your feedback to be entered

into a Daily Survey Drawing.
BRKSEC-2020
Complete your session surveys through was
the Cisco Live mobile app or on awesome!
www.CiscoLive.com/us.
Don’t forget: Cisco Live sessions will be available for viewing
on demand after the event at www.CiscoLive.com/Online.
Continue
your Demos in
the Cisco
Walk-in
self-paced
Meet the
engineer
Related
sessions
education campus labs 1:1
meetings
Thank you
#CLUS
Q&A
#CLUS

Brksec 2020

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Brksec 2020

Uploaded by

Copyright:

Available Formats

#CLUS

• Deploy L2 Firewalls in the DC

Webex Teams will be moderated cs.co/ciscolivebot#BRKSEC-2020

13:00 10:30 08:30 08:00

After the Session

They are included for additional detail

Cisco Firepower NGFW

Firepower Threat Defense (FTD) Software

Firepower (L7) Firepower Threat Defense

• Application inspection Migration

Cisco Firepower NGFW Product Family

(SM-24, SM-36, SM-

Single hop upgrade

Firepower Firepower FTD 6.1

Single Hop Single Hop

Firepower FTD 6.2.3

FMC Installation Guide: http://www.cisco.com/c/en/us/td/docs/security/firepower/hw/firepower_management_center/management_center/installation.html

Firepower 4100 / Firepower 9300 (2 Management)

Outside FTD Management

Hardening/Extended QA Single Hop Upgrades TLS Hardware Acceleration

Latest Compatible FXOS Version (now 2.3.1.75)

Enable to add column to

Layer-2 Switch FTD Inside

• Connect to the Firepower Threat Defense Application

• Prompts to configure admin password, management (IPv4 and/or IPv6),

FTD Initial Setup – FTD Console

• Connection to FMC must be preconfigured on FTD, single line command.

FTD Initial Setup – Adding a Device to FMC

Select based upon Previously configured

• Routed Mode is the traditional mode of the firewall. Two or more

• Integrated Routing and Bridging (IRB) allows a firewall to both

• All platforms • 5506 – 5555 only • All platforms

Basic Interface Configuration

Basic Interface Configuration

Deploying the Redundant Outside Interfaces

Deploying the Redundant DMZ Interfaces

GigabitEthernet1/4 G1/3 VLAN

No IP either Edge Aggregation

Deploying the Redundant DMZ Interfaces

Repeat 1x for VLAN 151

Deploying the Redundant DMZ Interfaces

What is a vPC EtherChannel?

• All links are active – no STP blocked ports

• A vPC Peer Link is used on Nexus devices to instantiate 10G

• Peer Link synchronizes state between vPC peers

• vPC White paper:

• Supported in all modes (transparent and routed)

Deploying the Inside Interfaces with EtherChannel

Deploying the Inside Interfaces with EtherChannel

Same security zone can

Deploying the Inside Interfaces with EtherChannel

Deploying the Inside Interfaces with EtherChannel

FTD Packet Processing Flow

• FTD is optimized as a flow-based inspection device

• BGP RIB is replicated in failover along with other protocols

Non Stop Forwarding (NSF)

FTD Routing – Static Use Case

FTD Routing – Dynamic Use Case

FTD Routing – Dynamic Use Case

Next slide is from

FTD Routing – Dynamic Use Case

FTD Packet Processing Flow

• Manual NAT – Source (and possibly destination) is used as a match criteria