Firewall Architectures

BRKSEC-2021

Mason Harris CCIE # 5916

Solutions Architect
masonh@cisco.com
Your Speaker

Mason Harris CCIE #5916

masonh@cisco.com
Solutions Architect
15 years at Cisco
10th Year as a Cisco Live Speaker

@mason_harris
Cisco ASA Sessions: Building Blocks
BRKSEC-2020 BRKSEC-2021 BRKSEC-3032
Firewall Firewall ASA Clustering
Deployment Architectures Deep Dive
(Mon 10:00) (Wed 08:00) (Th 10:00)

BRKSEC-3021 BRKSEC-2028
Maximizing Firewall Deploying NG
Performance Firewall
(Tue 08:00) (Mon 08:00)
(Th 13:00)
Agenda
Introduction
Deployment Modes
Routing on the ASA
Firewall Virtualization
ASA High Availability
Advanced ASA Deployments
Summary
INTRODUCTION
Introduction What is Firewall Architecture?
Deploying any firewall means a consideration of the surrounding
network and the reasons for deploying a firewall
This session will focus on different ways Cisco firewalls are deployed
Cisco firewalls can be physical or virtual or a combination of both
Best practices and gotchas/caveats will be shared and discussed
This session does not cover IOS firewall, Firewall Services Module
(FWSM) or ASA Next Generation Firewall (FirePOWER services)
Please ask questions, well be moving fast
PHYSICAL FIREWALLS
Physical Firewalls: Service Modules and Appliances
Cisco currently only has one service module firewall, the ASA SM for the
Catalyst 6500-E
SM firewalls have no physical interfaces and rely entirely on the existing
switching infrastructure for packet flow
Uses VLANs to redirect which packets are inspected or bypassed
Appliance firewalls can be deployed in more places in the network but require
physical cabling
Additional services are available (e.g. remote access VPN) on physical firewalls
that dont exist on blade firewalls
ASA SM and ASA appliances run same code and have same features (mostly)
Physical Firewalls: ASA Service Module
Supported on Catalyst 6500-E and 7600
Treat as an external firewall on a stick
Critical design around SVI placement for L3
Up to 4 modules in one chassis
Completely based on ASA5585-X architecture with full feature parity
VPN is supported with ASA 9.0(1)+, ASA clustering is not supported
Physical Firewalls: ASA 5585 Appliances
2 slots (2 RU): FW+FW, FW+NGIPS (FirePOWER on ASA), or I/O Expansion card
Top end 5585s provide 4 10GE ports (SFP)
I/O card(s) can add up to 20 10GE ports
20 GBps multiprotocol per appliance (5585-60)
10 million connections per appliance (5585-60)

2 5585s can be stacked in one chassis as shown above

DEPLOYMENT MODES
Firewall Design: Modes of Operation
Routed Mode is the traditional mode of the firewall. Two or more
interfaces that separate L3 domains
Transparent Mode is where the firewall acts as a bridge functioning
mostly at L2
Multi-context mode involves the use of virtual firewalls, which can be
either routed or transparent mode
Mixed mode is the concept of using virtualization to combine routed and
transparent mode virtual firewalls (ASA 9.0+)
What is a Transparent mode Firewall?
Transparent Firewall (L2) mode provides an option in environments where
existing services cant be sent through the firewall at L3
Very popular mode in data center environments
In L2 mode:
Routing protocols can establish adjacencies through the firewall
Protocols such as HSRP, IPSEC, GLBP can pass with ACL
Multicast streams can traverse the firewall
Non-IP traffic can be allowed (IPX, MPLS, BPDUs)
NO dynamic routing protocol support or VPN support
Specific design requirements, reference Configuration Guide for details:
http://www.cisco.com/c/en/us/support/security/asa-5500-series-next-generation-firewalls/products-installation-and-
configuration-guides-list.html
How Does Transparent Mode Work?
Firewall functions like a bridge (bump in the wire) at L2, only ARP packets
pass without an explicit ACL
Still can use traditional layer 4-7 ACLs on the firewall
Does not forward Cisco Discovery Protocol (CDP)
Service modules are supported, multi-context mode is supported
Same subnet exists on all interfaces in the bridge-group
Different VLANs on inside and outside interfaces
In addition to Extended ACLs, use an EtherType ACL to restrict or allow L2
protocols
Transparent Mode Requirements
Uses logical entities called bridge-groups to segment traffic, each has 1 BVI
A BVI (Bridged Virtual Interface) address is required for both management and
for traffic to pass through the transparent firewall
Up to 4 interfaces are permitted per bridge-group (inside, outside, DMZ1, DMZ2)
Up to 250 bridge-groups (9.3), prior releases limited to 8
Best Practice: Always set default gateways of hosts to L3 on far side of firewall,
NOT the management IP of firewall
In multi-context mode an interface can not be shared among contexts (virtual
firewalls)
 Transparent Mode Configuration (2 interfaces)
firewall transparent
hostname ciscoasa
10.1.1.0 /24 vlan 20 !
interface GigabitEthernet0/0
vlan 20
nameif outside
Bridge-group

Same security-level 0
bridge-group 1
subnet BVI 1: 10.1.1.100 /24
(Bridge Virtual Interface) !
1

on interface GigabitEthernet0/1
both! vlan 10
nameif inside
security-level 100
bridge-group 1
!
10.1.1.0 /24 vlan 10 interface BVI1
ip address 10.1.1.100 255.255.255.0
Firewall - Routed Mode
hostname ciscoasa
10.99.1.0 /24 !
interface GigabitEthernet0/0
nameif outside
security-level 0
10.99.1.1 - outside ip address 10.99.1.1 /24
!
interface GigabitEthernet0/1
nameif inside
security-level 100
ip address 10.1.1.1 /24
!
10.1.1.1 - inside
Routed mode has a routing
table, ASA operates at L3
10.1.1.0 /24
ASA can use routing protocols
ROUTING ON THE ASA
Routing and the ASA
ASA IOS router, but has evolved over time to add more routing functions
Understanding the Next Hop selection process on ASA is critical
ASA supports EIGRP, OSPFv2/v3, RIP, BGP and PIM-SM
Separate management routing table in 9.5(1) (July 2015)
ASA supports floating static routes
ASA Failover synchronizes routing table as part of state sync process
ASA Clustering also syncs routing table but process depends on deployment
Routing is supported in multi context mode; EIGRP and BGP can only have
one instance per context while OSPF v2 can have up to two
Routing and the ASA Continued Proxy ARP
Proxy ARP is used when a device responds to an ARP request with its own
MAC address despite not owning that MAC address
ASA has it on by default but requires show run all to see in configuration
no sysopt noproxyarp <interface>
Useful for NAT translations and other things where ASA is hiding the true
identity of a service
Many networks have suffered due to a misunderstanding of this command
Excellent summary blog post by Paul Stewart:
http://www.packetu.com/2011/11/07/the-asas-arp-behavior/
Non-Stop Forwarding (NSF) aka Graceful Restart
Traditionally when a network device restarts, all routing peers associated with
that device will remove the routes from that peer and update their routing table
At scale this could create an unstable routing environment across multiple
routing domains which is detrimental to overall network performance
Modern dual processor systems solve this problem by restarting the control
plane on one processor while continuing to forward traffic on the other
For devices that support NSF, route removal and insertion caused by restarts is
no longer necessary thus adding network stability
Uses protcol extensions to allow network device a grace period in which traffic
will continue to be forwarded via existing routes
Non-Stop Forwarding (NSF) on ASA (9.3)+
Pre 9.3: Routing Information Base is replicated in A/S failover and Spanned
Etherchannel clustering
Active unit or master establish dynamic routing adjacencies and keep standby and slaves up-
to-date
When the active unit or master fails, the failover pair or cluster continue traffic forwarding
based on RIB
New active unit or master re-establish the dynamic routing adjacencies and update the RIB
Adjacent routers flush routes upon adjacency re-establishment and cause momentary traffic
black holing
9.3 and after: Non Stop Forwarding (NSF) / Graceful Restart (GR)
Cisco or IETF compatible for OSPFv2, OSPF3; RFC 4724 for BGPv4
ASA notifies compatible peer routers after a switchover in failover or Spanned Etherchannel
clustering
ASA acts as a helper to support a graceful or unexpected restart of a peer router in all modes
Legacy Equal Cost Multi Path (ECMP) on ASA
Supports up to 3 Equal Cost Multi Path
(ECMP) routes on same interface 10.1.1.1 10.1.1.2 10.1.1.3

route outside 0 0 10.1.1.1

route outside 0 0 10.1.1.2
route outside 0 0 10.1.1.3
outside
Traffic is load-shared on outside interface
across three gateways using a hash of
source and destination addresses
Not supported across different interfaces
New Feature Interface Traffic Zones - 9.3+
Assign multiple physical and/or logical interfaces to a
Security Zone
Same-prefix ECMP with up to 8 next hops across all Zone-Out
interfaces in a zone; up to 256 zones maximum
All interfaces must have same security level outside1 outside2

inside 1 inside 2
Seamless connection switchover to another egress
interface in the same zone on failure butNAT/PAT Zone-In
sessions will need to be re-established
Helpful with assymetric routing and load-balancing
deployments, Not supported for VPN, BTF,
management or failover
http://www.cisco.com/c/en/us/td/docs/security/asa/asa93/configuration/general/asa-general-cli/interface-zones.html
Legacy Static Route Tracking via SLA
Static routes areum..static
192.168.1.100
ASA has had a tracking feature for many years
GW-A - Primary GW-B - Backup
to ensure that a next hop is up
Does NOT load-balance; uses an active-
standby model 10.1.1.1 10.2.2.1

route outside 0 0 10.1.1.1 1 track 1

route backup 0 0 10.2.2.1 254 outside
sla monitor 23
type echo protocol ipIcmpEcho 192.168.1.100
interface outside
sla monitor schedule 23 life forever start-time now
track 1 rtr 23 reachability
New 9.4+ Feature Policy Based Routing (PBR)
PBR effectively overrides the default route-map TEST permit 10
behavior of the ASA routing table match ip address <acl>
set ip next-hop 10.1.1.1
Similar in function to IOS feature; uses
ACL for matching in a route-map route-map TEST permit 20
match ip address <acl>
Only supported in routed mode on ASA, set ip next-hop 10.2.2.1
also supported in ASA Clustering
route-map TEST permit 30
Supports QoS and next hop manipulation set interface Null0
No match criteria implies a match any
Traffic not matching line 10 or 20 is
dropped by Null0 interface
 TRANSPARENT MODE:
Architecture and Deployment
ASA L2 FW: ASA between Hosts and Gateway
Local 10.1.1.x /24
Gateway

Vlan 20 Vlan 10
(Untrusted/Outside) (Trusted/Inside)

vlan 20 VIP: 10.1.1.254 ASA BVI: 10.1.1.100 Hosts: 10.1.1.1-99

ASAs in transparent mode with upstream L3 gateway

Server gateway on outside/untrusted side of firewall
Firewall is L2 adjacent and in path to hosts
Segmentation through VLAN assignment
ASA L2 FW: Intra VDC Insertion
Nexus Optional L3 path for FW bypass Nexus
7K VDC 7K VDC Single L2 Domain

FW Outside FW Inside

vlan 20 vlan 10
Virtual
Hosts
10.199.199.1 10.199.199.2
Server GW

ASA in either L2 or L3 mode, L2 is optimal in most cases

Add VRFs on Cat 6500 or Nexus 7K for segmentation
Server gateway inside of firewall
Minimizes firewall failures, route around failures if needed
ASA L2 FW: Inter VDC Insertion
Transparent (L2) firewall services are
sandwiched between Nexus Virtual
Device Contexts (VDC) N7k1-VDC-1
Core
Allows for other services (IPS, LB, etc) to
be layered in as needed vrf1 vrf2

ASAs can be virtualized to for 1x1

mapping to VRFs
Useful for topologies that require a FW
between aggregation and core N7k1-VDC-2
Aggregation
Firewalls could be L2 or L3
vrf1 vrf2
Case Study: L2 Firewall Between Two L3 Devices
Stateful inspection point is required a L2 firewall between L3 links
Firewall is processing at L2 (VLANs) while L3 services are unaffected if
permitted by firewall access control list (ACL)
Layer 3 point-to-point links

ISP-A
ISP A
Transparent
L3 Routed ASA
Internal placement provides ACL
Network Core inspection
and stateful Fully
Meshed
without disturbingBGP
existing
Layer 3 services
ISP-B
ISP B

Routed core with fully meshed BGP

Case Study: Transparent Firewall Logical View
L3 Switch/Router L3 Switch/Router

ISP A
Active ASA

VLAN trunks loop Active/Standby Failover control

Internal
traffic through the redundancy with link is a back-to-
Network transparent firewalls ASA failover back connection

Standby ASA

ISP B
L3 Switch/Router L3 Switch/Router
 Case Study: Transparent Firewall Traffic Flow
3. Connection passes
back through the switch at
Layer 2 toward the next Outside
routed hop on outside VLAN 101

1. Outbound
connection comes 192.168.0.3/29
in through inside
VLAN to SVI 100

192.168.0.1/29 SVI 100 2. Routing points to

192.168.0.3 as next hop,
passed through the
transparent ASA trunk

Internal
VLAN 200 Inside VLAN 100

Outside VLAN 101

192.168.0.2/29 SVI 100
Outside 192.168.0.4/29
VLAN 101
 FIREWALL
VIRTUALIZATION:
Multiple Context Mode and ASAv
ASA Multi Context Mode
Multiple virtual firewalls operate concurrently on a single physical device
Each such firewall is called a context, up to 250 contexts total
Independent interface sets, policies, routing tables, management, and so on
Inter-context routing via shared interfaces with virtual MAC addresses on ASA
Commonly deployed in VRF environments at intersection points
Internet
All contexts share limited hardware resources
Some resources can be limited on per-context basis
No VPN support except LAN-to-LAN tunnels in ASA 9.0+ Single
Physical
ASA Chassis

PCI Vendor Corp

Resource Management
You can limit the per-context usage of certain resources
Management sessions, connections, xlates, inspects, syslogs, VPN, routes
Both total counts and per-second rates could be limited
Memory, CPU, interface rates, and other platform resources cannot be limited

Limits are applied with resource classes:

asa(config)# class gold
asa(config-class)# limit-resource route 5000
asa(config-class)# context HR
asa(config-ctx)# member gold

%ASA-5-321001: Resource routes' limit of 5000 reached for context vfw1

Configuring a Multiple Context ASA
Context = a virtual firewall
All virtualized firewalls must define a System context and an Admin context

Admin Context: VFW

Virtual Firewall
Remote root access and Admi 1
contexts
access to all contexts n
VFW
2
System Context:
Physical ports assigned System VFW
3

There is no policy inheritance between contexts

The system space uses the Admin context for network connectivity
Multi Context Mode - Common Deployment
VLAN 11 VLAN 21 VLAN 31 VLAN 41

Single
Physical
VFW VFW VFW VFW ASA
1 2 3 4

VLAN 10 VLAN 20 VLAN 30 VLAN 40

Firewalls can be in transparent or routed mode or both (mixed mode 9.0+)

Physical links are typically trunks but could be physical interfaces
Contexts in routed mode can share VLANs, but not in transparent mode
ASA Multiple Context Mode Segmentation

One physical ASA

Security Services
Contexts could represent different Enclave/Zone/Swim Lane
tenants or VRF networks
Contexts can be stacked
Network devices can exist inside of
protected enclave/zone/swim lane
Creates separation via contexts
ASA Multiple Context Mode Configuration
interface Ethernet0/0 !
! class default
interface Ethernet0/0.1 limit-resource All 0
vlan 10 limit-resource ASDM 5
! limit-resource SSH 5
interface Ethernet0/0.2 admin-context admin
vlan 20 context admin
! allocate-interface Ethernet0/2 outside
interface Ethernet0/1 allocate-interface Ethernet0/3 inside
! config-url disk0:/admin.cfg
interface Ethernet0/1.1 !
vlan 11 context vfw1
! allocate-interface Ethernet0/0.1 outside-vfw1
interface Ethernet0/1.2 allocate-interface Ethernet0/1.1 inside-vfw1
vlan 21 config-url disk0:/context1.cfg
! !
interface Ethernet0/2 context vfw2
! allocate-interface Ethernet0/0.2 outside-vfw2
interface Ethernet0/3 allocate-interface Ethernet0/1.2 inside-vfw2
config-url disk0:/context2.cfg
ASA Multi Context Mode Configuration (Contd)
ciscoasa/vfw1 (config)# show run
ASA Version 9.0
!
hostname vfw1
enable password 8Ry2YjIyt7RRXU24 encrypted
!
interface inside-vfw1
nameif inside
security-level 100
ip address 172.17.1.1 255.255.255.0
!
interface outside-vfw1
nameif outside
security-level 0
ip address 10.2.2.1 255.255.255.0
Dynamic Routing in Multi-Context Mode
Routed contexts support OSPFv2 and EIGRP in ASA 9.0(1)+
BGP support in 9.2(1)
Separate routing table, database, and adjacencies in each context
OSPFv2 and EIGRP can be configured independently in each context
OSPFv2 and EIGRP can both be configured in the same context
2 instances of OSPFv2 and 1 instance of EIGRP per context

No inter-context peering through the shared interface

Static inter-context routes are supported
RIP, OSPFv3, and PIM are not supported in multi-context mode
To Use Multi Context Mode or Not?
Good fit for SPs who want to deploy a single appliance for multiple customers
Good fit for VRF segmentation where VLANs map to VRFs
Cant virtualize CPU or memory, careful with network surges
Cant easily share interfaces in transparent (L2) mode
Operationally more complex, management tools treat each context like a
separate firewall
Licensed feature $$$
Some ASA features arent compatible with virtualization
Cant easily reboot a context
What are North-South and East-West Flows?
Core

North-South (N-S) flows are

North - South
typically flows to and from Aggregation
Access layer to
Aggregation Layer and
Core
East-West (E-W) flows Access
typically stay either within a Virtual Virtual Virtual
zone or between zones and Hosts Hosts Hosts
often server to server traffic
Web Database App
East - West
Where to Place the Firewall?
Centralized firewalls are the traditional
approach to virtualized host security
Often a transitional architecture
Firewalls in the core, aggregation or edge?
Big challenge is scalability
Usually the limiting factor is connections
not bandwidth
How to handle a requirement for L2
(micro)segmentation of hosts?
How to address virtual host mobility? Hosts Hosts Hosts
Ciscos Legacy Virtual Firewalls: VSG and
ASA1000V
Cisco has two legacy virtual firewalls: the ASA 1000V and the Virtual Security
Gateway (VSG)
Each runs as a virtual machine in VMWare
Both are managed via Virtual Network Management Center (VNMC)
Both are licensed per CPU socket
They are complementary to each other and require the Nexus1000V Distributed
Virtual Switch and utilize a new forwarding plane, vPath
ASA 1000V
End-of-Sale
March 2015
Virtual Security Gateway ASA 1000V
What is the Virtual Security Gateway?
VSG is a L2 firewall that runs as a virtual
machine bump in the wire
It provides stateful inspection between L2
adjacent hosts (same subnet or VLAN)
It can use VMware attributes for policy
Provides benefits of L2 separation for East-
West traffic flows
Virtual Virtual Virtual
One or more VSGs are deployed per tenant Hosts Hosts Hosts
Requires Nexus 1000V dVS
VSG Deployment Guide: http://www.cisco.com/en/US/prod/collateral/modules/ps2706/ps11208/deployment_guide_c07-647435.html
ASA Evolution
2005 - Present 2012 2015

ASA 1000V
ASAv
Unique ASA
Codebase Same
Physical ASA codebase as
ASA 5500 and Physical ASA
5500-X family No L2 mode
No RA VPN
No Routing Protocols Clustering and
Limited Features Multiple Contexts
Introducing the Virtualized ASA (ASAv)
Introduced with ASA 9.2 code release (April 2014)
No Nexus1000V requirement
Currently supported on Vmware vSphere (5.x) and KVM
Has all ASA features with some exceptions
No support for:
1. ASA clustering
2. Multi context mode (cant virtualize a vm) ASAv Firewall
3. Etherchannel interfaces
(Virtualized ASA)
4. Active/Active Failover (requires multi context mode)

ASAv Deployment Guide: http://www.cisco.com/c/en/us/td/docs/security/asa/asa92/configuration/general/asa-general-cli/intro-asav.html#pgfId-1156584

ASAv: A Deeper Look
Supports ALL features of hardware ASA except those noted previously
Runs ASA 9.2+ code and features (same as physical ASA)
Up to 10 interfaces
Flexible licensing based on vCPU usage, intended to simplify
deployment, first ASA to get Smart Licensing feature
Managed like a hardware ASA: CLI, ASDM or Cisco Security Manager
(CSM) and REST API
Cisco.com registered users can download ASAv for home use (limited to
100kbps and 2 VPN conns)
ASAv: Deployment Best Practices
Stateful Inspection at the edge or for inter-VM traffic
Routed (L3) or transparent (L2) mode firewall
Multi-tenant environments
Cloud environments that require scalable, on demand, stateful access
control or remote access VPN
Where ASA1000V is deployed today
Performance is based on underlying hardware: single ASAv consumes
1 vCPU and 2GB of RAM
Requires VMware vCenter for deployment
Comparing Cisco Virtual Firewalls
ASAv Virtual Security Gateway

L2 and L3 mode L2 mode (transparent)

Dyn and static routing No routing
DHCP server and client No DHCP support
support
S2S and RA VPN No IPSEC support

Managed via CLI, ASDM, Managed by VNMC only

CSM
Full ASA code, CLI, SSH, Minimal config via CLI, SSH
REST API
FIREWALL HIGH
AVAILABILITY
Firewall High Availability Options
Like any other critical network device, firewalls must be deployed in a
highly available manner
This includes ports, links, data plane and control plane
ASA Active/Standby failover has been the standard approach
For: no single point of failure, stateful failover
Against: Deployed only in pairs, no sharing of load
ASA clustering provides unique advantages for elastic scaling
BP: Interface redundancy at Layer 2 is optimal vs full switchover
No disruption for transit traffic on single link failure with logical interface bundles
Device level switchover typically carries some convergence penalty
Interface Redundancy: Backup Interfaces
Backup interfaces aggregate two
physical interfaces as one logical
interface interface redundant 1
member-interface tengigabitethernet 0/6
No link aggregation, only L1 member-interface tengigabitethernet 0/7
redundancy nameif inside
ip address 10.1.1.2 255.255.255.0
No disruption of service to upper
layer protocols
Single MAC and IP or bridge-group
Can only be deployed in pairs
Up to 8 pairs of redundant
Red line is active link
interfaces can be configured
Black line is standby link
Interface Redundancy: Port Channels
interface TenGigabitEthernet0/8
Best practice: Utilize Link Aggregation channel-group 40 mode active
Control Protocol (LACP) where possible no nameif
no security-level Actively
LACP dynamically adds and removes (if negotiate
necessary) links to the port channel ! LACP with
interface TenGigabitEthernet0/9 switch
bundle
channel-group 40 mode active
Up to 8 active links in ASA 8.4+ and 16 no nameif
active links in 9.2(1)+ no security-level
!
Link aggregation benefit interface Port-channel40
nameif inside
Best practice in Nexus DC is to use ip add 10.1.1.2 255.255.255.0
Virtual Port Channels (vPC)
Best practice: use LACP where possible
Show port-channel summary' on ASA
Flags: D down P - bundled in port-channel
I - stand-alone s suspended
H - Hot-standby (LACP only)
U - in use N - not in use, no aggregation/nameif
M - not in use, no aggregation due to minimum links not met
w - waiting to be aggregated

Number of channel-groups in use: 1

Group Port-channel Protocol Span-cluster Ports
------+-------------+---------+------------+---------------------------
40 Po40 (U) LACP No Te0/8(P) Te0/9(P)
Virtual Port Channels (vPC) and the ASA
Virtual Port Channels (vPC) are port channels ASA
where both links are actively forwarding traffic
VPC was created to solve two inherent network
problems: Spanning-tree recalculation times and
unused capacity in redundant L2 uplinks (due to
STP blocks)
No additional config required on ASA
Supported only with Nexus switches
VPC Design Guide:
http://www.cisco.com/en/US/prod/collateral/switches/ps9441/ps9670/C07-
572830-00_Agg_Dsgn_Config_DG.pdf
Nexus 5K/7Ks
Port Channel Options and Summary
vPC Multi-Chassis LACP Port
Channel:
Both links active, optimal redundancy,
No Port Channel: all links active
STP Allows only one active link
Sub-optimal flows and resource
usage

VPC PEER LINK

Single-Chassis LACP Port

Channel:
Both links active but no device
Slide courtesyredundancy (single switch)
of Mike Storm
FAILOVER AND
CLUSTERING
 ASA Active/Standby Failover
HA
Interconnects
A pair of identical ASA devices can be configured in
Failover
Data interface connections must be mirrored between the
units with L2 adjacency Active Standby
Firewall Firewall
IP and MAC addresses on data interfaces move with the (Primary) (Secondary)
active unit
Centralized management from the active unit or context
Stateful failover mirrors stateful conn table between peers
Stateful failover makes Active/Active impractical for scaling
Failover delivers high availability not scalability
 Two Types of ASA Failover Primary

Active/Standby Failover
Single- or multiple-context mode Inside Outside

Device-level switchover on failure

One unit is always idling Secondary Secondary
ASA
Simple design for single tenant Primary

Active/Active Failover
A
Requires multiple-context mode Inside A
Switchover based on context groups B Outside A
Both units are passing traffic
Design caveats exist Inside B
A
Outside B
B
Secondary
ASA Clustering For Scalable High Availability
ASA Clustering was introduced in the 9.0 release (October 2012) to solve the
problem of redundancy with scalability
Allows for N+1 redundancy with a backup firewall for every active flow
An ASA cluster is treated by the network as one logical firewall
Configuration is synchronized among cluster members
Three reasons to consider ASA Clustering:
1. Redundancy no single point of failure, actively using all cluster members
2. Scalability cluster can grow as requirements increase over time
3. Asymmetric flow reassembly the cluster maintains symmetry for all conns
ASA Clustering System Requirements
All cluster members must have identical hardware configuration
Up to 8 ASA5580/5585-X in ASA 9.0 and 9.1; up to 16 ASA5585-X in ASA 9.2(1)+
Up to 2 ASA5500-X in ASA 9.1(4)+
SSP types, application modules, and interface cards must exactly match

Each ASA5580/5585-X member must have Cluster license installed

Enabled by default on ASA5500-X except ASA5512-X without Security Plus
3DES and 10GE I/O licenses must match on all members

Limited switch chassis support for control and data interfaces

Catalyst 6500 with Sup32, Sup720, or Sup720-10GE and Nexus 7000 in ASA 9.0+
Catalyst 3750-X and Nexus 5000 in ASA 9.1(4)+
Nexus 9300 in 9.2(1)+
ASA Clustering Scalability
Throughput scales at 70% of the aggregated capacity on average
16 ASA5585-X SSP-60 at 20Gbps 224Gbps of Real World TCP
throughput
Scales at 100% with no traffic asymmetry between members

Concurrent connections scale at 60% of the aggregated capacity

16 ASA5585-X SSP-60 at 10M 96M concurrent connections
Connections rate scales at 50% of the aggregated capacity
16 ASA5585-X SSP-60 at 350K CPS 2.8M CPS
CCL Best Practices
Size and protect CCL appropriately
Bandwidth should match maximum forwarding capacity of each member
Use an LACP Etherchannel for redundancy and bandwidth aggregation
20Gbps of Real World traffic with ASA5585-X SSP-60 2x10GE CCL
Dual-connect to different physical switches in vPC/VSS
Cannot use service blade expansion interfaces for CCL VPC
Use interface cards for extra 10GE ports in ASA 9.1(2) and later
Set MTU 100 bytes above largest data interface MTU
Avoids fragmentation of redirected traffic due to extra trailer CCL CCL

Ensure that CCL switches do not verify L4 checksums

TCP and ICMP checksums for redirected packets look invalid on CCL
ASA Cluster
Enable Spanning Tree Portfast and align MTU on the switch side
Spanned Etherchannel Data Interface Mode
Mix transparent and routed firewalls contexts
Must use Etherchannels: firewall-on-a-stick VLAN trunk or separate
All units use the same virtual IP and MAC on each logical data interface
Seamless load-balancing and unit addition/removal with cLACP
VPC 1 inside outside VPC 2
192.168.1.0/24 ASA Cluster 172.16.125.0/24

Te0/6 Te0/8

Te0/7 Te0/9
.1 .1
Te0/6 Te0/8

Te0/7 Te0/9
Individual Data Interface Mode
Routed firewall contexts only
Master owns virtual IPs on data interfaces for management purposes only
Use ECMP/PBR or dynamic routing protocols to load-balance traffic
Members get data interface IPs from configured pools in the order of joining
Per-unit Etherchannels support up to 16 members in ASA 9.2(1)+
inside outside
192.168.1.0/24 ASA Cluster 172.16.125.0/24
VPC
Te0/6 Te0/8 .1
.1 .2 .2
Te0/7 Te0/9
Master

Te0/6 Te0/8
.3 .3
Te0/7 Te0/9
Slave
Dynamic Routing and Clustering
Master unit runs dynamic routing in Spanned Etherchannel mode
RIP, EIGRP, OSPFv2, OSPFv3, BGP4 and PIM
Routing and ARP tables are synchronized to other members like in failover
Slower external convergence only on Master failure

Each member forms independent adjacencies in Individual mode

Same protocols as in Spanned Etherchannel, but multicast data is centralized as well
Slower external convergence on any member failure
Creative designs are possible with split clusters

Reduce protocol timers on both sides to speed up convergence

asa/master(config)# interface GigabitEthernet0/0
asa/master(config-if)# ospf hello-interval 1
asa/master(config-if)# ospf dead-interval 2
asa/master(config-if)# router ospf 1
asa/master(config-router)# timers spf 1 1
Port Channel Verification
asa(cfg-cluster)# sh port-channel summary
Number of channel-groups in use: 2
Group Port-channel Protocol Span-cluster Ports
------+-------------+---------+-----------+--------------------
32 Po32(U) LACP Yes Te0/6(P) Te0/7(P)
40 Po40(U) LACP No Te0/8(P) Te0/9(P)

PC 32 is the cluster data plane; PC 40 is the cluster control plane

Note that CCL is not a span-cluster port-channel (best practice)
Both are up as noted by the (U) and were negotiated via LACP
The spanned port-channel will not come up until clustering is enabled
Unsupported ASA Features with Clustering
SSL and IPSEC remote access VPN (Site to Site VPN is supported)
Legacy VPN load balancing is not supported for S2S VPNs
Botnet Traffic Filter (BTF)
DHCP Client, Server and Relay
Unified Communications features and inspection engines (SIP in 9.4)
WCCP
Some application inspection features (see Release Notes)
ASA AUTOMATION
REST API on ASA
Historically the ASA firewall has been managed via CLI or GUI (ASDM or Cisco
Security Manager)
Some customers use scripting tools to make programmatic changes
Growing need on ASA platform to have a standards-based approach, especially
combined with value of orchestration tools for virtual deployments
REST is based upon client-server model over HTTPS, lightweight approach
Allows for Create, Read, Update and Delete operations
My blog post gives a general overview
at:http://www.networkworld.com/article/2921386/security0/digging-deeper-into-
the-cisco-asa-firewall-rest-api.html
REST API on ASA - Continued
Requires REST
API agent to be
installed on ASA
and enabled
Supported on both
physical and virtual
ASA (ASAv)
Can use other
methods for
management
Excellent docs
console
Embedded Event Manager (EEM) (9.2)
EEM is a subsystem that originated in IOS for automation
On the ASA it allows programmatic responses to certain conditions (if-then) that
are useful for debugging and long term troubleshooting
Consists of two parts: events to which EEM listens and manager applets that
define actions
ASA EEM supports three types of events:
Syslog uses message ids as triggers
Timers Watchdog (periodic), Countdown (one-shot), Absolute (once-a-day)
Crash triggered when ASA is crashes

Supported in routed and transparent mode; not supported in multicontext mode

ADVANCED ASA
DEPLOYMENTS
 Deploying ASA at Internet Edge with Routing
A/S pair
OSPF v2/v3 and EIGRP
BGP as of ASA 9.2+
Both eBGP and iBGP, up to 500 peers
OSPF v2,v3
EIGRP Supported on ASAv
BGP Supported in Multi Context Mode
ASA can act as a multi homed edge Up to 100K routes
router and support VPN services
concurrently BGP support with clustering (9.3)+
VPN support could be for S2S IPSEC or
Remote Access VPN or both
Should I Deploy ASA Clustering at the Internet
Edge?
2 Unit cluster
ASA 9.1.4+ extends clustering to
5500-X family
2 units max
9.1.4 added support for 3750-X
Yes, if you need Active/Active firewalls switch for this reason
Yes, if you only need IPSEC S2S support and firewalling
Yes, if you use OSPF, EIGRP or BGP
No, if you require Remote Access VPN support
No, if you require inspection engine support for multimedia protocols (SIP
support in 9.4)
ASA Stacked Clusters and Multi Context Mode
ASA clustering and multi Logical Topology
context mode allow for
Physical Topology complex deployment
scenarios
Topology on right shows 4
cluster members stacked
on top of each other in the
data center
Network devices can be
sandwiched in between
virtualized clusters
Asymmetric flow
reassembly, etc.
ASA Clusters and Multi Context Mode Contd
Context 1 Context 2 Context X

Same physical topology as previous slide

This topology is where two separate access control policies are
required, ASA clusters could be L2 or L3
Physical cabling does not have to change (optional)
Clustering Across Multiple Data Centers
Until Dec 2013 ASA clustering was supported only in the same DC
Increasingly customer requirements and interest were around spanning an ASA
cluster across multiple DCs
Geographically separated clusters are supported now with 9.1.4+ under these
conditions:
Dark Media CCL with less than 10ms of one way latency
Routed (L3) firewall in individual interface mode only
ASA 9.2 extends Inter-DC clustering to Spanned Etherchannel mode
Transparent (L2) firewall only
Only the CCL can be used via dark media or overlay method, not data plane
For a deeper dive see the BRKSEC-3021 session dedicated to ASA clustering
Split or Single Individual Mode Cluster in Inter DC
Site A Site B
ASA Cluster
CCL is fully extended between ASA 9.1(4)+
DCs at L2 with <10ms of latency

CCL CCL CCL CCL

Data interfaces
connect to local
switch pair only Data Data
Data VLANs do not extend
with a split cluster to
localize traffic to site

Transit connections are not

vPC 1 contained to local site with vPC 2 Local VPC/VSS
extended data VLANs pairs at each site
Local VPC/VSS
pairs at each site
 Extended Spanned Etherchannel Cluster in Inter DC
Site A Site B
ASA Cluster
CCL is fully extended between
DCs at L2 with <10ms of latency
ASA 9.2+

Data CCL CCL Data

Each cluster member can All data interfaces bundle into a

single- or dual-connect to
the VSS/vPC pair for CCL
and Data
Transit connections are not
single Spanned Etherchannel
contained to the local site

vPC Peer Link

vPC logical switch pair is

stretched across sites
 Split Spanned Etherchannel Cluster in Inter DC

Site A Site B
ASA Cluster
CCL is fully extended between
ASA 9.2+
DCs at L2 with <10ms of latency

CCL Data CCL Single Spanned CCL Data CCL

Etherchannel for Data
Local Data on cluster side Local Data
Etherchannels on Etherchannels on
each VPC/VSS each VPC/VSS
switch pair switch pair

Data VLANs are not

vPC 1 extended to prevent loops vPC 2
Local VPC/VSS
Local VPC/VSS pairs at each site
pairs at each site
Remotely Triggered Black Holes (RTBH)
Route an IP address or prefix to the bit bucket at the network edge
Prevent malicious traffic from entering the secure network and consuming resources
Destination blocking temporarily drops all traffic to a protected resource until the attack
stops
Source blocking drops all traffic from a malicious host or subnet at the perimeter

Basic routing features propagate a drop rule across administrative domains

Ability to set an arbitrary next-hop in BGP, Null0 static routes, and Reverse Path
Forwarding (RPF)
Trigger device injects the rule into iBGP routing domain, blocking router drops traffic
based on rule
ASA can operate as the trigger or blocking device with BGP in 9.2+
 RTBH Trigger on ASA Example
route-map RTBH Create a route map to set the
set ip next-hop 192.0.2.1 next hop for any matching
set origin igp
set community no-export
advertised routes to the
router bgp 65001 blackhole IP address
neighbor 192.168.100.1 remote-as 65001
redistribute static route-map RTBH
Redistribute all static routes using
the route map for blackholing
Advertise a static route to the 3. Subsequent packets from
route Null0 10.1.1.1 255.255.255.255
attacker using the route-map 10.1.1.1 are dropped at the
Provider Edge router
PE
BGP
1. Establish BGP peering
between inside ASA and 10.1.1.1
2. ASA administrator
perimeter router with RTBH
identifies 10.1.1.1 as a
configuration
malicious host, configures a Soft uRPF ensures that each source
ip verify unicast source reachable-via any
block rule interface Null0 IP address has a valid return route
no ip unreachables
router bgp 65001
neighbor 192.168.1.1 remote-as 65001 Any traffic recursively routed to the
ip route 192.0.2.1 255.255.255.255 Null0 blackhole IP address will be dropped
Segmentation with ASA
Network (Micro)Segmentation with Cisco Firewalls

VLANs were an early and still the most common tool to segment the
network into smaller units
ASA in transparent mode was designed for this purpose (VLAN
stitching), but L2 domains are still shared
Virtual Security Gateway (VSG) was designed for E-W traffic
(micro)segmentation within the same L2 domain
VxLAN and Security Group Tags (SGTs) provide segmentation options
VxLAN Overview

Layer 2 VLANs create challenges in virtual and cloud infrastructure

Virtual eXtensible LAN (VxLAN) provides scale and flexibility
Up to 16M logical network segments vs 4096 VLANs
Ethernet frames from endpoints are carried in UDP over Layer 3

Virtual Tunnel Endpoint (VTEP) interfaces terminate VxLAN connections

Useful for inserting an external firewall between virtual segments
ASA as VxLAN Gateway
ASA 9.4 supports one VTEP with multiple tunnels per context
System VLAN limit applies to combined VLAN and VxLAN count

One static VTEP peer

(i.e. hypervisor) is VxLAN 10000
supported on ASA VLAN 100
ASA bridges or routes
between different
VxLAN 10100
TenGig0/8 network types

Multiple VTEP peers

require multicast- VxLAN 10200
based discovery

A Virtual Network Identifier (VNI) interface on interface vni1

ASA handles decapsulated VxLAN traffic for segment-id 10000
each segment interface vni2
segment-id 10100
interface vni3
segment-id 10200
Secure Segmentation with ASA
Compute servers and ASA
can be separated by a
routed infrastructure.

Combine hosts with a

similar security role into
a single VxLAN across
multiple compute
Extend all VxLAN segments into servers.
the ASA (virtual or physical) for
secure segmentation. Routed
mode scales best.
Routed Mode VxLAN Gateway

VTEP encapsulates ARP into multicast

to identify the peer for a particular
destination endpoint (MAC address).

ASA and its peers use unicast

and multicast IPv4 UDP to
communicate between outer 10.20.20.101 10.10.10.201
VTEP interfaces. VMs send IPv4/IPv6 packets over
the VxLAN toward inner default
gateway VNI on the ASA.
What are Security Group Tags (SGTs)?
SGTs are metadata carried in a L2 header
Think of it like a global ACL that all devices can share
Addresses two issues:
1. The lack of scalability of ACLs on multiple network devices
2. The ability to combine identity and access control in a single package
Built upon a principle that traffic is tagged at the edge and network
devices enforce a global, consistent access policy throughout the
network, network devices share policy information via SGTs
TrustSec is the marketing name for SGACLs, 802.1x and Identity
networking
SGT eXchange Protocol (SXP)

SGTs are implemented in hardware

VPN authorization result from ISE
Can be assigned via 802.1x, MAB or static
SXP is a mechanism where devices can pull or push IP to
SGT mappings from a native SGT device
ASA supports SXP as a listener and a speaker
 Creating an SGT Access Control Policy
ASA became SGT
aware in 9.0 release
Does not require the Permit PCI devices to
talk to PCI devices
whole infrastructure to regardless of IP
support SGTs address
ASA converts SGTs to
IP addresses
RA VPN users are
tagged on ingress
SGFW Rules Table View

Standard ACE rules (both IPv4 and IPv6) and SGFW rules are all
combined in the same rules table
Data Center Segmentation with Security Group Tags

Web
Servers

Middleware
Storage
Servers ASA
SGFW

Database
Servers
IPv6
IPv6 and Cisco Firewalls
Virtual Security Gateway supports IPv6
ASA code has supported IPv6 for many years and 9.0 release augments IPv6
features (ASA and ASASM)
Very little performance hit with IPv6
AnyConnect IPSEC VPN also support IPv6
ASDM supports IPv6 addresses
NAT46 and 64 support on ASA
Works with Security Group Tags (IPv4 and IPv6)
Unified IPv4 and IPv6 ACLs
Older ASA software used separate IPv4 and IPv6 interface ACLs:
access-list INSIDE_IPV4 extended permit ip host 10.1.1.1 any
ipv6 access-list INSIDE_IPV6 permit ip host 2001:DB8:1 any Any depends on
access-group INSIDE_IPV4 in interface inside the ACL type
access-group INSIDE_IPV6 in interface inside

Any IPv4
ASA 9.0 and newer uses a single ACL for all IPv4 and IPv6
access-list IN extended permit ip host 10.1.1.1 any4 Any IPv6
access-list IN extended permit ip host 2001::1 any6
access-list IN extended permit ip host 10.1.1.1 host 2001:DB8::10 Mixed IPv4 and IPv6
access-list IN extended permit ip any any (Need NAT)

Configuration migration from earlier releases: Any IPv4 or IPv6

Dual interface ACLs are merged

Contextual any conversion applies to ACLs only

Slide courtesy of Andrew Ossipov

ASA IPv6 Best Practices
ACL to block unknown Router Advertisement (RA)
ipv6 access-list outsideACL permit icmp6 host fe80::21e:7bff:fe10:10c any router-advertisement
ipv6 access-list outsideACL deny icmp6 any any router-advertisement
access-group outsideACL in interface outside
interface vlan2
nameif outside
security-level 0
ipv6 address autoconfig
ipv6 enable

Suppress ASA interface Router Advertisements

interface vlan2
ipv6 nd suppress-ra

https://supportforums.cisco.com/docs/DOC-15973
 SUMMARY AND
PARTING THOUGHTS
Summary and Parting Thoughts
Firewall deployment is not as simple as it used to be (to route or not to route?)
ASAv should be used where ASA1000V is present today
Virtualized firewalls (multi context mode) provide a nice option for segmented
networks (VRF Lite, MPLS, etc) and/or decentralized management
Firewall clustering offers advantages over the traditional A/S model especially if
interested in InterDC deployment
ASA L2 mode offers interesting opportunities for non-disruptive deployment
The ASA has robust IPv6 capabilities
Leverage Cisco Validated Designs (CVDs) as a best practice
Participate in the My Favorite Speaker Contest
Promote Your Favorite Speaker and You Could be a Winner
Promote your favorite speaker through Twitter and you could win $200 of Cisco
Press products (@CiscoPress)
Send a tweet and include
Your favorite speakers Twitter handle CiscoDCSecurity
Two hashtags: #CLUS #MyFavoriteSpeaker

You can submit an entry for more than one of your favorite speakers
Dont forget to follow @CiscoLive and @CiscoPress
View the official rules at http://bit.ly/CLUSwin
Complete Your Online Session Evaluation
Give us your feedback to be
entered into a Daily Survey
Drawing. A daily winner
will receive a $750 Amazon
gift card.
Complete your session surveys
though the Cisco Live mobile
app or your computer on
Cisco Live Connect.
Dont forget: Cisco Live sessions will be available
for viewing on-demand after the event at
CiscoLive.com/Online
Continue Your Education
Demos in the Cisco Campus
Walk-in Self-Paced Labs
Table Topics
Meet the Engineer 1:1 meetings
Thank you
ADDITIONAL SLIDES
Failover Interfaces
Failover Control Link is vital to the health of a Failover pair
failover lan interface FOVER_CONTROL GigabitEthernet0/0

Carries bi-directional control, keepalive, and configuration messages

Dedicated interface of each unit should connect to an isolated secure network
Back-to-back cable connections with a Redundant interface for most protection
Failover is disabled when Failover Control Link connectivity is interrupted

State Link latency should be <10ms and must be <200ms

failover link FOVER_STATE GigabitEthernet0/1

Data interface monitoring requires Standby IP addresses

Each unit monitors the health of its interfaces and compares with the peer
ip address 192.168.1.11 255.255.255.0 standby 192.168.1.12

Active virtual MAC address is inherited from the physical interface of the primary
ASAv and VSG Compared
ASAv with 4 vCPU Virtual Security Gateway
Throughput 1-2GB stateful vPath
Max Concurrent
Sessions
500,000 256,000

Max Conns/Sec 60,000 6K-10K (1vCPU/2vCPU)

S2S VPN Sessions 750 NA

AnyConnect Sessions 750 NA

VM Attributes Used by VSG (Partial List)
Name Meaning Source

vm.name Name of this VM vCenter

vm.host-name Name of this ESX-host vCenter
vm.os-fullname Name of guest OS vCenter
vm.vapp-name Name of the associated vCenter
vApp
vm.cluster-name Name of the cluster vCenter
vm.portprofile-name Name of the port-profile Port-profile
 ASAv and VSG 3 Tier Server Zone

Web client

NAT pool
ASAv Policy: ASAv Policy: Block
Allow only any external web
tcp/80 to Web access to DB servers
Zone

Web Zone Database Application

Tenant 1

Tenant 1
VM 1 VM 3 VM 1 VM 3 VM 1 VM 3
VM 2 VM 4 VM 2 VM 4 VM 2 VM 4

VSG: Only permit Web Zone VSG: Permit App Zone to

to access DB Zone access Web Zone but not DB
Using Identity and SG ACLs
All entries still require IP information (could be any)
Identity for source only; SG Tags and Names can be source or destination
Names must resolve to tags, groups to users, user to IP addresses

From HR_ADMIN To any

group on 10.1.1.1 destination

access-list IN permit ip security-group name HR_ADMIN host 10.1.1.1 any

access-list IN permit ip user ABCD\John any security-group tag 22 any

From AD user To any IP

ABCD/John with tag 22
anywhere
Syslogs show Users, Tags and Names when possible
%ASA-6-302013: Built outbound TCP connection 16 for outside:198.51.100.100/22
(198.51.100.100/22)(ABCD\Mary, 111:MKTG) to inside:10.0.0.2/20898 (10.0.0.2/20898)(1212)