Brksec 2020

BRKSEC-2020
Firepower NGFW in the

DC and Enterprise
Deployment Tips and New Features
Steven Chimes, Consulting Systems Engineer

Your Speaker
• Security Consulting Systems Engineer focused on
large global pharmaceuticals and finance
• 14 years in industry including academia,
manufacturing and now Cisco
• Goalkeeper, half-marathoner, volunteer ski patroller
and freshly minted husband
BRKSEC-2020 © 2019 Cisco and/or its affiliates. All rights reserved. Cisco Public 3
Agenda
• Deploy L3 Firewalls at the Edge
• Interfaces, Routing & NAT
• NGFW Policy Tips/SSL Decrypt
• High Availability
• Deploy L2 Firewalls in the DC
• Clustering Overview
• Deploy Multi-Instance
• Overview
• Configuration Walkthrough
• Alternative Designs
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 Mobile 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
cs.co/ciscolivebot#BRKSEC-2020
Or email me: schimes@cisco.com
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.
• Company requirements and configuration examples are based upon real-
life customer conversations and deployments.
There are ~100 slides we will not cover 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
Center (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 Center & Service Provider
FTD Initial Setup
New in 6.2.3! Reference
Single hop upgrade

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

1. Management
2. Management 3.
Center 6.1 Center 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
Center 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
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.
Center (FMC)
Layer-2 Switch FTD Inside

Outside
FTD Management
Chassis Management
(FP4100/FP9300)
Generally Suggested Version: FTD 6.2.3.X
FTD 6.2.3 (now 6.2.3.7, 1 release back from the latest patch) – “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.110)

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 Center 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
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
• EtherChannel uses LACP (Link Aggregation Control

src-dst-IP (hash)
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 w/ 6.2.3
or • FP4100/9300 support Etherchannel “On” mode w/ 6.3
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)
RIP?
Static or IGP
G1/2
• OSPFv2 & OSPFv3 (IPv6)
• RIP v1/v2
Seriously?
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
Reference
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
6.2.3
Logging Design for Large Deployments Example
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):
• TLS Proxy Session Setup Application Data
Encrypt/Decrypt Encrypt/Decrypt
• Session Setup Encrypt/Decrypt
(Asymmetric Key) (Symmetric Key)
• Application Data Encrypt/Decrypt
• TLS Proxy is always done in software TLS Proxy
(Software Only)
• Encrypt/Decrypt can be done in
hardware on:
• ASA 5525-X, 5545-X, 5555-X (6.2.3+) Network Data
• Firepower 4100/9300 series (6.2.3+)
• Firepower 2100 series (6.3+)
Enabling SSL Decrypt in Hardware
Enabled by default in 6.3+. Enabled via CLI in 6.2.3.
• 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
Reference
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
Reference

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

Step #3 – Create the SSL Rule
Reference

Step #3 – Specify the Criteria
None of these require

decryption of traffic
Reference

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
NTP Config #1 - FXOS
A leading cause of “no events are showing up in my FMC”…
FXOS does not sync time

from FMC. Use the same
NTP servers as FMC
Ensure the Server Status is

Synchronized
NTP Config #2 – FMC for Non-FXOS Devices
For FTD, defined in a Threat Defense policy

For legacy Firepower, defined in a Firepower policy
Ensure all the necessary/new

devices are added
Using “Via NTP from the

Management Center” is the default
and general best practice for non-
FXOS devices (e.g. FP2100)
NTP Config #3 – FMC Itself
Use the same NTP servers as

used for the FXOS devices
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

Center 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
Global Domain
• Primarily for MSPs
EMEA
Americas Domain
Domain
• Uses in the Enterprise:
Edge DC
• Force a policy to apply to all firewalls in a domain 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
Not required addresses to those of the primary.
functionally, but
best set for stability • If the primary unit is replaced with
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
• Not yet supported with Multi-Instance
For practical purposes, use
FXOS 2.3.x and FTD 6.2.3.x
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
• On the cluster control link:
algorithm that provides traffic
• Full unimpeded unicast and broadcast symmetry
connectivity at Layer 2
• No limitations on IP addressing or the • Configurable hash using the 5-tuple,
packet format above Layer 2 4-tuple, or 2-tuple
• 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
FMC Clustering Improvements with FTD 6.3
Discovery of cluster nodes is now automatic in FMC
FTD 6.2.3 - 6 Node Cluster Setup FTD 6.3 - 6 Node Cluster Setup
Add Device #1 Add Device #5 Add Device #1

in FMC in FMC in FMC
Add Device #2 Add Device #6 Devices #2 - #6 Automatically

in FMC in FMC Added to Cluster in FMC
Add Device #3 Add Devices to

Done!
in FMC Cluster in FMC
Add Device #4 Automatic discovery of nodes applies

Done
in FMC to both initial setup and additions
Set Cluster Control Link (CCL) MTU
Avoids fragmentation after encapsulation on CCL
Set MTU at 100

bytes above
highest data MTU
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,
• Gratuitous ARP for interface IPs
only Active Mac Address
needs to be set. partially mitigates this, but has no
effect on NAT IPs.
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
Reference
FTD Clustering
Configuration
Reference
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
Reference
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

Center 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
Reference

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
Reference

Creating Cluster Member #1
Name of the
individual device,
not the cluster a.k.a. “Image Type”
- ASA or FTD
Images uploaded by the
user into the Firepower
Chassis Manager, make
sure they match across
cluster members
Reference

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
Reference

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
Reference

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
Reference

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

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
Reference

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
Reference

Paste the config you

copied from the first
cluster member here
Reference

Must be different
than other units
Cluster Key – Enter

the same as before
Populated from the
pasted config
Reference

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
Reference

Change to be
unique
Populated from the
pasted config
Reference

Wait for device to

show in-cluster before
adding to FMC
Reference
Clustering Setup – Firepower Management Center

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
Reference
Cluster Successfully Added
Not a big deal,

clustering isn’t
technically live yet
Reference
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 IP:192.168.1.100

our ‘best practice’ data center designs GW: 192.168.1.1
Reference
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 security 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)
Reference
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
Reference
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
Reference
Now Cluster is Complete!
After deploying
changes, cluster
should turn green
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

source 10.10.44.100
22 44 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
FTD Multi-Instance
Overview
BRKSEC-2020
FTD Multi-Instance Intro
• Next generation replacement for ASA Multiple Context Mode
• Create multiple logical devices on a single module or appliance
• Instances are truly virtual (unlike ASA contexts), leveraging Docker containers
• Dedicated resources allows for traffic processing and management isolation
• Each container instance runs its own FTD software version
• Physical, logical and VLAN separation provided by chassis supervisor
Internet Firewall DMZ Firewall DC Firewall

FTD 6.3 FTD 6.3.0.1 FTD 6.3.0.2
6 CPU 6 CPU 10 CPU
Firepower 4100 or Firepower 9300
FTD Multi-Instance Key Details
• Requires FTD 6.3+
• Supported on Firepower 4100 and 9300 hardware only
• Supports inter-chassis HA for high availability only
• Maximum of 42 instances per chassis
• Not yet supported, but planned:

• Clustering
• Flow Offload
• Hardware crypto
• Overlapping IP addresses across instances managed by a single FMC
Instance Counts by Platform
Maximum CPU Cores Maximum FTD Instances
Firepower Platform
Per Instance Per Chassis
4110 22 3
4120 46 3
4140 70 7
4150 86 7
9300 w/ 1 x SM-24 46 7
9300 w/ 1 x SM-36 70 11
9300 w/ 1 x SM-44 86 14
9300 w/ 3 x SM-24 46 21
9300 w/ 3 x SM-36 70 33
9300 w/ 3 x SM-44 86 42
Network Interfaces
• Supervisor assigns physical, EtherChannel, and VLAN subinterfaces
• FXOS supports up to 500 total VLAN subinterfaces
• FTD can create VLAN subinterfaces on physical/Etherchannel interfaces
• Each instance can have a combination of different interface types
Data (Dedicated) Data-Sharing (Shared) Mgmt/Firepower-Eventing

FTD Instance A FTD Instance B FTD Instance A FTD Instance B FTD Instance A FTD Instance B
Supported Firewall Modes: Supported Firewall Modes: Supported Firewall Modes:

Routed, Transparent Routed Routed
Supported Usage: Supported Interface Usage: Supported Interface Usage:
Routed, Transparent, Inline, Passive, HA Routed (no BVI members), HA Management, Eventing
Network Interface Scalability
If you only read one section of FXOS docs, read the interface section:
https://www.cisco.com/c/en/us/td/docs/security/firepower/fxos/fxos241/cli-guide/b_CLI_ConfigGuide_FXOS_241/interface_management.html
• Ingress VLAN Group Entry Count defines maximum VLAN ID count

• Up to 500 VLAN subinterfaces or total entries across the chassis
• Re-using same VLAN ID consumes 2 entries
• Switch Forwarding Path Entry Count limits shared interfaces

• Up to 1021 TCAM entries for ingress/egress path programming across the chassis
• Each dedicated data interface consumes 3 - 4 entries, depending on usage
• Entries for shared data interfaces grow exponentially with instance count
Interface Scalability Best Practices
In order of preference:
• Use non-shared interfaces or subinterfaces
• Share subinterfaces under a single physical parent
• e.g. Share Po4.100, Po4.200, Po4.300 instead of Po1, Po2 and Po3
• Share subinterfaces instead of parent interfaces

• e.g. Po1.100, Po2.200, Po3.300 instead of Po1, Po2 and Po3
• Share physical ports or port-channels
• Maximum of 10 shared interfaces per instance

• Maximum of 14 instances per shared interface
Interface Combinations That Work
Documented in FXOS docs under “Shared Interface Usage Examples”
Alternatives to
Multi-Instance
Use Cases for Multi-Tenancy
Routing Table Resource

Separation Sharing
Independent and/or Oversubscription of

overlapping IP spaces firewall resources
Traffic Processing Policy Management Management

Isolation Simplification Separation
Compliance separation Smaller policy views that Independent

and tenant resource are managed by a single management of firewall
overflow protection administrator partitions
Multi-Tenancy Use Case Mapping to FTD
Policy Simplification Routing Independent Traffic Processing
Resource Sharing
Only Separation Only Management Isolation
Less Than
No 42 Tenants?
Yes
FMC Zones,
Future FTD Multi-
SG Tags, FTDv
Release Instance Mode
Categories
Zones and Categories for Policy Management
Migrate ASA contexts to FTD, without FTD Multi-Instance
Multi-Context Mode ASA
Po5.301 Inside Context A Outside Po5.302
Po5.303 Inside Context B Outside Po5.304
Po5.305 Inside Context C Outside Po5.306
Po5.307 Inside Context D Outside Po5.308
Define the context

interfaces as zone objects
Define the context

Group the rules that
were in an ASA
context in a category
Define the context

Group the rules that
were in an ASA
context in a category
Use the previously defined zones

as a source/destination in each rule
Multi-Instance
Configuration
Walkthrough
Demo Scenario Logical Design
Edge DMZ Firewall
Outside DMZ
Internet Firewall DMZ Firewall
Inside
DC Firewall DC Servers
Edge DMZ Firewall
(Physical – L3)
Outside DMZ
Internet Firewall DMZ Firewall

(Instance – L3) (Instance – L3)
Inside
(Instance – L2)
Edge DMZ Firewall
(Physical – L3)
Outside DMZ
Po3 Po4
Internet Firewall Inside DMZ Firewall

(Instance – L3) Po5.100 (Instance – L3)
Inside
Po5.301,Po5.302
(Instance – L2) Po5.303,Po5.304
Demo Scenario Multi-Instance Design
Po5.301 Po5.301
Po5.302 Po5.302
Po5.303 Po5.303
Po3 Po5.100 Po4 Po5.304 Po3 Po5.100 Po4 Po5.304
Internet Firewall DMZ Firewall DC Firewall Internet Firewall DMZ Firewall DC Firewall
FPR4K08-1-A FPR4K08-2-A FPR4K08-3-A FPR4K09-1-B FPR4K09-2-B FPR4K09-3-B
(Primary) (Primary) (Primary) (Secondary) (Secondary) (Secondary)
FPR4K08 FPR4K09
HA Link 1: Eth1/8.1001
Steps Involved in Bringing up a Multi-Instance
Reinitialize Create Add

Upgrade FXOS Module in Instances in Instances to
FXOS FXOS FMC
Multi-Instance Setup – FXOS Upgrade
Upload and upgrade FXOS to 2.4.1+
The file is big (~1 GB) with no

status bar. If you can, upload
from a local machine.
FXOS file on local machine
previously downloaded
from Cisco website
Pressing Close and staying
on the page does not stop
the upload. It will continue in
the background.
If you uploaded via the CLI, use

Refresh to repoll for images
Message will always appear when

upload is complete, even if you
pressed Close on the upload dialog
Upgrade/downgrade FXOS button
Verify image integrity button
After pressing Yes the upgrade process takes a while

(~15 min). Be patient and leave this page open.
Upload and upgrade FXOS to 2.4.1+ - If you are impatient
Expected version if you

refresh the page before
the upgrade restart occurs
Upload and upgrade FXOS to 2.4.1+ - If you are impatient
Expected message if you

refresh the page before
the upgrade is complete
Upgrade is complete
when you are prompted to
log in again.
Multi-Instance Setup – Module Reinitialization
Required to support Container instances
Reinitialization required after FXOS

upgrade to support Multi-Instance.
Module is Multi-Instance ready when

Upgrade typically takes ~5 minutes
you Service State returns to Online
Multi-Instance Setup – Configuring Interfaces
Adding Data-Sharing Interface for FPR4K08-1-A and FPR4K08-2-B
Data interfaces can be

used by a single instance
Data-Sharing interfaces
can be shared across
interfaces. Physical
interfaces, port-channels New in 6.3 is the option to
and subinterfaces can all add subinterfaces
be set to Data-Sharing
Adding Data-Sharing Interface for FPR4K08-1-A and FPR4K08-2-B
Physical interface for the

subinterface
Subinterface ID used by
FXOS and FMC
External VLAN. Does not

need to match
Subinterface ID.
Completed Interface Configuration
Dedicated port-channel to
be used on FPR4K08-1-A
Dedicated port-channel to
Shared subinterface to be
used on FPR4K08-1-A and
FPR4K08-2-A
Dedicated subinterfaces to
Semi-shared interface for

management of all instances
Dedicated subinterfaces for

HA link for each instance
Reference
MAC Address Restrictions

• Virtual MAC addresses are auto-generated for all instance interfaces
• All container instance interfaces use A2XX.XXYY.YYYY format
• XX.XXXX is a default prefix derived from a chassis MAC or user-defined
• YY.YYYY is a counter that increments for every interface
• Manual MAC address configuration within FTD is still available
• Must be unique across all instances on a shared interface
• Must be unique for all chassis manager defined subinterfaces under a physical
interface or port-channel interface
• e.g. Po5.100, Po5.301, Po.302, etc. must all have unique mac addresses
• e.g. Po4 and Po5.100 could have overlapping mac addresses
• Supervisor faults are raised for all MAC address conflicts
Multi-Instance Setup – First Instance Creation
Device name used locally

within FXOS. Does not have
to match FMC.
Native for standalone
Containers for Multi-Instance
FPR4K08-1-A
Interfaces assigned to instance

Dark grey text indicates the
by clicking
interface is assigned
These are the untagged (no

VLAN tag) interfaces. Light
grey indicates the interface is
not assigned to the instance.
FPR4K08-1-A
Controls the number of CPUs

assigned to the instance.
Default-Small is 6 CPUs.
Semi-shared management
interface. If empty, check that
interfaces of type Management
are defined under Interfaces.
Unique management IP for the

instance. Must be reachable
from the FMC.
FPR4K08-1-A
Registration key used only
once when pairing with FMC.
Doesn’t need to be complex.
Admin password for FTD, not
the password for FMC
Controls whether entering
expert mode (Linux shell) is
allowed via SSH.
Transparent or Routed
Alphanumeric string to assist
setup w/ NAT. Must be unique
across all devices in FMC.
If a dedicated event interface is

desired
FPR4K08-1-A
If the Status is install-failed, the

module was not reinitialized. Fix
is to reinitialize the module.
Assuming everything is okay,

Status should move to installing
within ~1 min
Reference
Multi-Instance Setup – Second Instance Creation

FPR4K08-2-A
Reference

FPR4K08-2-A
Reference

FPR4K08-2-A
Reference

FPR4K08-2-A
Reference
Multi-Instance Setup – Third Instance Creation

FPR4K08-3-A
Reference

FPR4K08-3-A
Reference

FPR4K08-3-A
Reference

FPR4K08-3-A
Multi-Instance Setup – Modify Resource Profile
FPR4K08-3-A
In some cases, the Default-Small

profile may not consume all the cores
Additional instances configured.

Steps in the hidden slides. Setup still running
FPR4K08-3-A
Default profile
of 6 CPUs
New profile to unused

CPU capacity
Multiples of 2,
excluding 8.
(e.g. 6, 10, 12, 14, 16)
FPR4K08-3-A
If previously created,
the profile could have
been selected during
setup. It can be
changed after setup.
FPR4K08-3-A
With HA and increasing

resources, stateful
failover is supported.
With HA and
decreasing resource,
stateful failover is not
guaranteed.
Multi-Instance Setup – Completed FXOS Setup
100% of CPU resources

now consumed
New Resource Profile

Restart complete
assigned
Complete the same steps for FPR4K09, using different names/IPs
Reference
Management and Licensing

• Each instance is managed as a separate firewall in FMC
• Each instance has its own management IP address
• Each instance must be added to FMC separately
• Separate software upgrades, restarts and policies
• Name for the Instance is not pulled from FXOS, is defined in FMC
• Name for the Chassis is pulled from FXOS, is defined in FXOS
Multi-Instance Setup – FMC Setup
Adding devices
Adding an Instance to
FMC is no different than
adding a physical firewall
Multi-Instance Setup – FMC Setup
Adding devices
Separate versions, upgrades,

policies per instance
Each Instance must be Chassis name defined in

added individually. Device FXOS
name defined in FMC. BRKSEC-2020 © 2019 Cisco and/or its affiliates. All rights reserved. Cisco Public 222
Reference
Licensing with Multi-Instance

• No additional feature license required to enable multi-instance
• When instances are managed by a single FMC:
• Additional subscription licenses (Threat, URL) are NOT required
• Instances on a security module share a single license.
• 42 instances on FP9300 w/ 3 x SM-44 modules  3 licenses
• When instances are managed by separate FMCs:

• Additional subscription licenses (Threat, URL, XXX) CAN be required per FMC
• 42 instance on FP9300 w/ 3 x SM-44 modules by 2 FMCs  3 - 6 licenses
• 42 instance on FP9300 w/ 3 x SM-44 modules by 42 FMCs  42 licenses
• Consider multi-domain management on a single FMC instead
Multi-Instance Licensing
No new feature license for

Multi-Instance features
URL Filtering license #1
URL Filtering license #2
Instances on the same

module share a feature
license when managed by
the same FMC.
6 instances on 2 modules
requires only 2 licenses
Multi-Instance High Availability
• Container instances only support inter-chassis HA
• Configured exactly as you would physical appliances
• Multiple instances can share one HA Link, using one VLAN per instance
• An HA pair allows differently sized instances for seamless resizing
• Stateful HA is supported but not guaranteed when downsizing
Internet Firewall DMZ Firewall DC Firewall Internet Firewall DMZ Firewall DC Firewall
(Primary) (Primary) (Primary) (Secondary) (Secondary) (Secondary)
FPR4K08 FPR4K09
Managed Just Like A Physical Firewall
HA, Policies, Eventing, etc.
Subinterfaces are
managed within FXOS
Everything else, except for

subinterfaces, is managed
just like a physical firewall
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 VSS
or VPC
or 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
• Failover of FTD handled by LACP on SW SW Only: Port Channel 1
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
• Inline pair interfaces on Standby HA unit HA Pair

are forced down when not active Active Standby
• 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
since only 1 unit is ever active
• Inline pair interfaces on Standby HA unit HA Pair

are forced down when not active Standby Active
• On failure of Active unit, LACP on SW: Disabled

• Detects links on old Active unit are down and SW Only: Port Channel 1 by LACP
removes those ports from use in EtherChannel X X VSS
• Detects links to new Active unit are now up or VPC
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
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
Reference
FTD Flow Bypass

Reference
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 Center.
Reference
Virtual FTD Installation steps (vSphere)
Deploy OVF Template
Enter the details asked

for by the Setup Wizard
Add FTD to Firepower

Management Center
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 Server ESXi Host
A and Server B Management
• Dedicated FTDv per ESXi host

Sensing
FTDv
• Promiscuous mode enabled in
ESXi for FTDv Sensing port group
vSwitch2
Virtual
Server A
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

(Outside) FTDv
• One with without (Inside) vSwitch2
Virtual
Server A
• Servers connect to Inside
vSwitch Virtual
Server B
• Port groups used for the Outside

interface must have only 1 active vSwitch4 vSwitch3 | P Port Group
uplink NIC2 NIC4

Protected vSwitch
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
Reference
A Familiar Platform With Advanced Functionality

Output of show running-config on FTD
Complete your online
session survey
• Please complete your Online Session
Survey after each session BRKSEC-2020
• Complete 4 Session Surveys & the Overall was
Conference Survey (available from awesome!
Thursday) to receive your Cisco Live T-
shirt
• All surveys can be completed via the Cisco
Events Mobile App or the Communication
Stations
Don’t forget: Cisco Live sessions will be available for viewing

on demand after the event at ciscolive.cisco.com
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 Mobile 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
cs.co/ciscolivebot#BRKSEC-2020
Or email me: schimes@cisco.com
Reference
Continue Your Education
Demos in Meet the Related

Walk-in
the Cisco engineer sessions
self-paced
Showcase labs 1:1
meetings
Thank you
Q&A

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

BRKSEC-2020

Firepower NGFW in the

Steven Chimes, Consulting Systems Engineer

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

Layer-2 Switch FTD Inside

Hardening/Extended QA Single Hop Upgrades TLS Hardware Acceleration

Latest Compatible FXOS Version (now 2.3.1.110)

Enable to add column to

• 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

• 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

• 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

• EtherChannel uses LACP (Link Aggregation Control

Protocol) to allow dynamic bundling and dynamic

What is a vPC EtherChannel?

• Virtual Port Channels (vPC) are common 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