firewall architectures -...
TRANSCRIPT
Your Speaker
Mason Harris CCIE #5916
Solutions Architect
15 years at Cisco
10th Year as a Cisco Live Speaker
@mason_harris
Cisco ASA Sessions: Building Blocks
BRKSEC-2020
Firewall Deployment
(Mon 10:00)
BRKSEC-2021
Firewall Architectures
(Wed 08:00)
BRKSEC-3032
ASA Clustering Deep Dive
(Th 10:00)
BRKSEC-3021
Maximizing Firewall Performance
(Tue 08:00)
BRKSEC-2028
Deploying NG Firewall
(Mon 08:00)
(Th 13:00)
• Introduction
• Deployment Modes
• Routing on the ASA
• Firewall Virtualization
• ASA High Availability
• Advanced ASA Deployments
• Summary
Agenda
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, we’ll 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 don’t 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 can’t 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)
10.1.1.0 /24 – vlan 10
10.1.1.0 /24 – vlan 20
BVI 1: 10.1.1.100 /24
(Bridge Virtual Interface)
firewall transparent
hostname ciscoasa
!
interface GigabitEthernet0/0
vlan 20
nameif outside
security-level 0
bridge-group 1
!
interface GigabitEthernet0/1
vlan 10
nameif inside
security-level 100
bridge-group 1
!
interface BVI1
ip address 10.1.1.100 255.255.255.0
Transparent Mode Configuration (2 interfaces)
Samesubnet
on both!
Brid
ge
-gro
up
1
Firewall - Routed Mode
10.1.1.1 - inside
10.99.1.1 - outside
10.99.1.0 /24
10.1.1.0 /24
hostname ciscoasa
!
interface GigabitEthernet0/0
nameif outside
security-level 0
ip address 10.99.1.1 /24
!
interface GigabitEthernet0/1
nameif inside
security-level 100
ip address 10.1.1.1 /24
!
• Routed mode has a routing table, ASA operates at L3
• 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
route outside 0 0 10.1.1.1
route outside 0 0 10.1.1.2
route outside 0 0 10.1.1.3
• Traffic is load-shared on outside interface across three gateways using a hash of source and destination addresses
• Not supported across different interfaces
10.1.1.1 10.1.1.310.1.1.2
outside
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 interfaces in a zone; up to 256 zones maximum
• All interfaces must have same security level
• Seamless connection switchover to another egress interface in the same zone on failure but…NAT/PAT sessions will need to be re-established
• Helpful with assymetric routing and load-balancing deployments, Not supported for VPN, BTF, management or failover
outside1 outside2
inside 1 inside 2
Zone-In
Zone-Out
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 are………um…..static
• ASA has had a tracking feature for many years to ensure that a next hop is up
• Does NOT load-balance; uses an active-standby model
route outside 0 0 10.1.1.1 1 track 1
route backup 0 0 10.2.2.1 254
sla monitor 23
type echo protocol ipIcmpEcho 192.168.1.100interface outside
sla monitor schedule 23 life forever start-time now
track 1 rtr 23 reachability
GW-A - Primary
outside
10.1.1.1 10.2.2.1
192.168.1.100
GW-B - Backup
New 9.4+ Feature – Policy Based Routing (PBR)
• PBR effectively overrides the default behavior of the ASA routing table
• Similar in function to IOS feature; uses ACL for matching in a route-map
• Only supported in routed mode on ASA, also supported in ASA Clustering
• Supports QoS and next hop manipulation
• No match criteria implies a match “any”
• Traffic not matching line 10 or 20 is dropped by Null0 interface
route-map TEST permit 10
match ip address <acl>
set ip next-hop 10.1.1.1
route-map TEST permit 20
match ip address <acl>
set ip next-hop 10.2.2.1
route-map TEST permit 30
set interface Null0
TRANSPARENT MODE:Architecture and Deployment
ASA L2 FW: ASA between Hosts and Gateway
• 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
Vlan 10
(Trusted/Inside)
vlan 20 VIP: 10.1.1.254
Local
Gateway
Hosts: 10.1.1.1-99
10.1.1.x /24
Vlan 20
(Untrusted/Outside)
ASA BVI: 10.1.1.100
ASA L2 FW: Intra VDC Insertion
• 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
FW Outside FW Inside
Server GW
Single L2 Domain
Virtual Hosts
vlan 10vlan 20
10.199.199.210.199.199.1
Optional L3 path for FW bypassNexus 7K VDC
Nexus 7K VDC
N7k1-VDC-2Aggregation
vrf1 vrf2
ASA L2 FW: Inter VDC Insertion
• Transparent (L2) firewall services are “sandwiched” between Nexus Virtual Device Contexts (VDC)
• Allows for other services (IPS, LB, etc) to be layered in as needed
• ASAs can be virtualized to for 1x1 mapping to VRFs
• Useful for topologies that require a FW between aggregation and core
• Firewalls could be L2 or L3
N7k1-VDC-1Core
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)
ISP-A
ISP-B
L3 Routed
Core Fully
Meshed BGP
Layer 3 point-to-point links
Routed core with fully meshed BGP
Transparent ASA
placement provides ACL
and stateful inspection
without disturbing existing
Layer 3 services
Internal
Network
ISP A
ISP B
Case Study: Transparent Firewall Logical View
Internal
Network
ISP A
ISP B
VLAN trunks “loop”
traffic through the
transparent firewalls
Failover control
link is a back-to-
back connection
Active/Standby
redundancy with
ASA failover
L3 Switch/Router
L3 Switch/Router
L3 Switch/Router
L3 Switch/Router
Active ASA
Standby ASA
Case Study: Transparent Firewall Traffic Flow
Inside VLAN 100
Outside VLAN 101
Outside
VLAN 101
192.168.0.3/29
Outside
VLAN 101
Internal
VLAN 200
192.168.0.4/29
1. Outbound
connection comes
in through inside
VLAN to SVI 100
192.168.0.1/29
192.168.0.2/29
SVI 100
SVI 100
2. Routing points to
192.168.0.3 as next hop,
passed through the
transparent ASA trunk
3. Connection passes
back through the switch at
Layer 2 toward the next
routed hop on outside
FIREWALL VIRTUALIZATION:
Multiple Context Mode and ASAv
• 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
• 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+
ASA Multi Context Mode
Internet
PCI Vendor Corp
Single Physical
ASA Chassis
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‘
System Context:
Physical ports assigned
Configuring a Multiple Context ASA
• Context = a virtual firewall
• All virtualized firewalls must define a System context and an Admin context
• There is no policy inheritance between contexts
• The system space uses the Admin context for network connectivity
Admin Context:
Remote root access and
access to all contexts
Virtual Firewall
contexts
VFW
1
VFW
2
VFW
3
Admi
n
System
Multi Context Mode - Common Deployment
• 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
VLAN 10 VLAN 20 VLAN 30 VLAN 40
VLAN 11 VLAN 21 VLAN 31 VLAN 41
VFW
1
VFW
2VFW
3VFW
4
Single Physical ASA
ASA Multiple Context Mode – Segmentation
• One physical ASA
• Contexts could represent different tenants or VRF networks
• Contexts can be “stacked”
• Network devices can exist inside of protected enclave/zone/swim lane
• Creates separation via contexts
Security Services
Enclave/Zone/Swim Lane
ASA Multiple Context Mode Configurationinterface Ethernet0/0
!
interface Ethernet0/0.1
vlan 10
!
interface Ethernet0/0.2
vlan 20
!
interface Ethernet0/1
!
interface Ethernet0/1.1
vlan 11
!
interface Ethernet0/1.2
vlan 21
!
interface Ethernet0/2
!
interface Ethernet0/3
!
class default
limit-resource All 0
limit-resource ASDM 5
limit-resource SSH 5
admin-context admin
context admin
allocate-interface Ethernet0/2 outside
allocate-interface Ethernet0/3 inside
config-url disk0:/admin.cfg
!
context vfw1
allocate-interface Ethernet0/0.1 outside-vfw1
allocate-interface Ethernet0/1.1 inside-vfw1
config-url disk0:/context1.cfg
!
context vfw2
allocate-interface Ethernet0/0.2 outside-vfw2
allocate-interface Ethernet0/1.2 inside-vfw2
config-url disk0:/context2.cfg
ASA Multi Context Mode Configuration (Cont’d)
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
• Can’t virtualize CPU or memory, careful with network surges
• Can’t easily share interfaces in transparent (L2) mode
• Operationally more complex, management tools treat each context like a separate firewall
• Licensed feature $$$
• Some ASA features aren’t compatible with virtualization
• Can’t easily “reboot” a context
What are North-South and East-West Flows?
• North-South (N-S) flows are typically flows to and from Access layer to Aggregation Layer and Core
• East-West (E-W) flows typically stay either within a zone or between zones and often server to server traffic
Web App
Access
Aggregation
Core
Database
East - West
No
rth
-S
ou
th
VirtualHosts
VirtualHosts
VirtualHosts
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
Cisco’s 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
Virtual Security Gateway ASA 1000V
ASA 1000V End-of-Sale
March 2015
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
• One or more VSGs are deployed per tenant
• Requires Nexus 1000V dVS
Virtual Hosts
Virtual Hosts
Virtual Hosts
VSG Deployment Guide: http://www.cisco.com/en/US/prod/collateral/modules/ps2706/ps11208/deployment_guide_c07-647435.html
ASA Evolution
Physical ASA
ASA 5500 and 5500-X family
ASA 1000V
Unique ASA Codebase
ASAv
Same codebase as Physical ASA
Clustering and Multiple Contexts
No L2 mode
No RA VPN
No Routing Protocols
Limited Features
2005 - Present 2012 2015
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 (can’t virtualize a vm)
3. Etherchannel interfaces
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 Firewall
(Virtualized ASA)
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
support
No DHCP support
S2S and RA VPN No IPSEC support
Managed via CLI, ASDM,
CSM
Managed by VNMC only
Full ASA code, CLI, SSH,
REST API
Minimal config via CLI, SSH
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
• No link aggregation, only L1 redundancy
• 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 interfaces can be configured
interface redundant 1
member-interface tengigabitethernet 0/6
member-interface tengigabitethernet 0/7
nameif inside
ip address 10.1.1.2 255.255.255.0
Red line is active link
Black line is standby link
Interface Redundancy: Port Channels
• Best practice: Utilize Link Aggregation Control Protocol (LACP) where possible
• LACP dynamically adds and removes (if necessary) links to the port channel bundle
• Up to 8 active links in ASA 8.4+ and 16 active links in 9.2(1)+
• Link aggregation benefit
• Best practice in Nexus DC is to use Virtual Port Channels (vPC)
• Best practice: use LACP where possible
interface TenGigabitEthernet0/8
channel-group 40 mode active
no nameif
no security-level
!
interface TenGigabitEthernet0/9
channel-group 40 mode active
no nameif
no security-level
!
interface Port-channel40
nameif inside
ip add 10.1.1.2 255.255.255.0
Actively negotiate LACP with switch
‘Show port-channel summary' on ASAFlags: 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 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
ASA
Port Channel Options and Summary
VPC PEER LINK
No Port Channel:
STP Allows only one active link
Sub-optimal flows and resource
usage
Single-Chassis LACP Port
Channel:
Both links active but no device
redundancy (single switch)
vPC Multi-Chassis LACP Port
Channel:
Both links active, optimal redundancy,
all links active
Slide courtesy of Mike Storm
FAILOVER AND CLUSTERING
ASA Active/Standby Failover
• A pair of identical ASA devices can be configured in Failover
• Data interface connections must be mirrored between the units with L2 adjacency
• IP and MAC addresses on data interfaces move with the 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
Active
Firewall
(Primary)
Standby
Firewall
(Secondary)
HA
Interconnects
Two Types of ASA Failover
• Active/Standby Failover
• Single- or multiple-context mode
• Device-level switchover on failure
• One unit is always “idling”
• Simple design for single tenant
• Active/Active Failover
• Requires multiple-context mode
• Switchover based on context groups
• Both units are passing traffic
• Design caveats exist
Secondary
ASA
OutsideInside
Primary
Secondary
Inside B
Outside A
Inside A
Outside B
Primary
Secondary
A
A
B
B
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
• 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
• Ensure that CCL switches do not verify L4 checksums
• TCP and ICMP checksums for redirected packets look “invalid” on CCL
• Enable Spanning Tree Portfast and align MTU on the switch side
VPC
ASA Cluster
CCL CCL
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 1ASA Cluster VPC 2inside
192.168.1.0/24
outside
172.16.125.0/24
.1
Te0/6
Te0/7
Te0/6
Te0/7
Te0/8
Te0/9
Te0/8
Te0/9
.1
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)+
VPC ASA Clusterinside
192.168.1.0/24
outside
172.16.125.0/24
.2
Te0/6
Te0/7
Te0/6
Te0/7
Te0/8
Te0/9
Te0/8
Te0/9
.2
.3.3
.1
.1
Master
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 convergenceasa/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 Verificationasa(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
• OSPF v2/v3 and EIGRP
• BGP as of ASA 9.2+
• Both eBGP and iBGP, up to 500 peers
• Supported on ASAv
• Supported in Multi Context Mode
• Up to 100K routes
• BGP support with clustering (9.3)+
OSPF v2,v3
EIGRP
BGP
• ASA can act as a multi homed edge router and support VPN services concurrently
• VPN support could be for S2S IPSEC or Remote Access VPN or both
A/S pair
Should I Deploy ASA Clustering at the Internet Edge?
• ASA 9.1.4+ extends clustering to 5500-X family
• 2 units max
• 9.1.4 added support for 3750-X switch for this reason
• Yes, if you need Active/Active firewalls
• 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)
2 Unit cluster
ASA “Stacked” Clusters and Multi Context Mode
Physical Topology
• ASA clustering and multi context mode allow for 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.
Logical Topology
ASA Clusters and Multi Context Mode – Cont’d
• 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)
Context 1 Context 2 Context X
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
Data
CCL
CCL is fully extended between
DCs at L2 with <10ms of latency
ASA Cluster
CCL
Data
CCL CCL
Transit connections are not
contained to local site with
extended data VLANs
vPC 1 vPC 2
ASA 9.1(4)+
Local VPC/VSS
pairs at each site
Local VPC/VSS
pairs at each site
Data interfaces
connect to local
switch pair onlyData VLANs do not extend
with a split cluster to
localize traffic to site
Site BSite A
Extended Spanned Etherchannel Cluster in Inter DC
Data CCL DataCCL
vPC Peer Link
vPC logical switch pair is
stretched across sites
CCL is fully extended between
DCs at L2 with <10ms of latency
ASA Cluster
All data interfaces bundle into a
single Spanned Etherchannel
Each cluster member can
single- or dual-connect to
the VSS/vPC pair for CCL
and Data
Transit connections are not
contained to the local site
ASA 9.2+
Site BSite A
Split Spanned Etherchannel Cluster in Inter DC
DataCCL
CCL is fully extended between
DCs at L2 with <10ms of latency
ASA Cluster
CCL DataCCL CCL
Data VLANs are not
extended to prevent loopsvPC 1 vPC 2
Local VPC/VSS
pairs at each site
Local VPC/VSS
pairs at each site
Single Spanned
Etherchannel for Data
on cluster sideLocal Data
Etherchannels on
each VPC/VSS
switch pair
Local Data
Etherchannels on
each VPC/VSS
switch pair
ASA 9.2+
Site BSite A
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+
Remotely Triggered Black Holes (RTBH)
RTBH Trigger on ASA Example
PE
ip verify unicast source reachable-via any
interface Null0
no ip unreachables
router bgp 65001
neighbor 192.168.1.1 remote-as 65001
ip route 192.0.2.1 255.255.255.255 Null0
route-map RTBH
set ip next-hop 192.0.2.1
set origin igp
set community no-export
router bgp 65001
neighbor 192.168.100.1 remote-as 65001
redistribute static route-map RTBH
route Null0 10.1.1.1 255.255.255.255
Create a route map to set the
next hop for any matching
advertised routes to the
“blackhole” IP address
Redistribute all static routes using
the route map for blackholing
10.1.1.1
Any traffic recursively routed to the
blackhole IP address will be dropped
“Soft” uRPF ensures that each source
IP address has a valid return route
3. Subsequent packets from
10.1.1.1 are dropped at the
Provider Edge router
Advertise a static route to the
attacker using the route-map
BGP
1. Establish BGP peering
between inside ASA and
perimeter router with RTBH
configuration
2. ASA administrator
identifies 10.1.1.1 as a
malicious host, configures a
block rule
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
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
VxLAN Overview
ASA 9.4 supports one VTEP with multiple tunnels per context
System VLAN limit applies to combined VLAN and VxLAN count
ASA as VxLAN Gateway
VxLAN 10000
VxLAN 10200
VxLAN 10100
VLAN 100
TenGig0/8
One static VTEP peer
(i.e. hypervisor) is
supported on ASA
interface vni1
segment-id 10000
interface vni2
segment-id 10100
interface vni3
segment-id 10200
Multiple VTEP peers
require multicast-
based discovery
A Virtual Network Identifier (VNI) interface on
ASA handles decapsulated VxLAN traffic for
each segment
ASA bridges or routes
between different
network types
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
servers.Extend all VxLAN segments into
the ASA (virtual or physical) for
secure segmentation. Routed
mode scales best.
Routed Mode VxLAN Gateway
ASA and its peers use unicast
and multicast IPv4 UDP to
communicate between “outer”
VTEP interfaces.
10.20.20.101 10.10.10.201
VMs send IPv4/IPv6 packets over
the VxLAN toward “inner” default
gateway VNI on the ASA.
VTEP encapsulates ARP into multicast
to identify the peer for a particular
destination endpoint (MAC address).
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 whole infrastructure to support SGTs
• ASA converts SGTs to IP addresses
• RA VPN users are tagged on ingress
Permit PCI devices to talk to PCI devices regardless of IP address
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
Database
Servers
Middleware
ServersStorage
ASA SGFW
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:
• ASA 9.0 and newer uses a single ACL for all IPv4 and IPv6
• Configuration migration from earlier releases:
• Dual interface ACLs are merged
• Contextual any conversion applies to ACLs only
access-list IN extended permit ip host 10.1.1.1 any4
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
access-list IN extended permit ip any any
Any IPv4
Any IPv6
Any IPv4 or IPv6
Mixed IPv4 and IPv6
(Need NAT)
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
access-group INSIDE_IPV4 in interface inside
access-group INSIDE_IPV6 in interface inside
“Any” depends on
the ACL type
Slide courtesy of Andrew Ossipov
ASA IPv6 Best Practices
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
• ACL to block unknown Router Advertisement (RA)
• 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 through Twitter and you could win $200 of Cisco Press products (@CiscoPress)
• Send a tweet and include
• Your favorite speaker’s Twitter handle CiscoDCSecurity
• Two hashtags: #CLUS #MyFavoriteSpeaker
• You can submit an entry for more than one of your “favorite” speakers
• Don’t forget to follow @CiscoLive and @CiscoPress
• View the official rules at http://bit.ly/CLUSwin
Promote Your Favorite Speaker and You Could be a Winner
Complete Your Online Session Evaluation
Don’t forget: Cisco Live sessions will be available for viewing on-demand after the event at CiscoLive.com/Online
• 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.
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
• 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
• Data interface monitoring requires Standby IP addresses
• Each unit monitors the health of its interfaces and compares with the peer
• Active virtual MAC address is inherited from the physical interface of the primary
failover lan interface FOVER_CONTROL GigabitEthernet0/0
ip address 192.168.1.11 255.255.255.0 standby 192.168.1.12
failover link FOVER_STATE GigabitEthernet0/1
ASAv and VSG Compared
ASAv with 4 vCPU Virtual Security Gateway
Throughput 1-2GB stateful vPath
Max Concurrent
Sessions500,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
vApp
vCenter
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 Zone Database Application
VM 1
VM 2
VM 3
VM 4
VM 1
VM 2
VM 3
VM 4
VM 1
VM 2
VM 3
VM 4
NAT pool
ASAv Policy: Block any external web access to DB servers
ASAv Policy: Allow only tcp/80 to Web Zone
VSG: Only permit Web Zone to access DB Zone
VSG: Permit App Zone to access Web Zone but not DB
Te
na
nt
1
Tenant
1
Web client
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
• Syslogs show Users, Tags and Names when possible
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 HR_ADMIN
group on 10.1.1.1
To any
destination
From AD user
ABCD/John
anywhere
To any IP
with tag 22
%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)