ASA Firewall

CCIE Security Version 4
Advanced Technologies Class

ASA Firewall
Agenda
ASA Feature Overview

ASA Stateful Filtering Overview
Single & Multiple Context Overview
Routed & Transparent Firewall Overview
VPN Termination Overview
Copyright www.INE.com
ASA and CCIE Security v4

CCIE SCv4 Blueprint defines multiple ASA hardware & software
versions
ASA with 8.2.x and 8.4.x
ASA-X with 8.6.x
Why multiple releases?

Lots of feature additions and changes in ASA starting with version 8.3,
e.g. NAT, global ACLs, etc.
Our technical discussion is relevant for 8.2.x, 8.4.x, and 8.6.x

8.4.x and 8.6.x are effectively equivalent
Code 9.x adds further changes outside our scope, e.g. VPNs in
multiple context
ASA Overview
Stateful Firewall Filtering
Supports Application Aware Inspection
VPN Termination
Supports both IKEv1/IKEv2 IPsec and SSL VPNs
Intrusion Prevention System (IPS)

IPS on Advanced Inspection and Prevention (AIP) Security Service
Module (SSM) for ASA5500 models
IPS built-in software module for ASA5500-X models
Content Filtering (URL Filtering, AVC, Virus, Spyware, Spam,etc.)

Content Security and Control (CSC) Security Services Module (SSM)
for ASA5500 models
ASA-CX built-in software module for ASA5500-X models
ASA Security Levels

ASA classifies the level of trust of an interface
by its security-level
Range of 0 100
100 is the most trusted interface

Assigned to interface inside by default
0 is the most untrusted interface

Assigned to all other interfaces by default
ASA interfaces can only pass traffic if both

nameif and security-level are defined
ASA Security Levels

Traffic from higher to lower security level
Permit by default
E.g. Inside to Outside
Traffic from lower to higher security level

Permit if state already exists
Deny if no state by default
E.g. Outside to Inside
Traffic between interfaces of same security

Deny by default
Exception with same-security-traffic permit inter-interface
same-security-traffic permit intra-interface is NOT related to
security-levels, allows traffic hairpining
Security-levels are bypassed by inbound or global ACLs

ASA Stateful Firewall Filtering

Enabled by default for TCP/UDP traffic and cannot be disabled
Track traffic that moves from trusted network to the untrusted
network
E.g. Inside to Outside interface
Create an entry in the state table for the traffic flow

E.g. TCP port 80 HTTP session from client A to server B
Track traffic that tries to enter from the untrusted network to the
trusted network
If an entry exists in the state table, permit it
E.g. the return HTTP flow from server B to client A
If no entry exists in the state table, deny it

E.g. NMAP port scan from the outside network
ASA Traffic Inspection

Modular Policy Framework (MPF) used to control how traffic is
inspected
MPF controls
What traffic is inspected
Basic layer 3 & 4 inspection of TCP, UDP, & ICMP
Application aware inspection of HTTP, SMTP, DNS, SIP, etc.
How traffic is inspected

Connection limits, QoS parameters, etc.
Direction of inspection
E.g. Inside to Outside vs. Inside to DMZ vs. Outside to DMZ, etc.
Access Control Lists (ACLs) are used to exempt or include traffic

into MPF engine
ASA Context Modes

ASA supports two different Context Modes of operation
Single Context Mode
Multiple Context Mode (Virtual Firewalls)
Single Context Mode

Shared configuration for all interfaces, security policies, routing
table, administrators, etc.
Multiple Context Mode

Separate configuration, interfaces, policies per virtual context
Allows for multiple virtual firewalls for managed services or
policy separation
ASA Firewall Modes

ASA supports two different Firewall Modes of operation
Routed Firewall
Transparent Firewall
Routed Firewall
Interfaces are in different subnets and different VLANs
Traffic is routed between interfaces
Implies the need for static or dynamic routing protocols
Transparent firewall
Interfaces are in the same subnet but different VLANs

Traffic is bridged between interfaces
Only one bridge-group can be created between two interfaces before 8.4
Up to 8 bridge-groups with 4 interfaces per bridge-group starting with 8.4
ASA Context Modes & Firewall Modes

Context Modes and Firewall Modes can run in any
combination
Single Context Mode Routed Firewall
Single Context Mode Transparent Firewall
Multiple Context Mode Routed Firewall
Multiple Context Mode Transparent Firewall
Mixed transparent/routed contexts are not

supported in 8.x code
ASA VPN Termination

Supports both IKEv1/IKEv2 IPsec and SSL VPN termination
IPsec with ESP, ESP over UDP and TCP
SSL over TCP (TLS) and UDP (DTLS)
AH not supported
Supports both LAN to LAN and Remote Access VPNs

IPsec LAN to LAN
AKA Site to Site
IPsec Remote Access

AKA Easy VPN Server / Client
SSL Remote Access

Clientless VPN (WebVPN)
Anyconnect SSL VPN Client
Questions?
Agenda
ASA Management Methods
Basic ASA Initialization
ASA Management
ASA supports two methods of management
Command Line Interface (CLI)
Cisco Adaptive Security Device Manager (ASDM)
Both supported in the current CCIE SCv4 Blueprint
CLI Management
Local via Console port
Remote via Telnet or SSH
ASDM Management
Remote via HTTPS
There are certain tasks which can only be completed using the GUI
(SSL VPN Bookmarks, AnyConnect Client Profiles, DAP Policies)

Connect to Console
Clear existing configuration
write erase or clear startup-config
clear configure all
Does not prompt for confirmation
ASA defaults to Single Context Mode Routed

Firewall

Initialize interfaces
Enable interfaces
no shutdown
Choose Trunk or Access Mode

Create subinterface and apply vlan for trunking
Assign security levels

security-level number
Assign interfaces name

nameif name
Assign IP Addressing
ip address ip_address [mask] standby ip_address
Questions?
Agenda
ASA Routing Protocols Overview

ASA Static Routing Examples
ASA Dynamic Routing Examples
ASA Route Tracking Examples
ASA IPv4 Routing

ASA supports IPv4 routing via
Static Routes
RIPv1 / v2 maximum one process
OSPF maximum two processes
EIGRP maximum one process
Per protocol functionalities are not as advanced
as in IOS code
ASA IPv4 Routing

ASA miscellaneous routing features
Multiple Routing Processes
Routing Authentication
Route Filtering
Redistribution
Redistribution Filtering
Equal Cost Multipath
Supported over the same interface only
Route Tracking
Multicast Routing
Reliable Static Routes on ASA

Like IOS, uses two parts
Service Level Agreement (SLA) / Response Time Reporter
(RTR)
Checks reachability with ICMP Echo (PING)
No advanced SLA metrics like in IOS
Enhanced Object Tracking

Object references SLA instance
If SLA instance PING is successful, Object is up
If SLA instance PING fails, Object is down
Static route references Object

Route can only be installed if Object is up
Allows for reliable floating static routes
Questions?
Agenda
ASA Access Control Lists (ACLs)
ASA Object Groups & Objects
Access-Lists (ACLs)
By default ASA allows
Traffic from higher security to lower security
Traffic from lower security to higher security if state already
exists
Not all traffic is actually inspected by default
Access Control Lists (ACLs) allow manual exceptions to

inspected traffic
Inbound ACLs and global ACLs bypass security-level
functionality
There can be one inbound and one outbound ACL per
interface, along with one global
Access-Lists (ACLs)
Order of processing is:
Inbound ACL
Global ACL
Outbound ACL
When global ACL is configured, the implicit deny from the inbound
ACL is automatically removed
When both inbound ACL and global ACLs are used we can say
that:
Rules from both ACLs are merged

First are processed rules from the inbound ACL
Second are processed rules from the global ACL
Only global ACL has the default implicit deny
Access-Lists (ACLs)
Like in IOS, ASA ACLs match traffic based on
Source IP Address
Destination IP Address
IP Protocol Number
TCP & UDP Ports
ICMP Type Codes
Time Range
Like in IOS, ACLs always end in implicit deny

Access-Lists (ACLs)
Like in IOS, ASA ACLs can be
Standard
Matches only on source IP addresses
Extended
Matches on any combination of src, dst, port, etc.
Unlike in IOS, ASA ACLs

Use the same naming convention for standard and
extended
Cannot mix both in the same list
Use subnet masks instead of wildcard masks

Object Groups
Object Groups simplify ACL management by
grouping similar objects together
E.g. PUBLIC_WEB_SERVERS grouping
Allows for more modular changes

Change to Object Group affects all ACEs that
reference the group
Object Groups
Four types of Object Groups
Protocol
E.g. TCP, UDP, ESP, GRE, etc.
Network
IP address, subnet address, etc.
Service
TCP & UDP port numbers
ICMP type
Echo, Echo-Reply, Unreachable, etc.
ACL Example Without Object Groups

access-list
access-list
access-list
access-list
access-list
access-list
access-list
access-list
access-list
access-list
access-list
access-list
1
1
1
1
1
1
1
1
1
1
1
1
extended
extended
extended
extended
extended
extended
extended
extended
extended
extended
extended
extended
permit
permit
permit
permit
permit
permit
permit
permit
permit
permit
permit
permit
tcp
tcp
tcp
tcp
tcp
tcp
tcp
tcp
tcp
tcp
tcp
tcp
host
host
host
host
host
host
host
host
host
host
host
host
200.0.0.1
200.0.0.1
200.0.0.1
200.0.0.1
200.0.0.1
200.0.0.1
200.0.0.2
200.0.0.2
200.0.0.2
200.0.0.2
200.0.0.2
200.0.0.2
host
host
host
host
host
host
host
host
host
host
host
host
10.0.0.100
10.0.0.100
10.0.0.100
10.0.0.101
10.0.0.101
10.0.0.101
10.0.0.100
10.0.0.100
10.0.0.100
10.0.0.101
10.0.0.101
10.0.0.101
eq
eq
eq
eq
eq
eq
eq
eq
eq
eq
eq
eq
www
https
smtp
www
https
smtp
www
https
smtp
www
https
smtp
ACL Example With Object Groups

object-group network OUTSIDE_TRUSTED_HOSTS
network-object host 200.0.0.1
object-group network PUBLIC_INSIDE_SERVERS
object-group service PUBLIC_INSIDE_SERVER_PORTS tcp
port-object eq www
port-object eq https
port-object eq smtp
!
access-list 2 extended permit tcp object-group
OUTSIDE_TRUSTED_HOSTS object-group PUBLIC_INSIDE_SERVERS
object-group PUBLIC_INSIDE_SERVER_PORTS
Objects
Added along with NAT changes in 8.3
Different than object-groups
Required for Object-NAT
More on this later
Can contain a single entry/definition

Network
Subnet, range, host
Service
Protocol, TCP/UDP source/destination ports
TCP/UDP ports can only be used in Twice NAT
Object Groups vs. Objects

Object groups can contain one or more entries
E.g. multiple hosts, ports, etc.
Object can contain only one entry

E.g. single host, subnet, port, etc.
Why use both?

Object is called from both ACL and NAT in newer code
Allows NAT and ACL config changes to be synchronized
E.g. web server moves to a new internal address; change the
object and both NAT and ACLs are updated
ACL Example With Objects

object network SOURCE
host 10.10.10.10
object network DESTINATION
subnet 100.100.100.0 255.255.255.0
object service PROTOCOL
service ip
!
access-list ACL permit object PROTOCOL object SOURCE object
DESTINATION
ACLs in the CCIE Lab Exam

In the lab exam ACL requirements may not be explicit
E.g. if RADIUS server is on the inside and a host
authenticating to it is on the outside you must manually
allow this on the ASA
Draw out network flows to visualize what needs to be

allowed
E.g. AAA, NTP, BGP, GRE, ESP, ISAKMP, etc.
Logging can be helpful to see what is dropped

Explicit deny ip any any log at end of ACL
Questions?
Agenda
ASA High Availability Overview
Redundant Interfaces
Failover
ASA High Availability

Link High Availability
Dynamic routing
Generic solution relying on infrastructure redundancy
Reliable static routing

Tracking next-hop reachability
Binding multiple physical interfaces
Node High Availability

Failover
Groups multiple physical interfaces into one
logical interface
interface Redundant [num]
member-interface [physical-interface]
Only one interface is active

Not like EtherChannel in Catalyst switching
active-member <physical-interface>
Physical interfaces should only have physical
parameters
Speed, duplex, no shutdown, etc.
Redundant interface has logical parameters

nameif, security-level, ip address, etc.
MAC address taken from first member

MAC could be encoded manually
ASA Failover Overview

ASA supports two types of failover
Active/Standby
Active unit passes traffic
Standby unit waits
Active/Active
Both units forward traffic
Only supported in multiple context mode
Different contexts active in same or different units

Active/Standby supports
Single Context Mode Routed Firewall
Single Context Mode Transparent Firewall
Active/Active supports
Multiple Context Mode Routed Firewall
Multiple Context Mode Transparent Firewall

Standby unit monitors active in two ways
Failover link monitoring
Layer 2 polling through hello packets
Interface monitoring
If hello packets not received, interface testing starts:

Link Up/Down Test
Is there received traffic over the interface?
ARP Requests to hosts from ARP cache
Broadcast PING test

Stateless failover
Connection state table not copied from active to standby
All connections dropped and must be reestablished
Default mode
Stateful failover
Active unit constantly replicates state table
xlates, TCP, UDP, IKE & IPsec SA, ARP, etc.
Requires dedicated stateful failover link or the failover

link can be used
Active/Standby Failover
Uses designated failover interface
Requires a dedicated physical LAN link
Standby polls the active firewall
Configuration replicated from active to standby
State tables not replicated by default
Upon failover
Units change roles
Standby unit assumes IPs and MACs of primary
Failover can be forced or detected

Active/Standby Primary Configuration
Configure primary/secondary unit addressing

ip address <active_addr> <netmask> standby <standby_addr>
ipv6 address <active_addr>/<netmask> standby <standby_addr>
Designate primary unit

failover lan unit primary
Designate failover interface

failover lan interface
Configure failover interface IP addressing

failover interface ip [ifname] [active_addr] [netmask] standby
standby_addr
Enable failover
failover
Active/Standby Secondary Config

Designate secondary unit
failover lan unit secondary
Designate failover interface
failover lan interface
Configure failover interface IP addressing

failover interface ip [ifname] [active_addr]
[netmask] standby standby_addr
Enable failover
failover
Ensure configuration has been replicated from primary

Health Monitoring
Failover polling detects unit failure
Timeout via failover polltime
Interface fault detected via interface polling
Enabled by default for all interfaces but not for sub-interfaces

Interface needs an IP address for monitoring
Define interfaces with [no] monitor-interface
Timeout via failover polltime interface
Interface monitoring policy

failover interface-policy {N|%}
Failover if this many interfaces have failed (1 by default)
Stateful Failover
Configured separately from LAN failover
Uses stateful failover link for replication
Could be shared with LAN failover link
Normally recommended to be separate
State information may generate excessive amount of
traffic
Configured using single command

failover link
Active/Active Failover
One unit is active for a group of contexts
Another unit is active for a different group of
contexts
Uses the concept of failover groups
Defined in system context
There are only 2 failover groups, it makes no
sense to have more
Admin context is always member of failover
group 1, and its non-configurable
HA Commands
failover exec [active|mate|standby]
<command>
E.g. failover exec mate show version
show failover exec [active|mate|standby]

to identity the peer current configuration mode
show
show
show
show
failover
failover history
failover group only in A/A mode
monitor-interface only in A/A mode
Questions?
Agenda
Multiple Context Mode Overview

System, Admin, and User Contexts
Interface Sharing
Classification Rules
Context Resources
Routing in Multiple Context Mode
ASA Context Modes

ASA supports two different Context Modes of operation
Single Context Mode
Multiple Context Mode (Virtual Firewalls)
Single Context Mode

Shared configuration for all interfaces, security policies, routing
table, administrators, etc.
Multiple Context Mode

Separate configuration, interfaces, policies per virtual context
Allows for multiple virtual firewalls for managed services or
policy separation

Separates ASA into multiple virtual firewalls
Each context is assigned
Interfaces
Physical or 802.1Q Subinterfaces
Resource limits
Number of connections, hosts, xlates, etc.
Firewall policy
MPF Inspections, ACLs, NAT, etc.

When in multi-context mode ASA supports
Routed Firewall
Transparent Firewall
Active/Active Failover
Primary forwards for one context
Secondary forwards for other context

When in multi-context mode ASA does not
support
VPN termination
Dynamic routing protocols
QoS features

Three types of contexts
System Context
Admin Context
User Defined Contexts
System Context
Used to create new contexts and define context
parameters
Interface to context assignments
Resource allocation
Configuration file location
Allows changing between contexts for

management
changeto context [name]
Initially only accessible via the console

Admin Context
Used for remote access to system context
Only context that remotely supports changeto system
command
Automatically created when multiple context mode enabled

Uses configuration file admin.cfg by default
Like other contexts, has no resources allocated by default

For management access you must
Allocate an interface
Assign nameif, security level, and IP address
Enable Telnet, SSH, or ASDM access
User Defined Contexts

Used for logical separation of traffic flows
Created under system context by
Specifying context name

Allocating interfaces
Allocating resources
Allocating configuration file
All additional configuration occurs in the user context mode

changeto context [name] from system or admin context
Management connections to user defined contexts can only access

themselves
changeto command not available
Context Interface Allocation

Contexts can have interfaces allocated three ways
Unique physical interfaces per context
Unique subinterfaces per context
Shared interfaces between contexts
E.g. shared outside interface
Physical interface parameters defined in system context

E.g. speed, duplex, no shutdown
Logical interface parameters defined in admin/user context

E.g. nameif, security-level, ip address, etc.
Shared interfaces must conform to classifier rules

Context Classification Rules

ASA must be able to associate inbound traffic
with the correct context
Three possible ways classify traffic
Unique physical interfaces or subinterfaces
Unique MAC address per-context for shared
interfaces
Unique NAT translations per-context for shared
interfaces

Unique physical interfaces or subinterfaces
Separates traffic at physical or link access layer
(e.g. VLANs)
Best practice in most cases, but may consume
public IPs

Unique MAC address per-context for shared
interfaces
Shared interfaces use the same MAC address by
default
Make addresses unique with
mac-address auto command in system context
Interface level mac-address in user contexts

Unique NAT translations per-context for
shared interfaces
Static or Dynamic NAT/PAT
Allows for overlapping inside addresses between
contexts
Outside address must still be unique per context
Identity NAT
Inside and outside addresses must be unique per
context
Context Resources
Resources can be limited on a per context basis
Connections
Translations (xlates)
MAC Addresses
Management sessions
Critical if you have licensing limitations

Resources defined by class in system context
limit-resource [ASDM | All | Conns | ...]
Assign resource class in context subconfiguration mode

member [class]
Context Routing
Only static routes supported
Even for connected prefixes in other contexts
Contexts may be cascaded

Default route from one context points to inside
interface of another context
This allows for context architectures, e.g. shared
firewall
Multiple Context Configuration

Enable Multiple Context Mode
ASA(config)# mode multiple
Requires reboot and configuration erase
Define contexts
ASA(config)# context ABC
Assign interfaces to context

ASA(config-ctx)# allocate-interface
Specify configuration file storage

ASA(config-ctx)# config-url
Complete configuration in user context mode

ASA# changeto context ABC
ASA/ABC#
Questions?
Agenda
ASA Transparent Firewall
ASA Firewall Modes

Routed Firewall
Interfaces are in different subnets and different
VLANs
Traffic is layer 3 routed between interfaces based on
routing table
Transparent firewall
Interfaces are in the same subnet but different VLANs
Traffic is layer 2 bridged between interfaces based on
CAM table

Limitations
VPNs not supported for transit traffic
Supports local management via site-to-site IKEv1/IKEv2 IPsec
tunnel
Only static routing supported

E.g. default route
Multicast IP routing
Multicast traffic can be allowed through ACL
QoS not supported

DHCP Relay Agent not supported, but DHCP Server is
Inspection engine works as in routed mode

Before 8.4
After 8.4
Maximum two interfaces/vlans used for bridging traffic

One additional interface/vlan used for failover
Mgmt interface can be dedicated for management
Global IPv4 address required for IPv4 traffic to be bridged, optionally configure the mgmt
interface with IPv4 address
Interfaces can be paired into bridge-groups
No direct traffic allowed between bridge-groups, similar to multi-context mode
Maximum 8 bridge-groups supported with maximum 4 interfaces per bridge-group
Mgmt interface can be dedicated for management
Each bridge-group requires an IPv4 address to bridge IPv4 traffic, optionally configure the
mgmt interface with IPv4 address
Starting with 8.2 IPv6 traffic supported in transparent mode

Link-Local IPv6 address is good enough for IPv6 traffic bridging

Traffic forwarding policy differs from Routed Firewall
Inside to Outside
High security to low security level
Permit ARP
Permit Broadcasts
Permit Inspected Unicast
TCP, UDP, default inspection class
Most control plane protocols denied

OSPF, EIGRP, PIM, CDP, VTP, etc.
Use ACL deny logging if youre not sure

Outside to Inside
Lower security to higher security
Permit return of inspected traffic
Most control plane protocols are not inspected
Deny all others
ACL exceptions may be needed for Inside to Outside

as well as Outside to Inside
Ethertype ACLs needed to permit non-IP packets
Ethertype ACLs are not stateful
ARP and BPDU are allowed by default
Transparent Firewall Configuration 8.2
Enable Transparent Firewall
Enable Interfaces
[no] firewall transparent

no shutdown
Assign interface names

nameif [name]
Assign interface security levels

security-level [num]
Assign default global management IP

Configure optional management interface
interface mgmt0/0
nameif [name]
management-only
Transparent Firewall Configuration 8.4
Enable Transparent Firewall
Enable Interfaces
[no] firewall transparent

no shutdown
Assign names
nameif [name]
Assign security levels

security-level [num]
Assign interface to a bridge-group

Bridge-group [num]
Configure bridge-group IP address

Interface BVI [num]
Configure optional management
interface mgmt0/0
management-only
nameif [name]
Transparent Firewall and NAT

NAT is supported in Transparent Firewall mode
as of 8.0(2)
NAT Caveats
Inside and Outside are on the same IP subnet
Translation to pool not on the subnet is supported, but
routing must be taken into account
Interface PAT not supported because there is no
interface IP address
ARP inspection not supported
Questions?
Agenda
ASA Transparent Firewall & ARP Filtering
Transparent Firewall and ARP Spoofing

Transparent Firewall forwards all ARP by default
Network attack can occur by host impersonating
anothers MAC address
I.e. ARP Spoofing
ARP inspection allows static ARP to be checked

as ARP transits
If static match and wrong address, drop
If no static match, drop or forward
Transparent Firewall and ARP Spoofing

Configuration
arp inside 1.2.3.4 1234.5678.9abc
arp-inspection inside enable [flood |
no-flood]
Transparent Firewall and MAC Learning
In transparent mode ASA learns MAC addresses

like a normal transparent bridge
MAC learning can be disabled and replaced with
static entries
Prevents unauthorized hosts on the segment
Configuration
mac-address-table static
mac-learn [inside|outside] disable
Questions?
Agenda
Active/Standby Transparent Failover
Active/Active Transparent Failover

ASA Firewall

Caricato da

Informazioni sul documento

Copyright

Formati disponibili

Condividi questo documento

Condividi o incorpora il documento

Opzioni di condivisione

Hai trovato utile questo documento?

Questo contenuto è inappropriato?

Copyright:

Formati disponibili

ASA Firewall

Caricato da

Copyright:

Formati disponibili

CCIE Security Version 4

Advanced Technologies Class

ASA Feature Overview

ASA and CCIE Security v4

Why multiple releases?

Our technical discussion is relevant for 8.2.x, 8.4.x, and 8.6.x

Intrusion Prevention System (IPS)

Content Filtering (URL Filtering, AVC, Virus, Spyware, Spam,etc.)

ASA Security Levels

100 is the most trusted interface

0 is the most untrusted interface

ASA interfaces can only pass traffic if both

ASA Security Levels

Traffic from lower to higher security level

Traffic between interfaces of same security

Security-levels are bypassed by inbound or global ACLs

ASA Stateful Firewall Filtering

Create an entry in the state table for the traffic flow

If no entry exists in the state table, deny it

ASA Traffic Inspection

How traffic is inspected

Access Control Lists (ACLs) are used to exempt or include traffic

ASA Context Modes

Single Context Mode

Multiple Context Mode

ASA Firewall Modes

Interfaces are in the same subnet but different VLANs

ASA Context Modes & Firewall Modes

Mixed transparent/routed contexts are not

ASA VPN Termination

Supports both LAN to LAN and Remote Access VPNs

IPsec Remote Access

SSL Remote Access

Basic ASA Initialization

ASA defaults to Single Context Mode Routed

Basic ASA Initialization

Choose Trunk or Access Mode

Assign security levels

Assign interfaces name

ASA Routing Protocols Overview

ASA IPv4 Routing

ASA IPv4 Routing

Reliable Static Routes on ASA

Enhanced Object Tracking

Static route references Object

Access Control Lists (ACLs) allow manual exceptions to

Rules from both ACLs are merged

Like in IOS, ACLs always end in implicit deny

Unlike in IOS, ASA ACLs

Use subnet masks instead of wildcard masks

Allows for more modular changes

ACL Example Without Object Groups

ACL Example With Object Groups

Can contain a single entry/definition

Object Groups vs. Objects

Object can contain only one entry

Why use both?

ACL Example With Objects

ACLs in the CCIE Lab Exam

Draw out network flows to visualize what needs to be

Logging can be helpful to see what is dropped

ASA High Availability

Reliable static routing

Node High Availability