Firewall Manual

ASA SECURITY FIREWALL
Copyright Commsupport Networks Ltd Page 2

Copyright 2007-2014 Commsupport Networks Ltd. All rights reserved.
The following publication, FIREWALL Lab Workbook series, was developed by Commsupport
Networks Ltd. All rights reserved. No part of this publication may be reproduced or distributed in any
form or by any means without prior written permission from Commsupport Networks Ltd
Cisco, Cisco Systems, the Cisco logo, and CCIE are registered trademarks of Cisco Systems, Inc.
and/or its affiliates in the United States and certain other countries. All other products and company
names mentioned in this workbook are the trademarks, registered trademarks, or service marks of
their respective owners.
Disclaimer
The following publication: FIREWALL Lab Workbook series is designed to assist students in their
preparation for the Cisco Systems FIREWALL Exam.
The enclosed material is presented to you on an as is basis. Every effort has been taken to ensure
that all material contained in this workbook is complete and accurate. The authors and
Commsupport Networks assume no liability or responsibility to any person or entity with respect to
loss or damages incurred by using theinformation contained in this workbook.
This workbook was developed by Commsupport Networks Ltd and is an original work of the
aforementioned authors.
Any similarities between material presented in this guide and actual FIREWALL Exam or other
material is completely coincidental.
CONTENTS
Lab Lab Name Page
1 Initial Setup 7
2 NAT and ACLs 8.2 61
3 NAT and ACLs 8.4 103
4 Handling Traffic 159
5 Transparent Firewall 195
6 Multiple Context 231
7 Failover 257
This ASA FIREWALL Lab Manual is Version 2 and is currently under development
Version 3 release is due Late December 2014 and will include the following topics
1. Routing using
a. EIGRP
b. OSPF
c. RIP
2. Qos
a. Traffic Shaping
b. Traffic Policing
c. Prioritisation
3. IP SLA
4. Threat Detection
5. Tuning Failover
6. Transparent Firewall Proxy Next hop labs
R1
Fa0/1 Fa0/0
Fa0/1
Fa0/2
Fa0/3
Fa0/6
R2
Fa0/1 Fa0/0
R3
Fa0/1 Fa0/0
Eth0/1
Eth0/0
Fa0/1
Fa0/2
Fa0/3
Fa0/7
SW1
SW2
Fa0/8
Fa0/9
Eth0/1
Eth0/0
ASA1
ASA2
Equipment Used in these labs
2 X ASA 5510 8.2 and 8.4 with Security Plus License.
Routers 1, 2, 3 = 1841 12.4 64Mb RAM 128Mb Flash -IOS Advanced Security 12.4
Routers 4, 5 = 2801 12.4 64Mb RAM 128Mb Flash IOS Advanced Security 12.4
Switches SW1 and SW2 3550 EMI
SECTION 1: INITIAL SETUP
Lab 1 : Initial Setup Topology Diagram
R1
Border_X Inside
FastEthernet 0/0
192.168.2.1/24
Border_X Outside
Fastethernet 0/1
192.168.1.1x /24
ASA Outside
Eth0/0
192.168.2.2 /24
ASA Inside
Eth0/1
10.0.0.1 /24
Corporate Server
IP: 10.0.0.10 /24
Default GW: 10.0.0.1
Internet Server
192.168.1.2x /24
Default Gateway:
192.168.1.1X
Ip route 0.0.0.0 0.0.0.0 192.168.1.254
ASA
Border_X
R2
192.168.1.254 /24
Towards Internet or
192.168.1.10
SW2
All ports in Vlan 1
All ports are Access
F0/0
Fa0/2
Fa0/10
VLAN 1
Fa0/7
Fa0/2
SW1
VLAN 27
Fa0/6
Fa0/1
VLAN 16
Eth 2-3
Fa 12-13
SW1
Part 1: Initial configuration and device management
Configure SW1 and SW2
Step 1: Configure Switch SW1
SW1# erase startup-config
SW1# reload
SW1# conf t
switch(config)# hostname SW1
SW1(config)# int range fa0/1 - 24
SW1(config-if-range)# shut
SW1(config-if-range)# exit
Step 2: Configure the Connection between R1 and the inside interface of the ASA
SW1(config)# int fa0/1
SW1(config-if)# no shut
SW1(config-if)# switchport access vlan 16
SW1(config-if)# spanning-tree portfast
SW1(config-if)# exit
Step 3: Configure the Connection between R2 and the outside interface of the ASA
SW1(config)# int fas 0/2
SW1(config-if)# int fas 0/7
Step 4: Unshut Interface Fa0/12 and Fa0/13, these will be used later in the lab for etherchannel and
interface redundancy.
SW1(config)# int range fas 0/12 - 13
SW1(config-if-range)# no shut
SW2# reload
switch# conf t
Step 6: Configure the Connection between R2 and the outside world, Fa0/10 leads to the internet.
Step 7: Configure R1
R_ONE# erase startup-config
R_ONE# reload
router(config)# hostname R1
R1(config)# int fa0/0
R1(config-if)# ip address dhcp
R1(config-if)# exit
R1(config)# no ip routing
Task 1:
In this initial part you will familiarise yourself with the general commands. Please make sure that you
pay close attention to the commands and the questions asked, make notes and ask question, if
there is some concept you do not understand please ask the instructor.
Step 1: Erase any existing configuration from the ASA
The first part of this lab requires that you clear all configuration from the ASA in your lab.
Clearing the configuration before starting on new labs is always a good idea, rather than
having to over write an existing configuration.
Follow the steps for the ASA in your lab:
NOTE: z represents the router number, x represents your lab number
asa>
asa>enable
Password:
asa#write erase
Erase configuration in flash memory? [confirm]
[OK]
asa#reload
[OK]
Proceed with reload? [confirm]
***
*** --- START GRACEFUL SHUTDOWN ---
Shutting down File system
***
*** --- SHUTDOWN NOW ---
Process shutdown finished
Step 2: When the ASA finally boots you will be presented with an output that resembles the one
below.
Pre-configure Firewall now through interactive prompts [yes]?no
Step 3: The ASA default hostname is ciscoasa. Like a Cisco router or Cisco switch the default
prompt you are placed into by default is the user mode, and like on a Cisco Router or Switch to go
from the User mode to the privilidged exec mode enter the command enable and press Enter,
when the password prompt appears press Enter once again and the ASA will present the privileged
exec mode.
Type help or ? for a list of available commands.
ciscoasa>enable
Password:
ciscoasa#
Step 4: To display the contents of the running configuration file use the command show run
ciscoasa# show run
: Saved
:
ASA Version 8.4(3)
!
hostname ciscoasa
enable password 8Ry2YjIyt7RRXU24 encrypted
passwd 2KFQnbNIdI.2KYOU encrypted
names
!
interface Ethernet0/0
shutdown
At this point please type in no, if the prompt has
proceeded past this point then use the key
sequence control+z to come out of the setup
prompt
At this point please press enter
Interfaces are all shutdown
no nameif
no security-level
no ip address
!
shutdown
no nameif
no security-level
no ip address
!
shutdown
no nameif
no security-level
no ip address
!
shutdown
no nameif
no security-level
no ip address
!
interface Management0/0
shutdown
no nameif
no security-level
no ip address
!
boot system disk0:/asa843-k8.bin
ftp mode passive
pager lines 24
mtu inside 1500
no failover
icmp unreachable rate-limit 1 burst-size 1
asdm image disk0:/asdm-649.bin
no asdm history enable
arp timeout 14400
timeout xlate 3:00:00
timeout pat-xlate 0:00:30
timeout conn 1:00:00 half-closed 0:10:00 udp 0:02:00 icmp 0:00:02
timeout sunrpc 0:10:00 h323 0:05:00 h225 1:00:00 mgcp 0:05:00 mgcp-pat 0:05:00
timeout sip 0:30:00 sip_media 0:02:00 sip-invite 0:03:00 sip-disconnect 0:02:00
timeout sip-provisional-media 0:02:00 uauth 0:05:00 absolute
timeout tcp-proxy-reassembly 0:01:00
timeout floating-conn 0:00:00
dynamic-access-policy-record DfltAccessPolicy
Management Interface is shutdown
Interfaces are without names
Interfaces are without security levels
Interfaces are without ip addresses
user-identity default-domain LOCAL
http server enable
http 192.168.1.0 255.255.255.0 inside
no snmp-server location
no snmp-server contact
snmp-server enable traps snmp authentication linkup linkdown coldstart
telnet timeout 5
ssh timeout 5
console timeout 0
threat-detection basic-threat
threat-detection statistics access-list
no threat-detection statistics tcp-intercept
webvpn
!
class-map inspection_default
match default-inspection-traffic
!
!
policy-map type inspect dns preset_dns_map
parameters
message-length maximum 512
policy-map global_policy
class inspection_default
inspect dns preset_dns_map
inspect ftp
inspect h323 h225
inspect h323 ras
inspect netbios
inspect rsh
inspect rtsp
inspect skinny
inspect esmtp
inspect sqlnet
inspect sunrpc
inspect tftp
inspect sip
inspect xdmcp
inspect ip-options
!
service-policy global_policy global
prompt hostname context
no call-home reporting anonymous
call-home
profile CiscoTAC-1
no active
destination address http https://tools.cisco.com/its/service/oddce/services/DDCEService
destination address email callhome@cisco.com
destination transport-method http
subscribe-to-alert-group diagnostic
subscribe-to-alert-group environment
subscribe-to-alert-group inventory periodic monthly
subscribe-to-alert-group configuration periodic monthly
subscribe-to-alert-group telemetry periodic daily
Cryptochecksum:0f4e6f1f0d4682c723cb99f6b1833d71
: end
ciscoasa#
Step 5: When you start working with the ASA devices it is always advisable to verify which features
are enabled on the device, non-default features on the ASA require the appropriate licence to
activate them. To display the features and the license type used by the ASA use the command
show version
ciscoasa# show version
Cisco Adaptive Security Appliance Software Version 8.4(3)
Device Manager Version 6.4(9)
Compiled on Fri 06-Jan-12 10:24 by builders
System image file is "disk0:/asa843-k8.bin"
Config file at boot was "startup-config"
ciscoasa up 15 mins 27 secs
Hardware: ASA5510, 256 MB RAM, CPU Pentium 4 Celeron 1600 MHz
Internal ATA Compact Flash, 128MB
BIOS Flash M50FW080 @ 0xffe00000, 1024KB
Encryption hardware device : Cisco ASA-55x0 on-board accelerator (revision 0x0)
Boot microcode : CN1000-MC-BOOT-2.00
SSL/IKE microcode: CNLite-MC-SSLm-PLUS-2.03
IPSec microcode : CNlite-MC-IPSECm-MAIN-2.04
0: Ext: Ethernet0/0 : address is 0022.9008.f262, irq 9
4: Ext: Management0/0 : address is 0022.9008.f261, irq 11
5: Int: Not used : irq 11
Licensed features for this platform:
Maximum Physical Interfaces : Unlimited
Maximum VLANs : 100
Inside Hosts : Unlimited
Failover : Active/Active
VPN-DES : Enabled
VPN-3DES-AES : Enabled
Security Contexts : 2
GTP/GPRS : Disabled
SSL VPN Peers : 2
Total VPN Peers : 250
Shared License : Disabled
Current image being used
Amount of Flash memory
Features available on this particular ASA
AnyConnect for Mobile : Disabled
AnyConnect for Linksys phone : Disabled
AnyConnect Essentials : Disabled
Advanced Endpoint Assessment : Disabled
UC Phone Proxy Sessions : 2
Total UC Proxy Sessions : 2
Botnet Traffic Filter : Disabled
This platform has an ASA 5510 Security Plus license.
Serial Number: JMX44444444
Running Activation Key: 0xffffffff 0xffffffff 0xffffffff 0xffffffff 0xffffffff
Configuration register is 0x1
Configuration has not been modified since last system restart.
This particular ASA has the following:
1. ASA image: asa843-k8.bin
2. Cisco ASDM image: 6.4(9)
3. ASA Model 5510
4. Supports 100 vlans
5. This ASA supports Active/Active failover
6. VPN-DES is Enabled
7. VPN-3DES-AES is enabled
License on this particular ASA
Activation Key
Task 2: Understanding the Factory Default Configuration
When an ASA boots for the first time or it has been defaulted it will startup up running a factory
default configuration.
When the ASA is factory defaulted it will:
1. Set aside one interface as a protected management network, so you can connect to it via
IP,A DHCP server pool is enabled on the management network, to provide an IP address for
the PC.
2. The HTTP server is enabled on the management network, to allow the PC to access secure
web based ASDM sessions with the ASA via HTTPS over TCP port 443.
3. The management interface IP address is configured as 192.168.1.1/24. The HTTP server is
will allow ASDM sessions from devices on the 192.168.1.0/24 management network.
4. On ASA 5510 and higher platforms always uses the Management0/0 physical interface for
the management network, The ASA 5505, does not have a management interface, it uses
VLAN 1 for the secure inside network, which is assigned to physical interfaces Ethernet0/1
through 0/7.
The ASA 5505 default configuration provides basic connectivity from its inside network to the
outside world.
One the 5505 the outside network is connected to physical interface Ethernet0/0, this interface is a
member of VLAN 2.
Should you wish to set the ASA back to factory default you can do so by entering the configure
factory-default command in configuration mode. This command will take effect straight away,
therefore if you are connected to the device via Telnet/SSH/ASDM your connection will be lost.
Step 1: Enter the command to set the ASA to factory default. Observe the default commands being
inserted
ciscoasa(config)# configure factory-default
Based on the management IP address and mask, the DHCP address
pool size is reduced to 253 from the platform limit 256
WARNING: The boot system configuration will be cleared.
The first image found in disk0:/ will be used to boot the
system on the next reload.
Verify there is a valid image on disk0:/ or the system will not boot.
Begin to apply factory-default configuration:
Clear all configuration
Executing command: interface management0/0
Executing command: nameif management
INFO: Security level for "management" set to 0 by default.
Executing command: ip address 192.168.1.1 255.255.255.0
Executing command: security-level 100
Executing command: no shutdown
Executing command: exit
Executing command: http server enable
Executing command: http 192.168.1.0 255.255.255.0 management
Executing command: dhcpd address 192.168.1.2-192.168.1.254 management
Executing command: dhcpd enable management
Executing command: logging asdm informational
Factory-default configuration is completed
Step 2: View the configuration on the ASA, do you see the configuration that was entered by the
previous step?
ciscoasa(config)# show run
Step 3: This next step you will clear all of the configuration that was inserted by the factory default
command by using the clear configure all command
ciscoasa(config)# clear configure all
WARNING: DHCPD bindings cleared on interface management, address pool removed
The Following commands are for reference only
clear configure all: Clears the entire running configuration
clear configure primary: Clears all commands related to connectivity, including the ip address,
mtu, monitor-interface, boot, route, failover, tftp-server, and shun commands
clear configure secondary: Clears all commands not related to ASA connectivity
clear configure command: Clears all commands that use the command keyword
Task 3: Performing a Reload THIS IS FOR REFERENCE ONLY
You can force an ASA to reload immediately. The ASA will see if the running configuration has been
saved; otherwise it will prompt you to save the configuration before reloading.
Once you have saved the configuration the ASA will then ask if you want to proceed with the
reload, press any key other than Enter. When the reload process begins, the ASA performs a
shutdown of all of its subsystems and processes.
To schedule a reload, you use the following command syntax:
ciscoasa# reload in {mm | hhh:mm}
The time interval can be given in minutes or hours and minutes from the time the reload command
is entered.
Once you schedule a reload, you can check the schedule and status with the show reload
command.
To cancel a scheduled reload enter the reload cancel command.
You can add any of the following keywords and options after any form of the reload command:
max-hold-time {mm | hhh:mm}: The ASA will wait a maximum elapsed time for the subsystems
and processes to be shut down gracefully, and then it will perform a quick reload without
waiting.
reason string: Records your reason in the ASA logs to indicate why the reload was requested; the
reason text will be shown to users on active SSH, Telnet, console, ASDM and VPN
sessions, session users so that they are aware of the impending reload.
noconfirm: Performs the reload with no confirmation request.
quick: Performs the reload without waiting for graceful shut down of processes
save-config: The ASA saves the running configuration before the reload
Task 4: Configuring Interface Redundancy
Each physical interface on the ASA operates independently of any other interfaces.
You can configure physical interfaces on the ASA as redundant pairs. The redundant pair of
interfaces are for the same function (inside, outside, dmz), and would connect to the same network.
Unlike in Etherchannel where the interfaces are all live and forwarding traffic but in a redundant pair
only one of the interfaces in the pair is live and passing traffic the other one stays in a standby state.
When the active interface goes down, the standby interface becomes active and takes over passing
traffic.
To configure the redundant pair you have to configure two physical interfaces as members of a
single logical redundant interface. The two interfaces must be the same type for example
10/100/1000 etc.
The redundant logical interface is configured with a unique interface name, security level, and IP
address.
Step 1: Create the redundant interface by entering the following configuration command, in this step
create Redundant interface 1
ciscoasa(config)# interface redundant 1
NOTE: Up to eight redundant interfaces on the ASA. The interface number can be 1 through 8
Step 2: Add a physical interface as a member of the redundant interface:
ciscoasa(config-if)# member-interface ethernet 0/2
INFO: security-level and IP address are cleared on Ethernet0/2.
ciscoasa(config-if)# member-interface ethernet 0/3
Note: Be aware that the member interface cannot have a security level or an IP address configured.
In fact, as soon as you enter the member-interface command, the ASA will automatically clear
those parameters from the physical interface configuration.
Step 3: Eth0/2 and Eth0/3 are both connected to SW1 interface Fa0/12 and 13, unshut both the
interfaces on the ASA and run the following command to view which interface is active.
ciscoasa# int eth0/2
(config-if)# no shut
(config-if)# int eth0/3
(config-if)# no shut
(config-if)# exit
ciscoasa# sho int redundant 1
Interface Redundant1 "", is up, line protocol is up
=========output omitted for brevity========
MAC address 001c.5826.3ad6, MTU not set
Redundancy Information:
Member Ethernet0/2(Active), Ethernet0/3
Last switchover at 16:27:09 UTC Jul 23 2012
The order in which you configure the interfaces is important. The first physical interface added to a
logical redundant interface will be assigned and set as the active interface.
An active interface will stay active until it loses its link status, at which point the standby interface
will take over. The standby interface wil also take over when the active interface is administratively
shut down.
When the previous active interface comes back on-line the active status will not revert to that
interface. The active status is traded back and forth only when the current active fails.
Step 4: The logical redundant interface takes the MAC address of the first member interface that
you configure. From that point regardless of which physical interface is active, the same MAC
address is used.
Although this being a Cisco devices you can manually configure a unique MAC address on the
redundant interface with the mac-address mac_address interface configuration command.
ciscoasa# conf t
ciscoasa(config)# inter redundant 1
ciscoasa(config-if)# mac-address 0001.2323.2323
ciscoasa(config-if)# end
ciscoasa# sho run inter redundant 1
interface Redundant1
member-interface Ethernet0/2
member-interface Ethernet0/3
mac-address 0001.2323.2323
Step 5: The redundant interface is configured as a normal physical interface. The only command
that need to be configured the two physical interfaces are the port speed and duplex.
ciscoasa(config)# inter redundant 1
ciscoasa(config-if)# ip address 10.1.1.1 255.255.255.0
ciscoasa(config-if)# security-level 100
ciscoasa(config-if)# nameif inside
Step 6: And view the output to verify the setup
Step 7: Clean up the configuration
Task 5: Etherchannel
In the previous lab task with redundant interface, two physical interfaces were bound into one
logical interface, but, only one of the two links could pass data at any given time.
With ASA software release 8.4(1), you can bundle between 2 and 8 physical interfaces as a single
logical port-channel interface using an EtherChannel
NOTE: Each interface must be of the same type, speed, and duplex mode before an EtherChannel
can be built.
An ASA can support up to eight active interfaces in a single EtherChannel, you can configure up to
16 different interfaces per EtherChannel, although only eight of them can be active at any time. If
one active interface fails, another one automatically takes its place.
Step 1: To configure the EtherChannel, the ASA and the switch must both be configured. You
options in how you configure the ASA interfaces for instance you can chose the interfaces to
statically participate, where the EtherChannel is always on. With this configuration the switch
interfaces must too be configured for always on operation, or you can configure the ASA and
switch to negotiate an EtherChannel with each other.
In this step you will configure eth0/2 and 0/3 to be in an LACP etherchannel
ciscoasa(config)# int eth0/2
ciscoasa(config-if)# channel-group 1 mode active
ciscoasa(config-if)# exit
ciscoasa(config-if)# channel-group 1 mode active
Step 4: Configure the Port-Channel interface with nameif / ip address / security level and unshut the
member interfaces
ciscoasa(config)# inter port-channel 1
INFO: Security level for "inside" set to 100 by default.
ciscoasa(config)# inter eth0/2
ciscoasa(config-if)# no shut
ciscoasa(config-if)# inter eth0/3
ciscoasa(config-if)# end
Step 5: Eth0/2 and Eth0/3 are connected to port 12 and 13 on SW1.
SW1(config)# int range fastEthernet 0/12 - 13
SW1(config-if-range)# channel-group 1 mode active
Creating a port-channel interface Port-channel 1
Step 5: Verify the configuration so far on the ASA, note the (P) next to the Port numbers, these
denotes a Bundled port
Step 6: The ASA and the switch use a system priority (a 2-byte priority value followed by a 6-byte
switch MAC address) to determine which of the two devices is allowed to make the decision about
which interfaces are actively participating in the EtherChannel.
ciscoasa(config)# lacp system-priority 4096
ciscoasa(config)# exit
ciscoasa# show lacp sys-id
4096 ,001c.5826.3ad4
Step 7: Interfaces are selected and become active according to their port priority value (a 2-byte
priority followed by a 2-byte port number), where a low value indicates a higher priority. A set of up
to 16 potential links can be defined for each EtherChannel.
ciscoasa(config)# int ethernet 0/2
ciscoasa(config-if)# lacp port-priority 4096
ciscoasa(config)# int ethernet 0/3
ciscoasa(config-if)# lacp port-priority 8192
Step 8: And verify the port configuration
Step 9: Clear the configuration from the ASA
Step 10: Default Fas0/12 and Fa0/13 on SW1.
SW1(config)# default int range fastEthernet 0/12 13
Task 6: Configuring Vlan Interfaces
An interface on the ASA can be configured as multiple sub-interfaces to connect to multiple logical
networks just like a router-on-a-stick configuration. The interface is configured to operate like a trunk
link.
Note: On an ASA 5505, each VLAN is defined by a unique VLAN interface and can connect to
physical interfaces and be carried over a VLAN trunk link.
Step 1: Configure Eth0/2 with Subninterfaces to be a trunk link to carry vlan 10, 20, 30
ciscoasa(config)# inter eth0/2
ciscoasa(config)# int eth0/2.10
ciscoasa(config-subif)# vlan 10
ciscoasa(config-subif)# exit
Step 2: Verify the configuration. Check that all the subinterfaces are up.
Note: Although a Cisco switch can be configured to negotiate the trunk status or encapsulation
through the Dynamic Trunking Protocol (DTP) the ASA cannot
Task 8: Initialise the security appliance
Step 1: In this next task you will configure the ASA with the correct IP addresses and prepare the
ASA to accept connections to the ASDM.
Start by going to the Ethernet 0/1 interface and setting the name on the interface, the name will be
inside, when the ASA sees this particular name being applied to an interface it will automatically
assign the interface the highest security level of 100. Even so you will enter the security level of the
interface manually. Apply the IP address of 10.0.0.1/24 to the eth0/0 interface and then bring it live.
Note: The ASA can obtains an IP address for the interface via DHCP, you can release and renew
the DHCP lease by re-entering the ip address dhcp command.
ciscoasa> enable
Password:
ciscoasa# conf t
ciscoasa(config)# interface e0/1
Step 2: Interface security levels SHOULD be unique so that the ASA can apply security policies
across security-level boundaries. This is because of the two following inherent policies that an ASA
uses to forward traffic between its interfaces:
A. Traffic is allowed to flow from a higher-security interface to a lower-security interface (inside to
outside, for example), provided that any access list, stateful inspection, and address translation
requirements are met.
B. Traffic from a lower-security interface to a higher one cannot pass unless additional explicit
inspection and filtering checks are passed.
ciscoasa(config-if)#exit
It is possible to use the following command in global configuration mode so that you can reuse
security level numbers and relax the security level constraint between interfaces using the
command below:
ciscoasa(config)# same-security-traffic permit inter-interface
If you have a requirement were traffic must enter and exit through the same interface, traversing the
same security level for example when the ASA is configured to support multiple logical VPN
connections terminating on the same ASA interface then you can use the following command:
ciscoasa(config)# same-security-traffic permit intra-interface
The traffic will enter the ASA interface and comes out of one VPN connection, only to enter a
another VPN connection and back out of the same interface. In effect, the VPN traffic follows a
hairpin turn on a single interface.
Note: Hairpinning is a term you will hear often in networking
Step 3: The ASA uses the Secure Sockets Layer (SSL) protocol to communicate with a client. The
ASA acts as web server to process the requests from the clients and therefore you must enable the
web server on the ASA with the http server enable command.
The ASA will also discard all incoming packets to the web server until the management clients IP
address is in the trusted network.
ciscoasa(config)# http server enable
ciscoasa(config)# http 192.168.1.0 255.255.255.0 outside
ciscoasa(config)# wri mem
Enable HTTP
Trust connections to the HTTP server from
this network & this interface. All zeros
means trust any connection from any
source on the outside.
Step 4: Configure are Default route on the ASA pointing to the next hop of 192.168.2.1 which is R2
inside interface.
ciscoasa(config)# route outside 0.0.0.0 0.0.0.0 192.168.2.1
Task 9: Configure DHCP services
Step 1: In this task you will configure DHCP services to lease addresses to the corporate clients on
the inside network. The command line does not allow the entry of a default gateway in the same
way as a cisco router would instead we will use the dhcpd option 3 ip command. Once the range,
gateway and dns server have been applied the service must be started on the inside interface.
ciscoasa(config)# dhcpd address 10.0.0.10-10.0.0.100 inside
ciscoasa(config)# dhcpd option 3 ip 10.0.0.1
ciscoasa(config)# dhcpd dns 8.8.8.8
ciscoasa(config)# dhcpd enable inside
Step 2: Go to R1, (Corporate Server) and Bounce the F0/0 interface R1 ought to have acquired its
ip addresses from the ASA
The address pool specifies the start
and end range to be used on the inside
Task 10: Configure the Border Router (R2)
The Border router has two fastethernet interfaces:
Fa0/0 connects to the ASA eth0/0
Fa0/1 connects to the internet (Or if not available to an external Server on the outside
of your network hosting web and File server services)
Configuring IP addresses on Fastethernet interfaces
Step 1: Erase any existing configuration from all of the routers
The first part of this lab requires that you clear all configuration from all three of the routers in
your lab.
Clearing configurations before starting on new labs is always a good idea, rather than having
to over write an existing configuration.
Follow the steps below for all three routers in your lab:
Rz_x>enable
Rz_x#erase startup-config
Rz_x#reload
Step 2: When the routers finally boot you will be presented with an output that resembles the one
below.
--- System Configuration Dialog ---
Would you like to enter the initial configuration dialog? [yes/no]:no
Assigning correct IP addressing to the Border Router
Step 1: Enter a host name on the Border_x router (Refer to the network diagram on the first page),
in this step you will also enter the command that stops console messages from interrupting your
input and the command that prevents typos from causing DNS name resolutions.
Router(config)#hostname Border_x
Border_x(config)#no ip domain-lookup
Border_x(config)#line con 0
Border_x(config-line)#logging synchronous
Border_x(config-line)#exit
Step 2: Enter the correct interface modes and set the correct address on Border_x Fastethernet
0/0.
Now go through the steps to enter the correct ip address on Border_x Fastethernet 0/1 interface,
this interface is the one which you will connect to the outside world. Ask your instructor which cable
to use to connect to the outside interface
Border_x(config)# interface Fastthernet 0/1
Border_x(config)# description LINK_TO_OUTSIDE_WORLD
Border_x(config-if)# ip address 192.168.1.1X 255.255.255.0
Border_x(config-if)# no shut
Border_x(config-if)# end
Border_x# copy run start
Step 3: Enter the correct interface modes and set the correct address on Border_x Fastethernet 0/0
this interface is the one which you will connect to the ASAs outside eth0/0 interface
The hostname you give this router is
Border_x , The x is your lab number
X is your Lab Number, if in doubt ask your instructor
Border_x(config)# description LINK_TO_ASA
Border_x(config-if)# ip address 192.168.2.1 255.255.255.0
NAT/PAT using the address of the interface
You are required to perform configurations to enable internet access.
You need to configure Border_x with NAT, you need to configure the appropriate NAT interfaces;
NAT inside and NAT outside respectively
Step 1: Configure the access control list that NAT will use to make it matching decisions based on
traffic coming from the inside network of the ASA, the DMZ (To be configured) and traffic from the
ASA
Border_x# config t
Border_x (config)# access-list 100 permit ip 192.168.2.0 0.0.0.255 any
Border_x (config)# access-list 100 permit ip 192.168.1.0 0.0.0.255 192.168.2.0 0.0.0.255
Border_x(config)# access-list 100 permit ip 10.0.0.0 0.0.0.255 any
Border_x(config)# access-list 100 deny ip any any
Step 2: Configure NAT so that it can translate the inside addresses defined by the access list above
to an address already associated to an interface and enable PAT
Below you will tell ip nat that the inside source is defined by the access list numbered 1 and to
translate these inside addresses to the address on the interface and overload i.e PAT.
Border_x(config)# ip nat source list 100 interface fastethernet 0/1 overload
Step 3: NAT must now be instructed as to which interfaces are facing the outside world in this lab
the outside is the fastthernet 0/1
Border_x(config)# interface fastethernet 0/1
Border_x(config-if)# ip nat enable
Border_x(config-if)# exit
Step 4: NAT must now be instructed as to which interfaces are facing inside in this lab the inside
is the fastethernet 0/0, but in this lab you will be allowing traffic from the outside to come in to the
inside part of the network so you will use the ip nat enable command
Step 5: The router now needs a series of static default routes to instruct it to forward traffic to the
correct next hops
1. Towards the internet we need a static default route
Border_x(config)# ip route 0.0.0.0 0.0.0.0 192.168.1.254
2. Towards the inside network of 10.0.0.0 we will need a static route
The fastethernet 0/0 interface in
this lab is the outside interface
On the inside interface use the
enable command
Step 6: Now test the configuration. From the router you will need ping the following addresses:
Ping 1: Ping an outside machine, ask the instructor for this address, otherwise use the address
8.8.8.8 which is a Google DNS server, if you get a reply your internet connection is up
Ping 2: This time ping the Google DNS server from the ASA of the inside Corporate laptop and then
check the translations on the border router.
Border_x# sho ip nat nvi translations
Task 11: Launch the Cisco ASDM
In this task you will launch the Cisco ADSM
Step 1: Verify that you have Java 1.4.2, 1.5.0 pr 1.6.0 loaded on the computer
Step 2: Verify that encryption is enabled on the ASA
Config file at boot was "startup-config"
ciscoasa up 15 mins 27 secs
Hardware: ASA5510, 256 MB RAM, CPU Pentium 4 Celeron 1600 MHz
Internal ATA Compact Flash, 128MB
BIOS Flash M50FW080 @ 0xffe00000, 1024KB
Encryption hardware device : Cisco ASA-55x0 on-board accelerator (revision 0x0)
Boot microcode : CN1000-MC-BOOT-2.00
SSL/IKE microcode: CNLite-MC-SSLm-PLUS-2.03
IPSec microcode : CNlite-MC-IPSECm-MAIN-2.04
4: Ext: Management0/0 : address is 0022.9008.f261, irq 11
Licensed features for this platform:
Maximum Physical Interfaces : Unlimited
Maximum VLANs : 100
Inside Hosts : Unlimited
Failover : Active/Active
VPN-DES : Enabled
VPN-3DES-AES : Enabled
Encryption is enabled
Amount of Flash memory
GTP/GPRS : Disabled
SSL VPN Peers : 2
Total VPN Peers : 250
Shared License : Disabled
AnyConnect for Mobile : Disabled
AnyConnect for Linksys phone : Disabled
AnyConnect Essentials : Disabled
Advanced Endpoint Assessment : Disabled
UC Phone Proxy Sessions : 2
Total UC Proxy Sessions : 2
Botnet Traffic Filter : Disabled
This platform has an ASA 5510 Security Plus license.
Serial Number: JMX44444444
Running Activation Key: 0xffffffff 0xffffffff 0xffffffff 0xffffffff 0xffffffff
Configuration register is 0x1
Configuration has not been modified since last system restart.
Step 3: Verify that the time and date on the ASA match the time and date on the Corporate Server
ciscoasa# clock set 20:35:00 20 July 2012
ciscoasa# show clock
20:35:02.469 UTC Tue July 2 2012
The clock on the ASA defaults to UTC time. Make sure that the time zone match on the ASA and
the device manager P.C, if the time zones do not match the certificate may not be valid
Step 4: Check the version of ASDM running on the ASA
Device manager version
Step 5: Open Internet explorer on the desktop on the device manager P.C (Internet Machine) and
delete the cookies by completing the following substeps.
1. From the browser toolbar, choose Tools > Internet Options, the internet option window
opens
2. Click Delete Cookies, the delete cookie window opens
3. Click OK
4. In the internet options window, click OK
Step 6: Access the Cisco ADSM console by completing the following substeps
1. In the url field of the browser window, enter the following https://192.168.2.2
2. A security alert will appear, click View Certificate, the certificate window appears.
3. Click Install Certificate. The Certificate Import Window pop-up window opens
4. Click Next. The Certificate Import Wizard > Certificate Store Panel is displayed.
5. Click Next. The Certificate Import Wizard > Completing the Certificate Import Wizard panel is
displayed
6. Click finish. The Root Certificate Store pop-up window opens, if a Security warning window
is displayed, click Yes
7. Click Yes, The Certificate Import Wizard window pops open.
8. Click OK
9. Click OK in the Certificate window
10. Click Yes in the Security Alert Window, the Cisco ASDM 6.4 window opens
11. Click Run ASDM. The warning Security Screen pop-up window opens
12. Click Yes
13. If another Warning- Security pop-up window is displayed, click Run
14. The Cisco ASDM Launcher login window is displayed
15. If a pop-up window is displayed asking if you would like to create a shortcut on your desktop,
click NO
16. When prompted for a password leave the password field and username blank
17. Click OK. Cisco ASDM should now load and display the home window
Step 7: In the device information area of the Device dashboard, examine the contents of the
general tab, and answer the following questions
Q1: What is the hostname?
A1: ciscoasa
Q2 What is the security appliance version?
A1: Either 8.3 or 8.4
Q3: What is the Device Type?
A3: Cisco 5510
Q4: What is the firewall Mode?
A4: Routed
Q5: What is the context Mode?
A5: Single
Step 8: Examine the configuration of the ASA by clicking the configuration icon and then completing
the following substeps
1. Click on the Configuration button in the menu bar
2. Select Device Setup from the navigation panel
3. Click Interfaces, notice that the inside interface is configured
4. Select Device Name/Password. Notice that the hostname ciscoasa is displayed in the
hostname field
5. Select Device Management from the navigation panel
6. Expand the Management Access menu
7. Select ASDM./HTTPS/TELNET/SSH. Which address is displayed in the list of hosts that are
allowed to access the ASA using ASDM?
Task 12: Configure the ASA with the ASDM
Task 1: Run the Cisco ASDM Startup wizard, this wizard helps you to put the basic config onto the
ASA firewall rather having to do it via the CLI
Complete the following steps
Step 1: In ASDM choose wizards > Startup Wizard from the main menu. The Startup Wizard
opens, displaying the Starting point (Step 1 of ...) page
Step 2: Verify that the Modify Existing Configuration radio Button is selected
Step 3: Click Next. The Basic Configuration (Step 2 of ...) page is displayed
Step 4: Verify that ciscoasa is displayed in the in the ASA hostname field
Step 5: Configure Commsupport.local in the domain name field
ciscoasa(config)# domain-name Commsupport.local
Step 6: Click Next. The Interface Configuration (Step 3 of ...) page is display
Step 7: Complete the following substeps to configure the outside interface
1. Select Ethernet 0/0 from the interface drop down list
2. Enter outside in the interface name field
3. Verify the Use the Following IP Address radio button is selected
4. Enter 192.168.2.2 in the ip address field
5. From the Subnet Mask drop-down menu, choose subnet mask 255.255.255.0
6. Select the Enable interface check box
7. Verify that 0 is displayed in the security Level field.
CLI VERSION
ciscoasa(config)# int eth 0/0
ciscoasa(config-if)# nameif outside
Step 8: Click Next, The other Interfaces Configuration (Step 4 of ...) page is displayed click Next
Step 9: The Static Routes (Step 5 out of 11) page is displayed
Step 10: Click Add. The Add Static Route window opens.
Step 11: Complete the following substeps to configure a default route
1. Select outside from the Interface Name-drop-down list
2. Enter 0.0.0.0/0 in the IP Address Field.
3. Enter 192.168.2.1 in the gateway IP Field
4. Click OK
ciscoasa(config)# route outside 0.0.0.0 0.0.0.0 192.168.2.1 1
Step 12: In the Static Route (Step 5 of 11) page, click Next. The DHCP server page is displayed,
click Next
Step 13: The NAT page is displayed, (Step 7 of 11) select the No Address Translation radio
button, you will not be using NAT at this time
Step 14: Click Next, the Administrative Access (Page 8 of 11) page is displayed, click Next
Step 15: Click Next. The Auto Update Server (Step 9 of 11) page is displayed
CLI VERSION
CLI VERSION
Step 16: Click Next, the Cisco Smart Call Home Enrollment (Page 10 of 11) page is displayed,
select the No not enable smart call home radio button
Step 17: Verify the information on Startup Wizard Summary (Step 11 of 11) page is displayed and
then click finish and send
Task 13: Use the Cisco ASDM to configure logging to a Syslog Server
In this task you will configure syslog output to a syslog server.
Step 1: Verify that the Configuration button is selected in the Cisco ASDM toolbar
Step 2: Click Device Management in the navigation panel
Step 3: Expand the Logging menu
Step 4: Click Logging Setup, The Logging Setup panel is displayed
Step 5: Check the Enable Logging check box
ciscoasa(config)# logging enable
Step 6: Click Apply and send
Step 7: Click Syslog Servers in the logging menu, The Syslog Servers panel is displayed
Step 8: Click Add, The Add Syslog Server window opens
Step 9: Choose Inside from the Interface drop down list
Step 10: Enter 192.168.1.2x, the IP address of the syslog servers in the IP address field. This is the
internet Laptop you are configuring from. (X is your Lab Number)
Step 11: Click OK. You are returned to the Syslog Servers configuration panel.
ciscoasa(config)# logging host inside 192.168.1.2x
CLI VERSION
CLI VERSION
Step 13: Click Logging Filters in the logging menu. The logging Filters panel is displayed
Step 14: Highlight the Syslog Servers in the Logging Destination Column
Step 15: Click Edit on the right hand side of the screen. The Edit logging Filters windows opens
Step 16: In the Syslog from All Events Classes area, click the Filter on Severity radio button
Step 17: Choose Debugging from the Filter on Severity drop-down list
ciscoasa(config)# logging trap Debugging
Step 18: Click OK
Step 20: Click File > Save in the toolbar. The Save Running Configuration to Flash window
opens
Step 21: Click Send
Step 22: Use the CLI to verify your configuration
ciscoasa# show logging
Syslog logging: enabled
Facility: 20
Timestamp logging: disabled
Standby logging: disabled
Debug-trace logging: disabled
Console logging: disabled
Monitor logging: disabled
Buffer logging: disabled
Trap logging: level debugging, facility 20, 117 messages logged
CLI VERSION
Logging to inside 192.168.1.2x errors: 8 dropped: 94
History logging: disabled
Device ID: disabled
Mail logging: disabled
ASDM logging: disabled
Step 23: Open TFTPd32 or kiwisyslog Daemon on your computer
Step 24: From R1 Telnet to the Border Router on 192.168.2.1
Step 25: Observe if any messages appear on the output of the syslog program
Step 26: Stop sending messages to the syslog server
ciscoasa# conf t
ciscoasa(config)# no logging enable
Task 14: Use the CLI to configure System Logging
Step 1: In this first step you will configure the ASA to send informational and higher messages to
192.168.2.2x and that every message must have a time stamp. This is the internet Laptop you are
configuring from. (X is your Lab Number)
ciscoasa(config)# logging enable
ciscoasa(config)# logging timestamp
ciscoasa(config)# logging trap informational
ciscoasa(config)# logging host outside 192.168.2.2x
Step 2: Syslog uses UDP Port 514, it is possible to change to use TCP Port 1470. Use the
following command to do this.
ciscoasa(config)# logging host outside 192.168.2.2x tcp/1470
Note: that the syslog supports secure logging over SSL. To enable this, use the following
command. This command is an example only, do not enter it.
ciscoasa(config)# logging host outside 192.168.2.2x tcp/1470 secure
Step 3: Configure Syslog to store 65536 Bytes of debugging messages in the system memory
buffer.
ciscoasa(config)# logging buffer-size 65536
Step 4: Email logging allows the ASA to send messages to a specific email address. You need to
configure the severity level for the destination and the email settings, for instance the sender,
recipient , SMTP server
ciscoasa(config)# logging mail 0
ciscoasa(config)# logging from-address asa@commsupport.co.uk
ciscoasa(config)# smtp-server 192.168.2.2
ciscoasa(config)# logging recipient-address administrator@commsupport.co.uk level 3
Note: If is possible to configure multiple recipients and to configure different levels severities per
recipient
Task 15: Basic Device Settings
The ASA requires no password to enter privileged EXEC (enable) mode. Because initial access to
the console port necessitates physical access, this is understandable. However, if an ASA is going
to enter production, it is unacceptable to provide access without requiring at least basic
authentication.
1. Telnet access password is set to cisco by default,
2. SSH access (with the username being pix)
Step 1: From the CLI, use the enable password command to set the privileged mode password.
The ASA will automatically convert It to an MD5 hash when storing it.
The keyword encrypted at the end of output line specifies that the password is shown in encrypted
form (actually, an MD5 hash) rather than in plain text. Do not type encrypted when configuring the
enable password, if you where to copy the password into another ASA, you would have to copy the
entire line, including the keyword encrypted, so that the new ASA to understands that this is not a
plain-text password
ciscoasa(config)# enable password cisco level 15 encrypted
Encrypted enable password cisco is of incorrect length
ciscoasa(config)# enable password cisco level 15
Incorrect
Step 2: Logout out of the ASA and then log back into the device using the password of cisco
ciscoasa> en
Password: *****
ciscoasa#
Step 3: Telnet into the ASA from R1 and use the password of cisco, but before you do so enable
telnet sessions to be accepted by the ASA.
ciscoasa(config)# telnet 10.0.0.0 255.255.255.0 inside
Step 4: Before you can enable the SSH server on the ASA, you congigure the ASA with a public-
private pair of RSA keys. You can create the RSA key pair (or even replace an existing pair) by
using the crypto key generate rsa command.
SSH connections always uses the default key-pair type of the general-keys key pair. The default
modulus size is 1024. If you need to replace an existing pair, use the crypto key zeroize rsa
default command to delete the existing pair.
ciscoasa(config)# domain-name commsupport.local
ciscoasa(config)# crypto key zeroize rsa default
WARNING: The default key pair will be removed
WARNING: All device digital certificates issued using these keys will also be removed and
the associated trustpoints may not function correctly.
Do you really want to remove these keys? [yes/no]: yes
ciscoasa(config)# crypto key generate rsa modulus 2048
INFO: The name for the keys will be: <Default-RSA-Key>
Keypair generation process begin. Please wait...
Step 5: Once an RSA key pair has been configured. You should use SSH version 2 because it has
stronger methods of key management and message integrity checking.
ciscoasa(config)# ssh 10.0.0.0 255.255.255.0 inside
ciscoasa(config)# ssh version 2
ciscoasa(config)# username ciscoasa password ciscoasa
ciscoasa(config)# aaa authentication ssh console LOCAL
Step 6: From R1 SSH to the ASA. Open Putty or teraterm and bring up an SSH session with the
ASA, use the following details
Username: ciscoasa
Password: ciscoasa
Enable Password: cisco
Test the SSH and Telnet Connection to the AS 10.0.0.1 from R1
R1# ssh -l ciscoasa -v 2 10.0.0.1
Password: ciscoasa
The I is the letter L not the
number one
Task 16: Configure the Boot System Variable
The ASA can store multiple versions of the operating system software (memory allowing). When the
ASA boots it will check the boot variable to determine which version of the operating system it has
to load. If it is blank then the ASA boots to the first version of the software it finds in flash memory. If
multiple versions of the operating system are in memory you may want to select the version of
software to boot by configuring the boot system variable.
Step 1: Check the boot system variable. If the current boot system variable is blank please proceed
to Step 2.
ciscoasa(config)# show bootvar
BOOT variable =
Current BOOT variable =
CONFIG_FILE variable =
Current CONFIG_FILE variable =
ciscoasa(config)#
Step 2: Determine if a version of the operating system is stored in flash memory. Verify that
asa821-k8.bin and asa843-k8.bin are displayed, if only asa821-k8.bin is displayed call the
instructor.
ciscoasa(config)# dir
Directory of disk0:/
90 -rwx 16275456 21:15:44 Dec 02 2010 asa821-k8.bin
91 -rwx 11348300 14:08:38 Jan 24 2011 asdm60.bin
93 -rwx 1323 17:18:20 Mar 15 2012 admin.cfg
94 -rwx 25196544 13:35:04 Jul 02 2012 asa843-k8.bin
95 -rwx 18927088 13:36:46 Jul 02 2012 asdm-649.bin
Step 3: Set the boot variable to cause the ASA to boot from the asa821-k8.bin image
ciscoasa(config)# boot system disk0:/ asa821-k8.bin
Step 4: Verify that the boot variable was taken
ciscoasa(config)# show bootvar
BOOT variable =
Current BOOT variable = disk0:/asa821-k8.bin
CONFIG_FILE variable =
Current CONFIG_FILE variable =
Step 5: Save your current configuration.
ciscoasa(config)# write memory
Building configuration...
Cryptochecksum: 8c0a6d92 ac55545d 937179fa 5724a8b1
2331 bytes copied in 3.350 secs (777 bytes/sec)
[OK]
Task 17: NTP on the ASA
In this task you will configure the ASA to take its time source from Border_x (R2)
Step 1: Configure NTP on R2
Border_x# conf t
Border_x(config)# ntp authentication-key 1 md5 COMMSUPPORT
Border_x(config)# ntp trusted-key 1
Border_x(config)# end
Step 2: Configure NTP on the ASA
ciscoasa(config)# ntp authentication-key 1 md5 COMMSUPPORT
ciscoasa(config)# ntp authenticate
ciscoasa(config)# ntp server 192.168.2.1 key 1
ciscoasa(config)# ntp trusted-key 1
Step 3: Verify the NTP status on the ASA. It make take a few minutes for the NTP to sync.
ciscoasa# show ntp status
Clock is synchronized, stratum 9, reference is 192.168.2.1
nominal freq is 99.9984 Hz, actual freq is 99.9984 Hz, precision is 2**6
reference time is d60ab7d2.0e193625 (19:24:02.055 UTC Thu Oct 17 2013)
clock offset is 5.3376 msec, root delay is 0.81 msec
root dispersion is 15895.98 msec, peer dispersion is 15890.63 msec
Step 4: Run the following command to view which sessions are authenticated.
ciscoasa# show ntp associations detail
192.168.2.1 configured, authenticated, our_master, sane, valid, stratum 8
ref ID 127.127.7.1, time d60ab893.7ec698ea (19:27:15.495 UTC Thu Oct 17 2013)
our mode client, peer mode server, our poll intvl 64, peer poll intvl 64
root delay 0.00 msec, root disp 0.03, reach 37, sync dist 891.541
delay 0.79 msec, offset 8.4566 msec, dispersion 891.11
precision 2**18, version 3
======================output omitted for Brevity=======================
SECTION 2: NAT 8.2
Lab 2: NAT 8.2 Topology Diagram
R1
Border_X Inside
FastEthernet 0/0
192.168.2.1/24
Border_X Outside
Fastethernet 0/1
192.168.1.1x /24
ASA Outside
Eth0/0
192.168.2.2 /24
ASA Inside
Eth0/1
10.0.0.1 /24
Corporate Server
IP: 10.0.0.10 /24
Internet Server
192.168.1.2x /24
Default Gateway:
192.168.1.1X
Ip route 0.0.0.0 0.0.0.0 192.168.1.254
ASA
Border_X
R2
192.168.1.254 /24
Towards Internet or
192.168.1.10
SW2
All ports in Vlan 1
F0/0
Fa0/2
Fa0/10
VLAN 1
Fa0/7
Fa0/2
SW1
VLAN 27
Fa0/6
Fa0/1
VLAN 16
Part 1: Configure Translations on ASA 8.2
Step 1: OS version 7.0 as earlier is was not possible a PIX firewall to forward packets from a high
security interface to a low security interface (outbound traffic) unless there was a rule configured
for address translation. So if you wanted to pass traffic through the device you had to configure NAT
to match outbound packets against a translation rule (even if such a rule were to exempt a packet
from translation). This use of NAT was enforced. Starting with OS version 7.0 on the PIX and up to
the current ASAs there is no enforcement of NAT, by default.
At the ASA CLI, verify that NAT control is disabled
ciscoasa# sho run nat-control
no nat-control
Step 2: Determine if there are any nat commands configured on the ASA
ciscoasa# show run nat
nat (inside) 0 0.0.0.0 0.0.0.0
Step 3: From the command line on the corporate server (R1), establish a Telnet connection to the
backbone router on 192.168.1.1x
Step 4: View the translation table on the ASA
ciscoasa# show xlate
1 in use, 61 most used
Global 10.0.0.10 Local 10.0.0.10
Step 5: Close the Telnet Connection
Step 6: Clear the translation table on the ASA and verify that there are no translations
ciscoasa# clear xlate
Step 7: Enter the configuration mode on the ASA and remove the NAT statement inserted by the
ADSM from the configuration, then verify that the commands have been removed.
ciscoasa# conf t
ciscoasa(config)# clear config nat
ciscoasa(config)# show run nat
Step 8: From R1, establish a Telnet connection to the backbone router on 192.168.1.1x, you ought
to still be able to establish a Telnet connection to the router without any NAT configured because
NAT control is disabled, the connection will only work if R2 understands how to get back to the
network R1 is residing on is reachable via 192.168.2.2 which is the ASAs outside interface, check
that your R2 has the following route applied
Border_X(config)# ip route 10.0.0.0 255.255.255.0 192.168.2.2
Step 9: Complete the following substeps to enable NAT control on the ASDM
a. Click Configuration in the ASDM
b. Choose Firewall from the navigation panel
c. Choose NAT Rules from the Firewall menu. The NAT rules panel is displayed
d. Uncheck the Enable Traffic Through the Firewall Without Address Translation check box
e. Click Apply
Step 10: From R1 establish a Telnet connection to R2 on 192.168.1.1x, you should NOT be able
to establish a Telnet connection to the router with NAT control configured because when NAT
control is enable all traffic must match a NAT policy.
NOTE: If your traffic is still being permitted clear the xlate table
ciscoasa# clear xlate
Lab 1.1 NAT Exemption
If NAT control is enabled and NAT rules are configured, they are implemented, but traffic that is not
matched according to any of the NAT rules it is dropped.
The following is a list of situations that would require you to exempt certain traffic from NAT on an
ASA that otherwise enforces NAT:
Do not use NAT or PAT with applications that embed IP addresses on the application layer and
use end-to-end encryption. With encrypted traffic, the Cisco ASA cannot translate embedded
addresses and allow such applications to work properly across NAT.
Do not use NAT or PAT with applications that authenticate entire packets (such as IPsec
Authentication Header [AH] or Border Gateway Protocol [BGP]). When a packet hash value is
calculated, and then addresses and/or port numbers are translated later, the verification of the hash
at the other end of the communication will fail, and the packet will be dropped.
Do not use NAT or PAT with applications that establish additional dynamic sessions, and for
which the ASA does not support protocol-specific inspection rules. Also, if the application uses an
encrypted control channel, the ASA will not be able to inspect the packet contents and perform
modifications allowing the application to work properly across NAT/PAT.
R1
Border_X Inside
FastEthernet 0/0
192.168.2.1/24
Border_X Outside
Fastethernet 0/1
192.168.1.1x /24
ASA Outside
Eth0/0
192.168.2.2 /24
ASA Inside
Eth0/1
10.0.0.1 /24
Corporate Server
IP: 10.0.0.10 /24
Internet Server
192.168.1.2x /24
Default Gateway:
192.168.1.1X
ASA
Border_X
R2
192.168.1.254 /24
Towards Internet or
192.168.1.10
SW2
All ports in Vlan 1
F0/0
Fa0/2
Fa0/10
VLAN 1
S 10.0.0.10
D 8.8.8.8
S 10.0.0.10
D 8.8.8.8
ORIGINAL
PACKET SOURCE NOT
TRANSLATED
Step 1: In this lab you are going to configure the ASA to exempt the traffic from 10.0.0.10 (Your
inside Corporate Host) from being NATed when sending traffic to 8.8.8.8.
At this point set up a continuous ping from R1 to 8.8.8.8.
Note: Another term for NAT exemption is NAT Bypass
NAT Exemption allows configured traffic flows to completely bypass the ASAs NAT engine. Clients
and/or servers not requiring translation are thus allowed to communicate without the creation of any
translation slots in the translation table (which reduces device processing overhead).
ciscoasa(config)# access-list NAT_EXP line 1 extended permit ip host 10.0.0.10 host 8.8.8.8
and the nat rule referring to the ACL
ciscoasa(config)# nat (inside) 0 access-list NAT_EXP
Note: You can apply only a single NAT bypass rule to any one interface. As such, all traffic to be
exempted from NAT, when ingressing through a given interface, must be defined as part of the
same ACL.
Step 2: Verify your configuration
ciscoasa# show nat inside
match ip inside host 10.0.0.10 outside host 8.8.8.8
NAT exempt
translate_hits = 8, untranslate_hits = 0
match ip inside host 10.0.0.10 inside host 8.8.8.8
NAT exempt
match ip inside any outside any
no translation group, implicit deny
policy_hits = 1
Step 4: Verify on R2, can you see that the source of the traffic is 10.0.0.10, the traffic has arrived
from the ASA through the NAT control rule and is being translated by the Router.
Router# debug ip nat
IP NAT debugging is on
NAT*: s=10.0.0.10->192.168.1.201, d=8.8.8.8 [5582]
NAT*: s=8.8.8.8, d=192.168.1.201->10.0.0.10 [0]
NAT*: s=10.0.0.10->192.168.1.201, d=8.8.8.8 [5583]
NAT*: s=8.8.8.8, d=192.168.1.201->10.0.0.10 [0]
Router# undebug all
All possible debugging has been turned off
Step 5: End of Lab Clean up on the ASA. When you clear the commands below the pings on the
corporate machine will timeout.
ciscoasa(config)# clear configure access-list NAT_EXP
ciscoasa(config)# clear configure nat
LAB 1.2: Dynamic Inside Policy NAT
R1
Border_X Inside
FastEthernet 0/0
192.168.2.1/24
Border_X Outside
Fastethernet 0/1
192.168.1.1x /24
ASA Outside
Eth0/0
192.168.2.2 /24
ASA Inside
Eth0/1
10.0.0.1 /24
Corporate Server
IP: 10.0.0.10 /24
Internet Server
192.168.1.2x /24
Default Gateway:
192.168.1.1X
ASA
Border_X
R2
192.168.1.254 /24
Towards Internet or
192.168.1.10
SW2
All ports in Vlan 1
F0/0
Fa0/2
Fa0/10
VLAN 1
S 10.0.0.10
D 212.58.246.95
S 10.0.0.10
D 8.8.8.8
ORIGINAL PACKET ONE
Packet ONE SOURCE
TRANSLATED
Packet TWO SOURCE
NOT TRANSLATED
S 10.0.0.10
D 8.8.8.8
ORIGINAL PACKET TWO
S 192.168.2.100
D 212.58.246.95
The ASA supports the ability to specify which specific traffic flows (rather than only which source IP
addresses) will be subject to a translation rule.
You do this by defining a policy using an ACL, wherein flows defined with a permit entry become
eligible for the policy NAT rule you create.
You can combine policy NAT with dynamic inside NAT and create dynamic inside policy NAT rules.
In this case, you will translate the source IP addresses of your local hosts, depending on the
specific definition of traffic flows defined in an ACL.
Scenario:
a. Hosts in the 10.0.0.0/24 inside subnet will ping to 212.58.246.95 with their source IPs
addresses translated
Step 1: Configure the ACL matching the inside traffic going the destination
ciscoasa(config)# access-list POL_NAT extended permit ip 10.0.0.0 255.255.255.0 host
212.58.246.95
Step 2: Configure the inside nat rule matching the ACL from step1
ciscoasa(config)# nat (inside) 1 access-list POL_NAT
Step 3: Tie the rule from Step 2 to the outside side translated address of 192.168.2.100.
192.168.2.100 is the address that traffic from 10.0.0.0/24 will be translated to. The element which
ties the configuration on Step 2 and Step 3 together is the value 1
ciscoasa(config)# global (outside) 1 192.168.2.100 netmask 255.255.255.255
INFO: Global 192.168.2.100 will be Port Address Translated
This value 1 ties this config to Step 2 config
Step 4: Verify the configuration, try pinging something else like 8.8.8.8 or 4.4.4.2, do you get any
translations?
Step 5: Verify the traffic arriving from R1 10.0.0.10, this traffic ought to now be translating to
192.168.2.100
Border_x# debug ip nat
NAT*: s=192.168.2.100->192.168.1.201, d=212.58.246.95 [9812]
NAT*: s=212.58.246.95, d=192.168.1.201->192.168.2.100 [16475]
NAT*: s=192.168.2.100->192.168.1.201, d=212.58.246.95 [9813]
NAT*: s=212.58.246.95, d=192.168.1.201->192.168.2.100 [16476]
NAT*: s=192.168.2.100->192.168.1.201, d=212.58.246.95 [9814]
NAT*: s=212.58.246.95, d=192.168.1.201->192.168.2.100 [16477]all
All possible debugging has been turned off
LAB 1.3: Static Inside Policy PAT
R1
Border_X Inside
FastEthernet 0/0
192.168.2.1/24
ASA Outside
Eth0/0
192.168.2.2 /24
ASA Inside
Eth0/1
10.0.0.1 /24
Corporate Server
IP: 10.0.0.10 /24
ASA
Border_X
R2
Towards Internet or
192.168.1.10
F0/0
S 10.0.0.10
D 192.168.2.1:22
S 192.168.2.50
D 192.168.2.1
ORIGINAL PACKET ONE
Packet ONE SOURCE
TRANSLATED
Packet TWO SOURCE
TRANSLATED
S 10.0.0.10
D 192.168.2.1:23
ORIGINAL PACKET TWO
S 192.168.2.50
D 192.168.2.1
The ASA also supports the ability to specify which specific traffic flows using port numbers (rather
than which source IP addresses) will be subject to a translation rule.
You can combine policy NAT with static inside NAT and create static inside policy NAT rules. In this
case, you will translate the source IP addresses of your local hosts statically, depending on the
specific definition of traffic flows defined in an ACL.
Scenario:
b. Hosts in the 10.0.0.0/24 inside subnet will telnet to 192.168.2.1 with their source IPs
c. Hosts in the 10.0.0.0/24 inside subnet will SSH to 192.168.2.1 with their source IPs
Step 1: Configure SSH on the R2.
Border_x(config)# ip domain-name SSH_HOST
Border_x(config)# crypto key generate rsa general-keys modulus 1024
The name for the keys will be: Border_x.SSH_HOST
% The key modulus size is 1024 bits
% Generating 1024 bit RSA keys, keys will be non-exportable...[OK]
%SSH-5-ENABLED: SSH 1.99 has been enabled
Border_x(config)# line vty 0 807
Border_x(config-line)# transport input telnet ssh
Border_x(config-line)# login local
Border_x(config-line)# exit
Border_x(config)# username cisco password cisco
Step 2: Before you being this, PLEASE test that telnet works from the R1 to 192.168.2.1.
Turn nat control off and now SSH and Telnet from R1
ciscoasa(config)# no nat-control
Step 3: Configure the ACL matching the inside traffic going the destination along with matching the
destination port number
ciscoasa(config)# access-list POL_SNAT extended permit tcp host 10.0.0.10 host
192.168.2.1 eq 23
ciscoasa(config)# access-list POL_SNAT extended permit tcp host 10.0.0.10 host
192.168.2.1 eq 22
Step 4: Configure the inside nat rule matching the ACL from step 3
ciscoasa(config)# nat (inside) 2 access-list POL_SNAT
Step 5: Tie the rule from Step 4 to the outside side translated address, traffic which has matched
the access-list specified in Step 4 will be translated to 192.168.2.50
ciscoasa(config)# global (outside) 2 192.168.2.50 netmask 255.255.255.255
INFO: Global 192.168.2.50 will be Port Address Translated
NOTE: The value which ties Step 4 andStep 5 configurations together is the 2 value
Step 6: Verify the NAT translation on the ASA and the border router, notice that the source of the
traffic is 192.168.2.50 and that the source/destination ports for the traffic are showing as 22 for SSH
Notice this time the traffic is being translated to 192.168.2.50 and not 192.168.2.100 as configured
in Lab 1.2 Dynamic Inside Policy NAT
Border_x(config)# access-list 101 permit tcp any any eq 22
Border_x(config)# end
Border_x# debug ip packet 101 detail
IP: tableid=0, s=192.168.2.50 (FastEthernet0/1), d=192.168.2.1 (FastEthernet0/1), routed
via RIB
IP: s=192.168.2.50 (FastEthernet0/1), d=192.168.2.1 (FastEthernet0/1), len 92, rcvd 3
TCP src=64298, dst=22, seq=353736772, ack=1492301743, win=64440 ACK PSH
IP: tableid=0, s=192.168.2.50 (FastEthernet0/1), d=192.168.2.1 (FastEthernet0/1), routed via
RIB
IP: s=192.168.2.50 (FastEthernet0/1), d=192.168.2.1 (FastEthernet0/1), len 40, rcvd 3
TCP src=64298, dst=22, seq=353736824, ack=1492301847, win=64336 ACK
Border_x# undebug all
Perform the same verification operation for Telnet.
Step 7: Verify on the ASA, the below shows the output after the SSH test and before the Telnet
test.
ciscoasa# show nat inside outside
match icmp inside 10.0.0.0 255.255.255.0 outside host 212.58.246.95
dynamic translation to pool 1 (192.168.2.100)
match tcp inside host 10.0.0.10 outside host 192.168.2.1 eq 23
match tcp inside host 10.0.0.10 outside host 192.168.2.1 eq 22
match ip inside any outside any
no translation group, implicit deny
policy_hits = 620
Note: Any local host could match only one translation rule for any particular traffic flow. Policy NAT
rules are evaluated BEFORE regular NAT rules, so even if this rule uses a pool ID of 10, it will be
used, rather than pool ID 1, when packets match the defined policy. The pool IDs do not dictate the
order of evaluation.
Step 8: End of Lab clean Up
ciscoasa(config)# clear configure access-list POL_NAT
ciscoasa(config)# clear configure access-list POL_SNAT
ciscoasa(config)# clear configure global
One translation hit
LAB 1.4: Dynamic NAT
In this lab you will configure Dynamic NAT for the inside networks via the ASDM to translate traffic
from 10.0.0.0/24 to an outside range of 192.168.2.10-192.168.2.50
Step 1: Complete the following substeps to configure dynamic NAT for the inside network
a. In the ASDM NAT rules panel, click Add
b. Choose Add Dynamic NAT Rule from the add menu. The Add Dynamic NAT Rule window
opens
c. Choose inside from the interface drop-down list in the Original area
d. Enter 10.0.0.0/24 in the Source field in the Original area
e. Then click Manage. The Manage Global Pool window opens
Step 2: In the Add Global Address Pool window Click Add.
a. Choose outside from the interface drop-down list
b. Verify that 1 is displayed in the Pool ID field
c. Click the Range radio button in the IP Address field
d. Enter 192.168.2.10 in the Starting IP Address field
e. Enter 192.168.2.50 in the Starting IP Address field
f. Enter 255.255.255.0 in the Netmask field
g. Click Add. The address range is display in the Addresses Pool pane
h. Then click OK
Step 3: Now you find yourself back in the Manage Global Pool follow these steps.
a. Click OK
b. Click OK in the Manage Global Pool window
c. Verify that the global pool with the Pool ID if 1 is selected in the Translated table
d. Click OK
e. Click Apply in the NAT Rules panel
f. Click the Save button in the toolbar to save the configuration to flash memory. The save
Running Configuration to Flash window is displayed.
g. Click Apply
Step 4: Complete the following substeps to test the operation of the dynamic NAT configuration that
you configured
a. From R1 establish a Telnet connection to R2 on 192.168.1.1x, The TELNET session
ought to be successful.
b. Verify the ASA xlate table, your display should appear similar to the following because a
global address chosen from the low end for the global pool range has been mapped to
the corporate server.
Global 192.168.2.13 Local 10.0.0.10
Step 5: At the ASA look at the local host table. Notice that the display shows active connections on
the inside and the outside interfaces, the translation being used, and information about the current
connection.
ciscoasa# show local-host 10.0.0.10
Interface inside: 1 active, 1 maximum active, 0 denied
local host: <10.0.0.10>,
TCP flow count/limit = 2/unlimited
TCP embryonic count to host = 0
TCP intercept watermark = unlimited
UDP flow count/limit = 13/unlimited
Xlate:
Global 192.168.2.13 Local 10.0.0.10
Conn:
UDP outside 64.215.98.148:53 inside 10.0.0.10:52768, idle 0:00:01, bytes 126, flags -
TCP outside 192.168.2.1:23 inside 10.0.0.10:51517, idle 0:00:13, bytes 110, flags UIO
UDP outside 64.215.98.148:53 inside 10.0.0.10:55276, idle 0:00:19, bytes 210, flags
Interface outside: 2 active, 31 maximum active, 0 denied
Step 6: Write the current configuration to flash memory.
ciscoasa# write memory
Step 7: How many translation are in use in the translation table
ciscoasa(config)# show xlate detail
Flags: D - DNS, d - dump, I - identity, i - dynamic, n - no random,
r - portmap, s - static
NAT from inside:10.0.0.10 to outside:192.168.2.13 flags i
Step 8: Run the show conn command, do you see the i flag, this means incomplete TCP/UDP
connection.
S = awaiting inside SYN
U = Up
O = Outbound data
A = awaiting inside ACK to SYN
a = awaiting outside ACK to SYN
ciscoasa(config)# show conn
Step 9: How many connections are in the connection table, you ought to see the connection
created by the telnet session
ciscoasa(config)# show conn detail
Flags: A - awaiting inside ACK to SYN, a - awaiting outside ACK to SYN,
B - initial SYN from outside, b - TCP state-bypass or nailed, C - CTIQBE media,
D - DNS, d - dump, E - outside back connection, F - outside FIN, f - inside FIN,
G - group, g - MGCP, H - H.323, h - H.225.0, I - inbound data,
i - incomplete, J - GTP, j - GTP data, K - GTP t3-response
k - Skinny media, M - SMTP data, m - SIP media, n - GUP
O - outbound data, P - inside back connection, p - Phone-proxy TFTP connection,
q - SQL*Net data, R - outside acknowledged FIN,
R - UDP SUNRPC, r - inside acknowledged FIN, S - awaiting inside SYN,
s - awaiting outside SYN, T - SIP, t - SIP transient, U - up,
V - VPN orphan, W - WAAS,
X - inspected by service module
UDP outside:64.215.98.148/53 inside:10.0.0.10/52230,
flags -, idle 1s, uptime 3s, timeout 2m0s, bytes 126
TCP outside:192.168.2.1/23 inside:10.0.0.10/51632,
flags UIO, idle 1s, uptime 5s, timeout 1h0m, bytes 138
Step 11: If you want to configure the below procedure via CLI
ciscoasa(config)# nat (inside) 1 10.0.0.0 255.255.255.0 tcp 0 0 udp 0
ciscoasa(config)# global (outside) 1 192.168.2.10-192.168.2.50 netmask 255.255.255.0
LAB 1.5: Static NAT translation
R1
Border_X Inside
FastEthernet 0/0
192.168.2.1/24
ASA Outside
Eth0/0
192.168.2.2 /24
ASA Inside
Eth0/1
10.0.0.1 /24
Corporate Server
IP: 10.0.0.10 /24
ASA
Border_X
R2
Towards Internet or
192.168.1.10
F0/0
S 10.0.0.10
D 8.8.8.8
S 192.168.2.50
D 8.8.8.8
ORIGINAL PACKET ONE
TRANSLATED
Step 1: in the NAT Rules panel, click Add
a. Choose Add Static NAT Rule from the Add menu. The Add Static NAT Rule window opens
b. Choose inside from the interface drop-down list in the Original area
c. Enter 10.0.0.10 in the source field of the Original area
d. Choose outside from the interface drop-down list in the Translated area
e. Verify that the Use IP Address radio button is selected, and enter 192.168.2.77 in the
corresponding field
f. Click OK and then Click Apply in the NAT Rules panel
g. Click the Save button in the toolbar to save the configuration to flash memory. The save
Running Configuration to Flash window is displayed.
Step 2: Click Apply
Step 3: From the Internet Server, try to establish a HTTP connection R1. Just open the browser on
the internet Server and in the url field type 10.0.0.10.
This attempt NOT will work, since there is no rule which allows access from the outside to the
inside.
Step 4: If you want to configure the below procedure via CLI
ciscoasa(config)# static (inside,outside) 192.168.2.77 10.0.0.10 netmask 255.255.255.255 tcp 0 0
udp 0
Part 2 - Configuring ACLs in 8.2
In this task you will configure inbound access rules on the outside interface to perform these
functions:
1. Allow inbound web traffic from the outside network to R1
2. Allow Pings to any destination
3. Allow ICMP echo replies to the corporate server
4. Deny all other inbound traffic explicitly
Activity Procedure
Complete these steps
Step 1: Use the capture command to capture packets on the outside interface so that you can later
view detailed information about packets and how they are processed by the ASA.
ciscoasa# conf t
ciscoasa(config)# capture OUTSIDE_CAP interface outside trace buffer 1534
Step 2: Open a web browser on the internet server to test web access to R1. Enter
http://192.168.2.77 you will NOT be able to access.
Step 3: Display information about the packets that you captured on the outside interface
ciscoasa(config)# show capture OUTSIDE_CAP
16 packets captured
1: 19:31:36.543261 192.168.1.10.1467 > 192.168.2.77.80: S 2911725045:2911725045(0)
win 65535 <mss 1460,nop,wscale 1,nop,nop,sackOK>
2: 19:31:39.578415 192.168.1.10.1467 > 192.168.2.77.80: S 2911725045:2911725045(0)
win 65535 <mss 1460,nop,wscale 1,nop,nop,sackOK>
Step 4: Use the packet tracer to view the cause of your denied HTTP request to R1 by completing
the following substeps. These substeps will enable you to trace an HTTP packet that is attempting
to travel through the outside interface from the Internet Server to R1. This will also enable you to
observe the lifespan of an HTTP packet through the ASA.
1. Return to the ASDM session and click on the Tools option in the ASDM menu bar.
2. Choose Packet Tracer, and the ASDM Packet Tracer window opens
3. Choose outside from the interface drop down list
4. Verify that the TCP radio button is selected
5. Enter 192.168.1.10 in the source address field
6. Enter 1025 in the source address port field
7. Enter 192.168.2.77 in the destination IP address field
8. Enter 80 in the Destination Port field
9. Verify that the Show Animation check box is checked
10. Click Start
11. Expand the CAPTURE item in the Packet Tracer Phase panel, there you will see:
Type CAPTURE
Action ALLOW
Info MAC Access list
12. Expand ACCESS-LIST, you will see the following
Type - ACCESS-LIST
Action ALLOW
Config Implicit Rule
Info MAC Access List
13. Expand FLOW-LOOKUP, you will see the following
Type FLOW-LOOKUP
Action ALLOW
Info Found no matching flow, creating a new flow
Type ACCESS-LIST
Action DROP
Config Implicit Deny
15. Expand RESULT- The packet is dropped, you will see the following
Info: (Acl drop) Flow is denied by the configured rule
16. Expand the second instance of ACCESS-LIST again and click Show Rule in Access
Rule Table. The ASDM will show the Access rule table with the rule denied the HTTP
request highlighted
Step 4: Complete the following substeps to create an access rule that permits inbound web traffic
from the 192.168.1.0/24 network to the corporate server
CLI: ciscoasa(config)# access-list outside_access_in line 1 extended permit tcp 192.168.1.0
255.255.255.0 host 192.168.2.77 eq http
1. Click Add in the Access Rules panel
2. Choose Add Access Rule. The Add Access Rule window opens
3. Choose Outside from the interface drop-down list
4. Verify that the Permit radio button is selected
5. Enter 192.168.1.0/24 in the Source field
6. Enter 192.168.2.77 in the destination field
7. Enter tcp/http in the services field
8. Click OK
Step 5: Complete the following substeps to create an access rule that permits pings from any host
to any host from the outside
CLI: ciscoasa(config)# access-list outside_access_in line 2 extended permit icmp any any echo
5. Enter any in the Source field
6. Enter any in the destination field
7. Enter icmp/echo in the services field
8. Click OK
Step 6: Complete the following substeps to create an access rule that permits ICMP echo replies to
the corporate server from any host
CLI: ciscoasa(config)# access-list outside_access_in line 3 extended permit icmp any host
192.168.2.77 echo-reply
7. Enter icmp/echo-reply in the services field
8. Click OK
Step 7: Complete the following substeps to create an access rule that permits inbound FTP access
to R1 from any host
CLI: ciscoasa(config)# access-list outside_access_in line 4 extended permit tcp any host
192.168.2.77 eq ftp
7. Enter tcp/ftp in the services field
8. Click OK
Step 8: Complete the following substeps to create an access rule that denies all other traffic from
the outside, this statement is so that you may see the hit counts.
CLI: ciscoasa(config)# access-list outside_access_in line 5 extended deny ip any any
4. Verify that the deny radio button is selected
7. Enter ip in the services field
8. Click OK
Step 9: Click Apply in the Access Rules Panel
Step 10: Go to the CLI on the ASA and run the command show access-list to view the ACLs you
just created, hit counts and line numbers
ciscoasa(config)# show access-list
access-list cached ACL log flows: total 0, denied 0 (deny-flow-max 4096) alert-interval 300
access-list outside_access_in; 5 elements; name hash: 0x6892a938
access-list outside_access_in line 1 extended permit tcp host 192.168.1.10 host 192.168.2.77 eq
www (hitcnt=0) 0x96525736
access-list outside_access_in line 2 extended permit tcp host 192.168.1.10 host 192.168.2.77 eq ftp
(hitcnt=0) 0xd10904a4
access-list outside_access_in line 3 extended permit icmp any any echo (hitcnt=0) 0x2a287810
access-list outside_access_in line 4 extended permit icmp any any echo-reply (hitcnt=0)
0x54b872f3
access-list outside_access_in line 5 extended deny ip any any (hitcnt=4) 0x2c1c6a65
Step 11: Complete the following steps to test and verify the inbound ACL.
1. From the Internet Server ping the corporate server, this should successful
2. From the Internet Server establish a connection to HTTP on R1. this should be successful
3. We will not establish a connection to the FTP server on R1, this would have been
successful. (Ask instructor why this is not tested and you will get a long and sad story)
Step 12: Display the ACLs again and look at the hit count
access-list outside_access_in line 1 extended permit tcp host 192.168.1.10 host 192.168.2.77 eq
www (hitcnt=34) 0x96525736
access-list outside_access_in line 2 extended permit tcp host 192.168.1.10 host 192.168.2.77 eq ftp
(hitcnt=2) 0xd10904a4
access-list outside_access_in line 4 extended permit icmp any any echo-reply (hitcnt=0) 0x54b872f3
Step 13: Use the packet tracer to view the HTTP request to R1 by completing the following
substeps. These substeps will enable you to trace an HTTP packet that is attempting to travel
through the outside interface from the Internet Server to R1. This will also enable you to observe the
lifespan of an HTTP packet through the ASA.
1. Return to the ASDM session on the corporate server and click on the Tools option in the
ASDM menu bar.
5. Enter 192.168.1.10 in the source address field
10. Click Start
11. When the trace is complete expand and examine the results of the various phases of the
trace in the Packet Tracer Phase panel. The RESULT phase will show as packet is
allowed
12. Close Packet Tracer window
13. On the ASA delete the packet capture
ciscoasa(config)# no capture OUTSIDE_CAP
Lab 2.2 Configure Outbound Access Rules on the ASA
In this part of the lab you will configure ACLs rules on the inside interface to perform the following
functions.
1. Deny any web traffic
2. Allow outbound Telnet traffic
3. Deny all other traffic explicitly
Step 1: Test web access to the Internet Server by telneting to 192.168.2.1 port 80.
Step 2: Test Telnet port 23 access to R2 from R1.
Step 3: Complete the following substeps to create an access rule that denies all hosts on the
internal network from making outbound HTTP connections to any host
3. Choose inside from the interface drop-down list
8. Click OK
Step 4: Complete the following substeps to create an access rule that allows host 10.0.0.10 on the
internal network from making outbound FTP connections to the internet
4. Verify that the permit radio button is selected
5. Enter 10.0.0.10 in the Source field
7. Enter tcp/telnet in the services field
8. Click OK
the intside outbound, this statement is so that you may see the hit counts.
8. Click OK
Step 6: Test web access to the Internet Server by telneting to 192.168.2.1 port 80.
Step 7: Test Telnet port 23 access to R2 from R1.
Step 8: View your outbound ACL and look at the hit counts
ciscoasa(config)# show access-list inside_access_in
access-list inside_access_in; 3 elements; name hash: 0x433a1af1
access-list inside_access_in line 1 extended deny tcp any any eq www (hitcnt=3)
0xc86ea325
access-list inside_access_in line 2 extended permit tcp host 10.0.0.10 host 192.168.1.10 eq
telnet (hitcnt=0) 0x38636938
access-list inside_access_in line 3 extended deny ip any any (hitcnt=63) 0xbe9efe96
Step 9: Remove all the explicitly configured Access Rules on the inside_access_in ACL
ciscoasa(config)# clear configure access-list inside_access_in
Step 10: Save your configuration
--------- END OF LAB 2 --------
INTENTIONALLY BLANK
SECTION 3: NAT and ACLs 8.4
Lab 3: NAT and ACL 8.4 Topology Diagram
R1
Border_X Inside
FastEthernet 0/0
192.168.2.1/24
Border_X Outside
Fastethernet 0/1
192.168.1.1x /24
ASA Outside
Eth0/0
192.168.2.2 /24
ASA Inside
Eth0/1
10.0.0.1 /24
Corporate Server
IP: 10.0.0.10 /24
Internet Server
192.168.1.2x /24
Default Gateway:
192.168.1.1X
Ip route 0.0.0.0 0.0.0.0 192.168.1.254
ASA
Border_X
R2
192.168.1.254 /24
Towards Internet or
192.168.1.10
SW2
All ports in Vlan 1
F0/0
Fa0/2
Fa0/10
VLAN 1
Fa0/7
Fa0/2
SW1
VLAN 27
Fa0/6
Fa0/1
VLAN 16
NOTE: This lab is a continuation from Lab 1.2
Lab requirements:
1. ASA is running IOS 8.4 or above
2. ASDM is 6.4 or above
ciscoasa(config)# no boot system disk0:/asa821-k8.bin
ciscoasa(config)# boot system disk0:asa843-k8.bin
ciscoasa(config)# end
ciscoasa# reload noconfirm save-config
Part 1: Configuring NAT on the ASA
Lab 3.1: Configure Static Translations Using Auto NAT
You have one Server on the inside of your network one which is addressed 10.0.0.10
The 10.0.0.10 address will be translated to 192.168.2.10
Step 1: To start the process lets run a little test to make sure all works as it should. So from R1
(10.0.0.10), establish a Telnet connection to R2 on 192.168.1.1x, you ought to be able to
establish a Telnet connection to the router without any NAT configured because NAT control is
disabled, the connection will only work if the router understands that the network R1 is residing on is
reachable via 192.168.2.2 which is the ASAs outside interface,
NOTE: If the Telnet session fails check that your Router has the following route applied
Border_X(config)# ip route 10.0.0.0 255.255.255.0 192.168.2.2
Step 2: First of all you need to configure two network Objects, the first one identifies the inside host
and the second on will identify the address which we will translate the inside host to. i.e to
192.168.2.10
ciscoasa(config)# object network CORP_1
ciscoasa(config-network-object)# host 10.0.0.10
ciscoasa(config-network-object)# exit
ciscoasa(config)# object network PUB_CORP1
Step 3: The next command under the object network you define the static NAT translation
specifying that it will be a static translation to the address under the network object called
PUB_CORP1
ciscoasa(config-network-object)# object network CORP_1
ciscoasa(config-network-object)# nat (inside,outside) static PUB_CORP1
Step 4: Test and Verify
From the corporate server establish a telnet session to 192.168.1.254. Go to R2 and enter the
following command:
R2# sho ip nat nvi translations | sec 192.168.2.10
tcp 192.168.1.1x:15255 192.168.2.10:15255 192.168.1.254:23 192.168.1.254:23
You can view the output of the static translation on the ASA
Have a look at the connections table, it shows the inside address and the outside address, this
output does not show the post translated address
For a definitive view of what the ASA is translating use the following command
ciscoasa# show nat translated 192.168.2.10
Auto NAT Policies (Section 2)
1 (inside) to (outside) source static CORP_1 PUB_CORP1
Auto NAT
Step 5: Carrying out the Static Translation using the GUI
Complete the following substeps to configure a pair of network object
a. Go to Configure > Firewall > Objects > Network Objects/Groups to open the Network
Objects window.
b. Then from the Add drop down menu, select Network Object to create a new network
object.
c. A new window appears called the Add Network Object this is where you will define a
new network object and the associated nat rules
d. In the name field enter CORP_1, this name will be used to refer to this network object
for NAT, ACLs MPF policies and so on so it ought to be shot and descriptive
e. In the type field define the type of object being created, in this case select host
f. In the IP address field enter the original (native) ip address used by this object, Enter the
IP address of 10.0.0.10
g. You may enter a description but in our example here we will leave it blank
Step 6: If you were creating a network object with no NAT rules this would be enough and click OK
to accept the new object definition but here you want to create a static NAT entry for this host as
part of the network translation, so now expand the NAT portion of the window.
a. To create an auto NAT rule and not a manual NAT rule, check the Add Automatic
Address Translation Rule box, followed by selecting the translation type of static
b. Click on the ellipsis () button to the right of the translated address field to open the
Browse Translated Addr window
c. At the Add drop down menu, select Network Object to open the Add Network Object
window once again and this time you will define a network object for the translated address.
a. In the name field enter PUB_CORP_1, this name will be used to refer to this network
object for NAT, ACLs MPF policies and so on so it ought to be shot and descriptive
b. In the type field define the type of object being created, in this case select host
c. In the IP address field enter the original (native) ip address used by this object, Enter
the IP address of 192.168.2.10
d. You may enter a description but in our example here we will leave it blank
e. Click ok to complete the creation of the translation network object and return to the
Browse Translated Addr window.
The newly created translation object appears in the list of the IPv4 network objects and is
highlighted, but it has not yet been assigned as the translated address.
Step 7: Assigning this new object as the translated address for the original network object being
created is simple, so while the translation object is highlighted, you click on Translated Addr button
at the bottom of this window, followed by clicking OK to finish the assignment and return to the
original network object window.
The Translated Addr field is now populated with translation object just created.
Step 8: This translation to occur only between a specific pair of interfaces (Inside/Outside) so it is
necessary to define the direction of this translation rule. To do so, click Advanced button at the
bottom of the Add Network Object window. This opens the Advanced NAT settings window.
Step 9: In the interface section of this window you can to select the source and de inside and the
destination interface should be set to in this case outside.
Set the interface choices and then click OK to complete the settings of the Advanced NAT settings,
then click OK to complete the definition of the new network object for the inside R1
Step 11: From the inside Corp Server (R1) telnet to 192.168.2.1 on Port 80
Step 12: Go to the command line and verify your configuration using the show xlate command
Flags: D - DNS, i - dynamic, r - portmap, s - static, I - identity, T - twice
e - extended
NAT from any:10.0.0.10 to any:192.168.2.10
flags s idle 0:00:05 timeout 0:00:00
Step 13: End of lab clean up Highlight all the objects you created delete, apply and send
Or
ciscoasa(config)# no object network CORP_1
ciscoasa(config)# no object network PUB_CORP1
Lab 3.2: Configure Static Port Translations Using Auto NAT
R1
Border_X Inside
FastEthernet 0/0
192.168.2.1/24
ASA Outside
Eth0/0
192.168.2.2 /24
ASA Inside
Eth0/1
10.0.0.1 /24
WEB SERVER
IP: 10.0.0.10 /24
ASA
Border_X
R2
F0/0
S 192.168.2.1
D 192.168.2.100:25
S 192.168.2.1
D 192.168.2.100:8443
S 192.168.2.1
D 10.0.0.11:25
S 192.168.2.1
D 10.0.0.10:443
R1
E-MAIL SERVER
IP: 10.0.0.11 /24
In this scenario you have two servers sat on the inside network. The first server has the ip address
of 10.0.0.10 and it will host a secure web based application and listens for HTTPS connections on
TCP port 8443, the second is a TELNET server, with a local IP address of 10.0.0.11, and listens for
TELNET connections on the normal TCP port 23, you only have one outside IP address available
which will be 192.168.2.100
Step 1: To keep things as simple as possible we will configure one requirement at a time. First of all
we will configure the network object for the public HTTPS ip address. The name for this Object is
PUB_HTTPS with the address of 192.168.2.100
ciscoasa(config)# object network PUB_HTTPS
Step 2: Next configure the network object called HTTPS_CORPS with the address of 10.0.0.10
Under this network object you will configure the static translation to translate the ip address and the
port number
ciscoasa(config)# object network HTTPS_CORPS
ciscoasa(config-network-object)# nat (inside,outside) static PUB_HTTPS service tcp 8443 443
Step 3: Test and Verify. To make this test as real world as possible what we will do is create a
simple ACL on the ASA to permit all TCP traffic from any source to 10.0.0.10 and apply the ACL
globally.
ciscoasa(config)# access-list PERMIT_HTTP extended permit tcp any host 10.0.0.10
ciscoasa(config)# access-group PERMIT_HTTP global
Next on R1 you will configure the secure server and change the port that it listens to connections to
the secure server to 8443
R1(config)# ip http secure-server
R1(config)# ip http secure-port 8443
R1(config)# end
R1# sho ip http server secure status
HTTP secure server status: Enabled
HTTP secure server port: 8443
HTTP secure server ciphersuite: 3des-ede-cbc-sha des-cbc-sha rc4-128-md5 rc4-128-sha
HTTP secure server client authentication: Disabled
HTTP secure server trustpoint:
HTTP secure server active session modules: ALL
Step 4: From R2 telnet to 192.168.2.100 443 and you ought to connect to 10.0.0.10 port 8443
ciscoasa# sho conn
TCP outside 192.168.2.1:14979 inside 10.0.0.10:8443, idle 0:00:05, bytes 0, flags UB
And view the translaton rules on the ASA
ciscoasa# sho nat translated interface outside
1 (inside) to (outside) source static HTTPS_CORPS PUB_HTTPS service tcp 8443 https
also you can verify the connections made to the Secure HTTP server on R1
R1#sho ip http server connection
HTTP server current connections:
local-ipaddress:port remote-ipaddress:port in-bytes out-bytes
10.0.0.10:8443 192.168.2.1:14979 0 0
Step 5: Next configure the same setup for Telnet, but this time for Telnet. We are not going to
perform any port translations, just matching the port and transalating the IP address
ciscoasa(config-network-object)# object network PUB_TELNET
ciscoasa(config)# object network TELNET
ciscoasa(config-network-object)# nat (inside,outside) static PUB_TELNET service tcp 23 23
Enter and additional line to the existing ACL on the ASA we entered for the HTTP traffic, the new
ACL will match all traffic destination 10.0.0.11
ciscoasa(config)# access-list PERMIT_HTTP extended permit tcp any host 10.0.0.11
On R1 configure 10.0.0.11 as a secondary interface under the main interface and enable telnet
access to R1
R1(config)# inter fas 0/0
R1(config-if)# ip address 10.0.0.11 255.255.255.0 secondary
R1(config-if)# exit
R1(config)# line vty 0 807
R1(config-line)# password cisco
R1(config-line)# login
R1(config-line)# exit
Next from R2 test telnet access to 10.0.0.11 port 23 and you ought to be able to connect to R1
R2# telnet 192.168.2.100 23
Trying 192.168.2.100 ... Open
User Access Verification
Password: cisco
R1>
Verify the connection on the ASA, here you will see the connnecton being made
ciscoasa# show conn
TCP outside 192.168.2.1:12009 inside 10.0.0.11:23, idle 0:02:31, bytes 186, flags UIOB
Also verify the nat translations on the ASA. (we have not removed the previous HTTP nat
translations commands therefore they are still visible)
1 (inside) to (outside) source static HTTPS_CORPS PUB_HTTPS service tcp 8443 https
2 (inside) to (outside) source static TELNET TELNET_PUB service tcp telnet telnet
Success!!
Configure Static Port Translations Using Auto NAT using the GUI
Step 1: Complete the following substeps to configure a pair of network object
Objects window.
object.
d. In the name field enter INSIDE_HTTPS, this name will be used to refer to this network
e. In the type field define the type of object being created, in this case select host
g. You may enter a description but in our example here we will leave it blank
Step 3: If you were creating a network object with no NAT rules this config would be but in this
scenario you want to create a static NAT entry for this host as part of the host, so now expand NAT
part of the window.
d. Create an auto NAT rule rather than a manual NAT rule, check the Add Automatic Address
Translation Rule box, and then select the translation type of static
e. Click on the ellipsis () button to the right of the translated address field to open the
f. From the Add drop down menu, select Network Object to open the Add Network Object
1. In the name field enter PUB_HTTPS, this name will be used to refer to this network
2. In the type field define the type of object being created, in this case select host
3. In the IP address field enter the original (native) ip address used by this object, Enter
the IP address of 192.168.2.100
4. You may enter a description but in our example here we will leave it blank
5. Click ok to complete the creation of the translation network object and return to the
Step 4: Assign this new object as the translated address for the original network object being
created, click on Translated Addr button while the translation object is highlighted at the bottom of
this window, and click OK to finish the assignment and return to the original network object window.
The Translated Addr field has the translation object just created.
Step 5: This translation is intended to occur only between a particular set of interfaces
(Inside/Outside), to define the direction of this translation rule., click Advanced button at the
bottom of the Add Network Object window. This opens the Advanced NAT settings window.
Step 6: In the interface section of this window you have the can to select the source and destination
interface, both are set to any by default, The source interface should be in this case inside and
the destination interface should be in this case outside.
Step 7: The Static port translations are configured in the service section of the Advanced NAT
window. By default protocol setting is TCP, so we will leave it like that. In the field called Real Port
enter the port that the server is configured to listen on, which is in this case 8443, in the Mapped
port field enter the port that connections will be made to on the destination interface in this case
443
Then click OK to complete the settings of the Advanced NAT settings, then click OK to complete the
definition of the new network object for the inside HTTPS server and then complete the procedure
for the SMTP server
Step 9: Go to the CLI of the ASA and run the show xlate command
Step 10: End of lab clean up Highlight all the objects you created and delete, apply and send
ciscoasa(config)# clear configure object network
ciscoasa(config)# clear configure access-list
Lab 3.3: Configure Dynamic Translations Using Auto NAT
R1
Border_X Inside
FastEthernet 0/0
192.168.2.1/24
ASA Outside
Eth0/0
192.168.2.2 /24
ASA Inside
Eth0/1
10.0.0.1 /24
IP: 10.0.0.10 /24
ASA
F0/0
S 192.168.2.XYZ
D 8.8.8.8
S 10.0.0.10
D 8.8.8.8
In this scenario you will configure a dynamic translation for the inside network 10.0.0.0/24 to a range
of translated addresses 192.168.2.150-200 for use on the outside interface. These translations will
be one-to-one (NAT not PAT). If this pool of addresses is exhausted you want to back up this
translation range by using PAT with the interface address of the ASA acting as a PAT translation
address.
Step 1: Configure the network object to match the inside range of 10.0.0.0/24
ciscoasa(config)# object network INSIDE_RANGE
ciscoasa(config-network-object)# subnet 10.0.0.0 255.255.255.0
Step 2: Configure the network object to match the outside range of 192.168.2.150 to 200/24
ciscoasa(config)# object network OUTSIDE_NAT_POOL
ciscoasa(config-network-object)# range 192.168.2.150 192.168.2.200
Step 3: Configure the NAT translation under the network object
ciscoasa(config)# object network INSIDE_RANGE
ciscoasa(config-network-object)# nat (inside,outside) dynamic OUTSIDE_NAT_POOL interface
From R1 telnet to 192.168.2.1 then verify the connection on the ASA
ciscoasa# show conn
Also have a look at the translations on the ASA as well.
ciscoasa# show nat translated interface outside
1 (inside) to (outside) source dynamic INSIDE_RANGE OUTSIDE_NAT_POOL interface
Although we have not yet been able to determine what address the original packet was translated to
you can run show users command on R2. Or simply run this command on the ASA
ciscoasa# sho xlate
e - extended
NAT from inside:10.0.0.10 to outside:192.168.2.181 flags i idle 0:00:04 timeout 3:00:00
Complete the following substeps to configure a pair of network object
Objects window.
object.
d. In the name field enter INSIDE_SEGMENT, this name will be used to refer to this
network object for NAT, ACLs MPF policies and so on so it ought to be shot and
descriptive
e. In the type field define the type of object being created, in this case select Network
g. In the netmask field enter the mask of 255.255.255.0
h. You may enter a description but in our example here we will leave it blank
Step 3: If you were creating a network object with no NAT rules you would be done at this point and
would click OK to accept the new object definition but in this scenario you want to create a static
NAT entry for this host as part of the network definition, therefore expand the NAT portion of the
window.
a. To create a auto NAT rule rather than a manual NAT rule, check the Add Automatic
Address Translation Rule box, and then select the translation type of dynamic
b. Click on the ellipsis () button to the right of the translated address field to open the
c. From the Add drop down menu, select Network Object to open the Add Network Object
1. In the name field enter OUTSIDE_NATPOOL, this name will be used to refer to this
network object for NAT, ACLs MPF policies and so on so it ought to be shot and
descriptive
2. In the type field define the type of object being created, in this case select Range
3. In the Start Address field enter the start of the range ip address used by this object,
Enter the IP address of 192.168.2.150
4. In the End Address field enter the start of the range ip address used by this object,
Enter the IP address of 192.168.2.200
5. You may enter a description but in our example here we will leave it blank
6. Click ok to complete the creation of the translation network object and return to the
Step 4: To assign this new object as the translated address for the original network object being
created, while the translation object is highlighted, click on Translated Addr button at the bottom of
this window, and then click OK to complete the assignment and return to the original network object
definition window.
The Translated Addr field is now populated with information for the translation object you just
created.
Step 5: At the bottom of this window, check the Fall through to interface PAT (Dest Intf) button
and select the outside interface from the drop down list. Doing this also sets the outside interface
as the destination interface for this rule, as if you had entered the Advanced NAT settings window
and made such a change, Finally click OK to complete the creation of the new Network Object.
Step 7: Go to the CLI of the ASA and run the show xlate command
e - extended
NAT from any:10.0.0.10 to outside:192.168.2.188 flags i idle 0:00:01 timeout 3:00:00
ciscoasa#
ciscoasa(config)# clear configure object
3.4 Configuing Manual NAT
Manual NAT rules are checked before Auto NAT.
If you go back to the output of the show nat translated interface outside commands of the
previous NAT ing example you will notice in the output the statement Auto NAT Policies (Section
2)
Manual NAT rules are configured in Section 1 and are therefore checked before Section 2 unless
you configure the Manual NAT rule with the command after-auto which will appear in Section 3.
ciscoasa# show nat translated interface outside
1 (inside) to (outside) source dynamic INSIDE_RANGE OUTSIDE_NAT_POOL interface
Why and when would you use Manual Nat?, simple this type of NAT allows granular control of the
Packet, for example you can configure Manual NAT to translate both the Source and the
Destination of the Packet which is useful in situations when the source and destination networks are
on the same subnet.
LAB 3.5 MANUAL NAT: EXAMPLE ONE POLICY NAT
In the First example you are going to translate traffic from 10.0.0.0/24 to 192.168.2.50 only if the
packet is going to the destination address 200.200.200.200 port 80 which will also be translated and
we will translate the destination address to 100.100.100.100 port 23.
This is very similar to the Lab earlier on Dynamic Inside Policy NAT on ASA IOS 8.2.
Step 1: Create two object groups that will be used to match the destination IP addresses of the
packets leaving the ASA
This one will match the destination prior to the translation, hence this is the original source
ciscoasa(config)# object network DEST_ORIGINAL
This one will be used to replace the 200.200.200.200 in the destination field
ciscoasa(config)# object network DEST_TRANSLATED
Step 2: Create two object groups that will be used to match the source IP addresses of the packets
leaving the ASA
This one will match all the traffic coming from the subnet 10.0.0.0/24
ciscoasa(config)# object network SOURCE_ORIGINAL
This one will replace the subnet 10.0.0.0/24 with the address of 192.168.2.50
ciscoasa(config)# object network SOURCE_TRANSLATED
Step 3: Create the two service objects which will match the destination ports.
This service object will match the original destination port number
ciscoasa(config)# object service ORIGINAL_DPORT
ciscoasa(config-service-object)# service tcp destination eq www
This service object will replace original destination port of 80 with the destination port of 23
ciscoasa(config)# object service TRANSLATED_DPORT
ciscoasa(config-service-object)# service tcp destination eq telnet
Step 4: The next step is to put all the statements together
ciscoasa(config)# nat (inside,outside) 1 source dynamic SOURCE_ORIGINAL
SOURCE_TRANSLATED destination static DEST_ORIGINAL DEST_TRANSLATED service
ORIGINAL_DPORT TRANSLATED_DPORT
Step 5: Go to R2 and create the following interface and enable Telnet access
R2(config)# inter loop 100
R2(config-if)# ip add 100.100.100.100 255.255.255.0
R2(config-if)# exit
R2(config)# line vty 0 807
R2(config-line)# password cisco
R2(config-line)# login
Step 6: Go to R1 and telnet to 200.200.200.200 port 80 and you ought to the password prompt
R1# telnet 200.200.200.200 80
Trying 200.200.200.200, 80 ... Open
Password:
R2>
Step 7: Test and Verification
Go to the ASA and run the following command
Manual NAT Policies (Section 1)
1 (inside) to (outside) source dynamic SOURCE_ORIGINAL SOURCE_TRANSLATED
destination static DEST_ORIGINAL DEST_TRANSLATED service ORIGINAL_DPORT
TRANSLATED_DPORT
Success
Translations
Run the show connections and show xlate on the ASA
ciscoasa# show conn
TCP outside 200.200.200.200(100.100.100.100):23 inside 10.0.0.10:31998, idle 0:03:52,
bytes 209, flags UIO
And the show xlate, note the Flags, this NAT rule also falls under the TWICE NAT rule along with
port mapping
e - extended
TCP PAT from outside:100.100.100.100 23-23 to inside:200.200.200.200 80-80
flags srT idle 0:06:09 timeout 0:00:00
TCP PAT from inside:10.0.0.10/31998 to outside:192.168.2.50/31998 flags ri idle 0:06:09
timeout 0:00:30
Inside address has been
translated to 192.168.2.50
This rule is deemed to fall
under Twice NAT
Step 8: Command explained
SOURCE_TRANSLATED destination static DEST_ORIGINAL DEST_TRANSLATED service
source dynamic SOURCE_ORIGINAL SOURCE_TRANSLATED
Matches the original source address SOURCE_ORIGINAL to be translated dynamically to
to the translated source address of SOURCE_TRANSLATED
destination static DEST_ORIGINAL DEST_TRANSLATED
Matches the original destination addres DEST_ORIGINAL that will be translated to
DEST_TRANSLATED
service ORIGINAL_DPORT TRANSLATED_DPORT
Match the original destination port number ORIGINAL_DPORT to be translated to
TRANSLATED_DPORT
NOTE: Mapping port numbers can only be carried out for destination ports and not source
Step 9: Clear object and NAT statements off of the ASA.
Lab 3.6 MANUAL NAT: EXAMPLE TWO POLICY NAT
In this second example you are going to translate traffic from 10.0.0.0/24 to 192.168.2.50 only if the
packet is going to the destination address 200.200.200.200 port 80. The destination IP address will
not be translated only the destination L4 port number will be translated to 23 once more
Step 2: Create two object groups that will be used to match the source IP addresses of the packets
leaving the ASA
This one will replace the subnet 10.0.0.0/24 with the address of 192.168.2.50
ciscoasa(config)# object network SOURCE_TRANSLATED
SOURCE_TRANSLATED destination static DEST_ORIGINAL DEST_ORIGINAL service
Step 5: Go to R2 and create the following interface and enable Telnet access
R2(config)# inter loop 100
R2(config-if)# ip add 200.200.200.200 255.255.255.0 secondary
R2(config-if)# exit
Step 6: Test and Verify: Go to R1 and telnet to 200.200.200.200 port 80
R1# telnet 200.200.200.200 80
Trying 200.200.200.200, 80 ... Open
Password:
R2>
Step 7: Examine the outputs on the ASA. Note that the destination address has not been modified
from the original address only the source address and the destination ports have been changed
e - extended
flags srIT idle 0:01:39 timeout 0:00:00
TCP PAT from inside:10.0.0.10/20922 to outside:192.168.2.50/20922 flags ri idle 0:01:39
timeout 0:00:30
Have a look at the nat translation command on the ASA. Here you can see how many translate and
untranslate hits the rule has had
1 (inside) to (outside) source dynamic SOURCE_ORIGINAL SOURCE_TRANSLATED
destination static DEST_ORIGINAL DEST_ORIGINAL service ORIGINAL_DPORT
TRANSLATED_DPORT
SUCCESS
Step 8: Clear object and NAT statements off of the ASA.
LAB 3.7 MANUAL NAT: EXAMPLE THREE POLICY NAT
In this third example you are going not to translate traffic from 10.0.0.0/24. You will only translate
the destination address of the packet going to the destination address 200.200.200.200 port 80. The
destination address will be translated to 100.100.100.100 and the destination port number will be
translated to 23 once again
This one will be used to replace the 200.200.200.200 in the destination field
ciscoasa(config)# object network DEST_TRANSLATED
Step 2: Create one object groups that will be used to match the source IP addresses of the packets
leaving the ASA
ciscoasa(config)# nat (inside,outside) 1 source static SOURCE_ORIGINAL SOURCE_ORIGINAL
destination static DEST_ORIGINAL DEST_TRANSLATED service ORIGINAL_DPORT
TRANSLATED_DPORT
Step 5: Test and Verify: Go to R1 and telnet to 200.200.200.200 port 80
R1# telnet 200.200.200.200 80
Trying 200.200.200.200, 80 ... Open
Password:
R2>
Step 7: Examine the outputs on the ASA. Note that the destination address and ports have been
modified from the original addresses but the source have been unchanged
SUCCESS
e - extended
TCP PAT from inside:10.0.0.0/24 0 to outside:10.0.0.0/24 0
flags srIT idle 0:00:06 timeout 0:00:00
flags srT idle 0:00:06 timeout 0:00:00
Also have a look at the NAT on ASA to, you ought to see a couple of translate an untranslate hits
1 (inside) to (outside) source static SOURCE_ORIGINAL SOURCE_ORIGINAL destination
static DEST_ORIGINAL DEST_TRANSLATED service ORIGINAL_DPORT
TRANSLATED_DPORT
Step 8: Clear the configuration.
3.8 MANUAL NAT: EXAMPLE FOUR NAT EXEMPTION
In this fourth example of Manual NAT you will configure the traffic coming from 10.0.0.10 going to
Google DNS 8.8.8.8 to be exempted from NAT
R1
Border_X Inside
FastEthernet 0/0
192.168.2.1/24
ASA Outside
Eth0/0
192.168.2.2 /24
ASA Inside
Eth0/1
10.0.0.1 /24
WEB SERVER
IP: 10.0.0.10 /24
ASA
Border_X
R2
F0/0
S 10.0.0.10
D 8.8.8.8
S 10.0.0.10
D 8.8.8.8
Step 1: Configure two object groups, one matching Google DNS address of 8.8.8.8 and the other
matching the host address 10.0.0.10
ciscoasa(config)# object network GOOGLE
ciscoasa(config-network-object)# object network INSIDE_HOST
Step 2: Configure the nat rule to match real source INSIDE_HOST to the mapped source
INSIDE_HOST and the destination static of mapped destination GOOGLE and the real destination
GOOGLE
ciscoasa(config)# nat (inside,outside) 1 source static INSIDE_HOST INSIDE_HOST destination
static GOOGLE GOOGLE
Real source
mapped source
Mapped Destination Real Destination
Step 3: Send traffic from the R1 device to 8.8.8.8
e - extended
NAT from inside:10.0.0.10 to outside:10.0.0.10
flags sI idle 0:00:05 timeout 0:00:00
NAT from any:10.0.0.10 to outside:192.168.2.192 flags i idle 0:00:06 timeout 3:00:00
Step 4: Debug NAT on the Router, you will see that the traffic is arriving with no translation
R2# debug ip nat
NAT*: s=10.0.0.10->192.168.1.201, d=8.8.8.8 [18335]
NAT*: s=8.8.8.8, d=192.168.1.201->10.0.0.10 [0]
NAT*: s=10.0.0.10->192.168.1.201, d=8.8.8.8 [18336]
NAT*: s=8.8.8.8, d=192.168.1.201->10.0.0.10 [0]
NAT*: s=10.0.0.10->192.168.1.201, d=8.8.8.8 [18337]
Step 8: End of lab clean up Highlight all the objects you created.
ciscoasa(config)# NO nat (inside,outside) 1 source static INSIDE_HOST INSIDE_HOST
destination static GOOGLE GOOGLE
ciscoasa(config)# no object network GOOGLE
ciscoasa(config)# no object network INSIDE_HOST
Part 2: Configuring ACLs on the ASA 8.4
In this task you will configure inbound access rules on the outside interface of the ASA to perform
these functions:
1. inbound web traffic from the outside network (From the machine designated as the internet
server) to R1
2. Allow Pings to any destination
3. Allow ICMP echo replies to the R1
4. Deny all other inbound traffic explicitly
Step 1: Re-enter the static NAT rule from the previous lab
ciscoasa(config)# object network CORP_1
ciscoasa(config-network-object)# object network PUB_CORP1
ciscoasa(config-network-object)# object network CORP_1
ciscoasa(config-network-object)# nat (inside,outside) static PUB_CORP1
Step 2: Use the capture command to capture packets on the outside interface so that you can later
view detailed information about packets and how they are processed by the ASA.
ciscoasa# conf t
ciscoasa(config)# capture OUTSIDE_CAP interface outside trace buffer 1534
Step 3: Open a web browser on the internet server 192.168.1.2x to test web access to R1 Enter
http://192.168.2.10 you will NOT be able to access R1 via its static mapping with configuring an
ACL to permit the inbound HTTP traffic to R1
Step 4: Display information about the packets that you captured on the outside interface
ciscoasa(config)# show capture OUTSIDE_CAP
10 packets captured
1: 20:38:46.129082 192.168.1.2x.1106 > 192.168.2.10.80: S 1286904092:1286904092(0)
win 65535 <mss 1260,nop,nop,sackOK>
2: 20:38:49.113489 192.168.1.2x.1106 > 192.168.2.10.80: S 1286904092:1286904092(0)
3: 20:38:55.022337 192.168.1.2x.1106 > 192.168.2.10.80: S 1286904092:1286904092(0)
4: 20:38:59.752112 192.168.1.2x.137 > 192.168.2.255.137: udp 50
5: 20:39:00.500492 192.168.1.2x.137 > 192.168.2.255.137: udp 50
6: 20:39:01.251711 192.168.1.2x.137 > 192.168.2.255.137: udp 50
7: 20:39:02.007598 192.168.1.2x.137 > 192.168.2.255.137: udp 50
8: 20:39:02.753943 192.168.1.2x.137 > 192.168.2.255.137: udp 50
9: 20:39:03.505085 192.168.1.2x.137 > 192.168.2.255.137: udp 50
10: 20:39:10.477712 192.168.1.2x.137 > 192.168.2.255.137: udp 50
10 packets shown
Step 5: Use the packet tracer to view the cause of your denied HTTP request to R1 by completing
the following substeps. These substeps will enable you to trace an HTTP packet that is attempting
to travel through the outside interface from the Internet Server to R1. This will also enable you to
observe the lifespan of an HTTP packet through the ASA.
17. Return to the ASDM session on R1 and click on the Tools option in the ASDM menu bar.
21. Enter 192.168.1.2x in the source address field
26. Click Start
27. Expand the CAPTURE item in the Packet Tracer Phase panel, there you will see:
Type CAPTURE
Action ALLOW
Info MAC Access list
28. Expand ACCESS-LIST item directly below the CAPTURE item, you will see the following
Type - ACCESS-LIST
Action ALLOW
Config Implicit Rule
Info MAC Access List
29. Expand UN-NAT, you will see the following
Type UN-NAT
Subtype - STATIC
Action ALLOW
Config nat (inside,outside) source static CORP-SERVER CORP-SERVER-TRANS
Info - NAT divert to egress interface inside
Untranslate 192.168.2.10/80 to 10.0.0.10/80
Type ACCESS-LIST
Action DROP
Config Implicit Deny
31. Expand RESULT- The packet is dropped, you will see the following
Info: (Acl drop) Flow is denied by the configured rule
32. Expand the second instance of ACCESS-LIST again and click Show Rule in Access
Rule Table. The ASDM will show the Access rule table with the rule denied the HTTP
request highlighted
Step 6: Complete the following substeps to create an access rule that permits inbound web traffic
from the any network to the R1
16. Click OK
The command line for the rule above is
ciscoasa(config)# access-list outside_access_in line 1 extended permit tcp any object CORP-
SERVER eq http
Step 7: Complete the following substeps to create an access rule that permits pings from any host
to any host
16. Click OK
ciscoasa(config)# access-list outside_access_in line 2 extended permit icmp any any echo
Step 8: Complete the following substeps to create an access rule that permits ICMP echo replies to
the R1 from any host
15. Enter icmp/echo-reply in the services field
16. Click OK
ciscoasa(config)# access-list outside_access_in line 3 extended permit icmp any object CORP-
SERVER echo-reply
the outside, this statement is so that you may see the hit counts.
16. Click OK
ciscoasa(config)# access-list outside_access_in line 5 extended deny ip any any
ciscoasa(config)# access-group outside_access_in in interface outside
Step 10: Click Apply in the Access Rules Panel
The command line to apply all the rules created above is
ciscoasa(config)# access-group outside_access_in in interface outside
Step 11: Go to the CLI on the ASA and run the command show access-list to view the ACLs you
just created, hit counts and line numbers
access-list cached ACL log flows: total 0, denied 0 (deny-flow-max 4096)
alert-interval 300
access-list outside_access_in line 1 extended permit tcp any object CORP-SERVER eq www
(hitcnt=0) 0x9c95dd70
access-list outside_access_in line 1 extended permit tcp any host 10.0.0.10 eq www
(hitcnt=3) 0x9c95dd70
access-list outside_access_in line 2 extended permit icmp any any echo (hitcnt=236)
0x2a287810
access-list outside_access_in line 3 extended permit icmp any any echo-reply (hitcnt=0)
0x54b872f3
Step 12: Complete the following steps to test and verify the inbound ACL.
4. From the Internet Server ping R1 on 192.168.2.10, this should successful
5. From the Internet Server establish a connection to the website on R1. On 192.168.2.10,
this should be successful
Step 13: Display the ACLs again and look at the hit count
access-list outside_access_in line 1 extended permit tcp host 192.168.1.2x host 192.168.2.10 eq
www (hitcnt=34) 0x96525736
access-list outside_access_in line 3 extended permit icmp any any echo-reply (hitcnt=0) 0x54b872f3
Step 14: Use the packet tracer to view the HTTP request to R1 by completing the following
substeps. These substeps will enable you to trace an HTTP packet that is attempting to travel
through the outside interface from the Internet Server to R1. This will also enable you to observe the
lifespan of an HTTP packet through the ASA.
14. Return to the ASDM session on R1 and click on the Tools option in the ASDM menu bar.
18. Enter 192.168.1.2x in the source address field
23. Click Start
24. When the trace is complete expand and examine the results of the various phases of the
trace in the Packet Tracer Phase panel. The RESULT phase will show as packet is
allowed
25. Close Packet Tracer window
26. On the ASA delete the packet capture
ciscoasa(config)# no capture OUTSIDE_CAP
Part 3: Configuring Outbound ACLs on the ASA
functions.
4. Deny any web traffic
5. Allow outbound TELNET traffic
Step 1: Test web access from R1 to R1 by telneting to 192.168.2.1 port 80.
Step 2: Test telnet from R1 to 192.168.2.1.
Step 3: Complete the following substeps to create an access rule that denies all hosts on the
internal network from making outbound HTTP connections to any host
16. Click OK
ciscoasa(config)# access-list inside_access_in line 1 extended deny tcp any any eq http
Step 4: Complete the following substeps to create an access rule that allows host 10.0.0.10 on the
internal network from making outbound Telnet connections to the internet
16. Click OK
ciscoasa(config)# access-list inside_access_in line 2 extended permit tcp object CORP-
SERVER any eq telnet
the intside outbound, this statement is so that you may see the hit counts.
16. Click OK
ciscoasa(config)# access-list inside_access_in line 3 extended deny ip any any
ciscoasa(config)# access-group inside_access_in in interface inside
Step 6: Test web access from R1 to R1 by telnetting port 80.
Step 7: Test Telnet from R1 to R2
You ought to be able to gain access to the Border Router
Step 8: View your ACL and examine the hit counts
ciscoasa(config)# show access-list inside_access_in
access-list inside_access_in line 1 extended deny tcp any any eq www (hitcnt=21)
0xc86ea325
access-list inside_access_in line 2 extended permit tcp host 10.0.0.10 any eq telnet
(hitcnt=1) 0x7ed34f47
Cryptochecksum: 10453552 be303fa0 b4fadc01 ec7e6e96
[OK]
---------END OF LAB--------
Part 4: Handling ICMP Traffic
From as far back as PIX 7.X the firewall will respond to ICMP messages apart from ICMP messages
send to the broadcat address of the subnet.
Step 1: From R2 ping the ASA on 192.168.2.2, it ought to respond.
Border_x# ping 192.168.2.2
Step 2: If you do not want the ASA to respond to any ICMP requests enter the following command
and then from R2 ping 192.168.2.2 once more.Once the below has been placed on the ASA the
pings will fail, also if you try to ping 8.8.8.8 from the ASA itself the pings will also fail
ciscoasa(config)# icmp deny any outside
Step 3: In this step you will remove the command from step 2 and enter a command which allows
the ASA to ping any outside destination, but not to reply to echo requests.
ciscoasa(config)# icmp permit any echo-reply outside
Next ping 192.168.2.2 from R2, the pings ought to fail, but if you ping 8.8.8.8 once again from the
ASA they ought to work.
Step 4: Next from the ASA run a traceroute to 192.168.2.1, this will fail with the command as it is
from step 3.
ciscoasa(config)# traceroute 192.168.2.1 numeric
Type escape sequence to abort.
Tracing the route to 192.168.2.1
1 * * *
Note: Break the traceroute use the Ctrl+Shift+6
Step 5: To fix the Traceroute enter the following commands
ciscoasa(config)# icmp permit any time-exceeded outside
ciscoasa(config)# icmp permit any unreachable outside
Step 6: Once again run the Traceroute from the ASA to 192.168.2.1
ciscoasa(config)# traceroute 192.168.2.1
Tracing the route to 192.168.2.1
1 192.168.2.1 0 msec * 0 msec
Step 7: Clear configuration
ciscoasa(config)# no icmp permit any echo-reply outside
ciscoasa(config)# no icmp permit any unreachable outside
ciscoasa(config)# no icmp permit any time-exceeded outside
SECTION 4: HANDLING TRAFFIC
Lab 4: Topology Diagram
This lab is a continuation from Lab 1.3 Do Not Erase any Config
Part 1: Traffic Inspection on the ASA
The MPF concept is a very powerful and flexible process that can help you secure your
environment. The MPF is a set of three nested items:
Class map: Class-map are what you will configure and use on the ASA to match traffic. Use the
Class-map command
Policy map: Policy map are were you take action on the traffic you have matched using class
maps. Use the policy-map command
Service policy: A service policy is how you apply the policies you create to and interface or
globally using the service-policy command
The MPF (Modular Policy Framework) is as the name suggests Modular and as such can be built
so that service policies can have more than one policy map and policy-maps can refer to one or
more class maps and class-maps can refer to one or more matching elements.
The ASA contains one default Class-map, one Policy Map and one Service policy to see the default
settings you can use the show running-config service-policy command
Step 1: To view the default service policy that is tied to something called global_policy, which
has been applied globally to all ASA interfaces.
A service policy will always references a policy map.
ciscoasa(config)# show running-config service-policy
service-policy global_policy global
Step 2: The name of the policy map is global_policy. To see what the policy map is doing have a
look at it by running the show running-config policy-map global_policy command to display its
contents.
ciscoasa# show running-config policy-map global_policy
!
policy-map global_policy
class inspection_default
inspect dns preset_dns_map
inspect ftp
inspect h323 h225
inspect h323 ras
inspect rsh
inspect rtsp
inspect esmtp
inspect sqlnet
inspect skinny
inspect sunrpc
inspect xdmcp
inspect sip
inspect netbios
inspect tftp
inspect ip-options
This policy map called global_policy references a class command followed by a list of inspect
commands.
A policy map is used to identify traffic first using a class-map to do so and then perform some action
on it.
Step 3: To find out what sort of traffic is being classified in the policy map look at the class map
called inspection_default, do that by using the show running-config class-map
inspection_default command.
ciscoasa# show running-config class-map inspection_default
class-map inspection_default
match default-inspection-traffic
This particular class map contains a only single match command which identifies the appropriate
traffic. For ease of use and configuration the match default-inspection-traffic command matches
a default list of protocols and port numbers that are commonly inspected.
Part 2: Configuring a Policy for Inspecting OSI Layers 3 and 4
With the MPF, you can configure a class map that identifies a specific type of traffic according to
parameters found in OSI Layers 3 and 4, or the IP and UDP packet headers or TCP packet
headers, respectively. You can apply that class map to a policy map that can take action on the
matching traffic.
You can use the following steps to configure a security policy:
Step 1: Create a Layers 34 class map.
Step 2: Create a Layers 34 policy map.
Step 3: Finally apply the policy map to the appropriate interfaces.
Step 1: Define Layers 34 Class Maps
WARNING: You can define only one matching condition in a class map
The ASA can identify or classified traffic moving through it according to the matching statements
which have been defined in the class map.
It is possible to create multiple class-maps to match different classes of traffic and then a new policy
can be set on each class of traffic.
First, identify the class map with the class-map command. Give the class map an arbitrary name as
class_map_name, and then use the description command to describe the purpose of the class
map. If the class map does not already exist, a new one will be created.
ciscoasa(config)# class-map class_map_name
ciscoasa(config-cmap)# description text
Class-maps will allow you to match any one of the following:
All traffic: All packets passing through an ASA interface
Access list: Use an access list that will match according to protocol, IP addresses, port numbers
Traffic flow: Packets destined for a unique IP address, where the policy action will be applied on
a per-flow basis
Default traffic: Packets which belong to a predefined set of protocols and port numbers
Destination port: Packets being sent to a destination port number or even a range of port
numbers
Example: Only do not enter
RTP port range: Real-time Transport Protocol (RTP) packets within a range of UDP port
numbers
QoS values: Up to four matching IP precedence values, or up to eight DSCP values
VPN group: Packets that pass through a specific VPN tunnel group.
Step 1: In this configuration you will configure four individual access-control lists
A. Matching any traffic source and destination going to port 80
B. Matching any traffic source and destination going to port 53
C. Matching any traffic source and destination going to port 443
D. Matching any traffic source and destination using ICMP
A: Matching any traffic source and destination going to port 80
ciscoasa(config)# access-list MATCH-HTTP extended permit tcp any any eq 80
B: Matching any traffic source and destination going to port 53
ciscoasa(config)# access-list MATCH-DNS extended permit udp any any eq 53
C: Matching any traffic source and destination going to port 53
ciscoasa(config)# access-list MATCH-HTTPS extended permit tcp any any eq 443
D: Matching any traffic source and destination going to port 53
ciscoasa(config)# access-list MATCH-ICMP extended permit icmp any any
Step 2: Create the class-maps and assign the ACLs to the classmaps
ciscoasa(config)# class-map CM_HTTP
ciscoasa(config-cmap)# match access-list MATCH-HTTP
ciscoasa(config-cmap)# exit
ciscoasa(config)# class-map CM_DNS
ciscoasa(config-cmap)# match access-list MATCH-DNS
ciscoasa(config)# class-map CM_HTTPS
ciscoasa(config-cmap)# match access-list MATCH-HTTPS
ciscoasa(config)# class-map CM_ICMP
ciscoasa(config-cmap)# match access-list MATCH-ICMP
ciscoasa(config)#
Step 3: Define a Layer 34 Policy Map
Once you have defined the class maps the next thing to do is create the policy maps to perform
acrtions on the matched traffic.
The first three class-maps will be matched and inspected. the fourth i.e will be inspected and
policed.
ciscoasa(config)# policy-map PM_POLICY_MAP
ciscoasa(config-pmap)# class CM_HTTP
ciscoasa(config-pmap-c)# inspect http
ciscoasa(config-pmap-c)# exit
ciscoasa(config-pmap)# class CM_HTTPS
ciscoasa(config-pmap-c)# inspect http
ciscoasa(config-pmap)# class CM_DNS
ciscoasa(config-pmap-c)# inspect dns
ciscoasa(config-pmap)# class CM_ICMP
ciscoasa(config-pmap-c)# police output 8000
ciscoasa(config-pmap-c)# inspect icmp
ciscoasa(config-pmap)# exit
ciscoasa(config)#
Step 4: To match all traffic which you have not classified you can rely on the default class map
called class default.
This class map is configured by default and will match any traffic. If you execute the command
below you ought to see the class default listed.
NOTE: If you do not see the default class shown do not worry it is not always shown
ciscoasa# show running-config policy-map PM_POLICY_MAP
policy-map PM_POLICY_MAP
class CM_HTTP
inspect http
class CM_HTTPS
inspect http
class CM_DNS
inspect dns
class CM_ICMP
police output 8000
inspect icmp
class class-default
Policed to 8000 bits per second
The following list summarizes the actions that are possible.
Police or shape the traffic to control the bandwidth used
Give the traffic priority handling through the ASA
Set connection limits
Adjust TCP options
Inspect the traffic with an application inspection engine
Inspect the traffic with an IPS or CSC module
Export traffic information as NetFlow export data
Note: Be aware that the actions might not be carried out in exactly the same order you enter them
in the configuration. If multiple actions are found in a security policy, they are performed in the
following order:
1. QoS policing of ingress traffic
2. Set connection limits and TCP options
3. Send traffic to the CSC module
4. Application inspection
5. Send traffic to the IPS module
6. QoS policing of egress traffic
7. QoS priority handling
8. QoS traffic shaping
Step 5: Apply the Policy Map to the Appropriate Interfaces
The policy map could be applied to either one or even to all the ASA interfaces. Use the following
command to define a service policy that binds a policy map to an interface: You can use the global
keyword to apply the policy map globally, to all ASA interfaces.
Apply the policy map PM_POLICY_MAP the configured in step 3 to the outside ASA interface.
ciscoasa(config)# service-policy PM_POLICY_MAP interface outside
NOTE: The ASA supports only one global service policy. Remember that a global service policy is
configured by default.
The actions applied by a policy map are limited to a particular traffic direction. The enforcements is
dependent on how the service policy is applied.
Most actions can act on traffic in both the ingress and egress direction when the service policy is
applied to a single interface, but only in the ingress direction if applied globally.
Actions related to Policing, haping, and priority handling are either ingress or egress.
Action Applied to Interface Applied Globally
Set connection limits Bidirectional Ingress only
Adjust TCP options Bidirectional Ingress only
Inspect with application engines Bidirectional Ingress only
Offload to IPS or CSC module Bidirectional Ingress only
Shaping Egress only Egress only
Priority handling Egress only Egress only
Policing (input) Ingress only Ingress only
Policing (output) Egress only Egress only
Step 6: To test the policy map send a continuous ping to 8.8.8.8 from the corporate server (R1), this
ought to be successful. Stop the pings and then telnet to 192.168.2.1 using port 80.
The ICMP inspection engine allows ICMP traffic to have a "session" so it can be inspected like TCP
and UDP traffic. ICMP inspection ensures that there is only one response for each request, and that
the sequence number is correct.
Run the following command, as you will see that the counters are incrementing as the traffic is
inspected flowing through and out of the interface
ciscoasa# sho service-policy interface outside
Interface outside:
Service-policy: PM_POLICY_MAP
Class-map: CM_HTTP
Inspect: http, packet 16, drop 0, reset-drop 0
Class-map: CM_HTTPS
Class-map: CM_ICMP
Output police Interface outside:
cir 8000 bps, bc 1500 bytes
conformed 463 packets, 34262 bytes; actions: transmit
exceeded 0 packets, 0 bytes; actions: drop
conformed 584 bps, exceed 0 bps
Inspect: icmp, packet 926, drop 0, reset-drop 0
Part 3: Tuning Basic Layers 34 Connection Limits
Not only can the ASA inspect traffic but can also place limits on the number of layers 34
connections which form thorugh it. The two basic connection limits are available:
Connection timeouts: The duration of TCP connections in various states
Connection volumes: The number of simultaneous connections
Both types of connection limits are configured with the set connection command within a policy
map.
Step 1: Setting the TCP idle timeout on http session under the Policy map.
ciscoasa(config-pmap-c)# set connection timeout idle 0:0:30
Step 2: Verify and test the Configuration
ciscoasa# show service-policy interface outside
Interface outside:
Class-map: CM_HTTP
Set connection policy: drop 0
Set connection timeout policy:
idle 0:00:30
DCD: disabled, retry-interval 0:00:15, max-retries 5
DCD: client-probe 0, server-probe 0, conn-expiration 0
=================output omitted for brevity=======================
Idle timeout set to 30 secs
From R1 telnet to 192.168.2.1 port 80 (Simply connect do not type any commands in)
From there go to the asa and enter the show conn or show conn detail command and watch
the idle timer increament once it reaches 30 the connection ought to close.
ciscoasa# sho conn detail
flags U, idle 29s, uptime 29s, timeout 30s, bytes 0
There are timeouts already set in the global ASA configuration but with this configuration you can
set individual timeouts for particular matched traffic. If you want to set unlimted timeout use 0
Step 3: It is possible that some TCP sessions can remain idle for a little while but still be valid and
closing them can prove to be a little annoying. Therefore rather than drop any idle session you could
use the dcd feature to detect if the clients are still active.
When the TCP connection has been idle for the tcp timeout duration, the ASA will begin to send
probes to the devices to see if they they are still responsive. If the devices answer then connection
is still valid and should not be closed for being idle. Enter the following DCD value below.
ciscoasa(config-pmap-c)# set connection timeout dcd 0:20:00
Step 4: Test and verify, once again from R1 telnet to 192.168.2.1 port 80 (Simply connect do not
type any commands. From there go to the asa and enter the show conn or show conn detail
command and watch the idle timer increament once it reaches 30 the connection will NOT close
ciscoasa# show conn detail
flags U, idle 2s, uptime 1m3s, timeout 30s, bytes 0
Connection is still live and
every 30secs the idels timer
resets to 0
Also have a look at the Policy Map output
ciscoasa# show service-policy interface outside
Interface outside:
Class-map: CM_HTTP
Set connection policy: drop 0
idle 0:00:30
DCD: enabled, retry-interval 0:00:15, max-retries 5
=================output omitted for Brevity===================
NOTE: DCD will send probes for retry_interval seconds. If no response is received from the
devices, the probes are then resent for max_retries times. At this point If there is no response, the
connection is automatically closed.
Step 5: The embryonic-conn-max and per-client-embryonic-max options limit TCP connections
that are only partially open.
ciscoasa(config-pmap-c)# set connection embryonic-conn-max 2000
ciscoasa(config-pmap-c)# set connection per-client-embryonic-max 500
Step 6: An ASA can also apply the following two connection controls that are not related to
connection volume or limits:
TTL decrementing
Randomize initial sequence number
ASAs do not decrement the TTL value of packets that pass through it by default. Since the TTL
value is not changed by the ASA the ASA invisible as a routed hop.
If you want the ASA to uncloak itself and decrement the TTL value you configure the value below
ciscoasa(config-pmap-c)# set connection decrement-ttl
If you want to see the TTL of the packet moving through the ASA you could run thi s command
although it is not advisable in a real world scenario: USE WITH CAUTUON
ciscoasa(config)# capture PACKET type raw-data real-time detail
Step 5: A an TCP connection will negiciate initial sequence number (ISN) that is used as a starting
point to determine the TCP connection sequence numbers.
The ISN is generally a random number to make TCP spoofing attacks more difficult. In the real worl
ISN can be predicted based on the behaviour of certain host TCP stacks.
ASAs will select random ISN for evey new TCP connection. ISN generation will occurs only for
connections that are initiated from secure interfaces ASA.
Since the ASA steps in to randomise the ISN it can cause problems with some TCP connections
such as authentication or hash code based on TCP packets as they leave a device
Changing the ISN will cuase authentication to fail
Disable the random ISN generation on an ASA below
ciscoasa(config-pmap-c)# set connection random-sequence-number disable
Step 6: Verification basic TCP tuning parameters
To verify the configured connection settings use the following command.
ciscoasa(config-pmap-c)# sho service-policy interface outside
Interface outside:
Class-map: CM_HTTP
Set connection policy: random-sequence-number disable
drop 0
idle 0:00:30
DCD: enabled, retry-interval 0:00:15, max-retries 5
Set connection decrement-ttl
==================output omitted for Brevity=====================
Part 4: Inspecting BGP - TCP Parameters with the TCP Normalizer
FastEthernet 0/0
192.168.2.1/24
ASA Outside
Eth0/0
192.168.2.2 /24
ASA Inside
Eth0/1
10.0.0.1 /24
ASA
R2
Fa0/0
10.0.0.1 /24 R1
BGP
PEERING
An ASA can inspect individual TCP segments to ensure TCP protocol specification conformity.
Any TCP segments which to not conform are normalized so that they do conform. You can use the
TCP normalizer to prevent malformed packets or packets that are crafted to evade stateful
inspection from reaching protected hosts.
The TCP normalizer has lots of parameters that you can defined in a TCP map. Once the TCP map
have been created you can employ it through the MPF by matching traffic with a class map and
then referencing the TCP map in the set connection advanced-options tcpmap command under a
policy map.
Step 1: Begin configuring the TCP normalizer by defining a TCP Map, under this map you will
configure the following TCP normalizer actions.
a. Checksum-verification = Verify TCP checksum; drop the packet if it fails.
b. ttl-evasion-protection = This feature looks for packets that have a shorter than normal TTL,
where an attacker might be creating a short TTL that is allowed through the appliance, but
dropped between it and a destination device by an intermediate router because the TTL has
expired.
ciscoasa(config)# tcp-map NORMALISE_TCP
ciscoasa(config-tcp-map)# checksum-verification
ciscoasa(config-tcp-map)# ttl-evasion-protection
ciscoasa(config-tcp-map)# urgent-flag allow
Note: TTL evasion protection is enabled by default (the ttl-evasion-protection command).
Do not disable this command it you want to prevent attacks that attempt to evade security policy.
For example, an attacker can send a packet that passes policy with a very short TTL. When the TTL
goes to zero, a router between the ASA and the endpoint drops the packet. It is at this point that
the attacker can send a malicious packet with a long TTL that appears to the ASA to be a
retransmission and is passed. To the endpoint host, however, it is the first packet that has been
received by the attacker. In this case, an attacker is able to succeed without security preventing the
attack
Note: urgent-flag allow Sets the action for packets with the URG flag. The URG flag is used to
indicate that the packet contains information that is of higher priority than other data within the
stream. The TCP RFC is vague about the exact interpretation of the URG flag, therefore end
systems handle urgent offsets in different ways, which may make the end system vulnerable to
attacks.
The allow keyword allows packets with the URG flag. (Default) The clear keyword clears the URG
flag and allows the packet.
Step 2: Configure BGP on R1
R1(config)# ip routing
R1(config)# router bgp 1
R1(config-router)# neighbor 192.168.2.1 remote-as 10
R1(config-router)# neighbor 192.168.2.1 ebgp-multihop 2
R1(config-router)# exit
R1(config)# ip route 192.168.2.0 255.255.255.0 10.0.0.1
Step 3: Configure BGP on R2
R2(config-router)# neighbor 10.0.0.1 remote-as 1
R2(config-router)# neighbor 10.0.0.1 ebgp-multihop 2
Do not use a default route
or the bgp neighbors will
never establish
Step 4: Verify on the Routers and the ASA
ciscoasa# sho conn
And on R1
R1# sho ip bgp summary
BGP router identifier 10.0.0.10, local AS number 1
BGP table version is 1, main routing table version 1
Neighbor V AS MsgRcvd MsgSent TblVer InQ OutQ Up/Down State/PfxRcd
192.168.2.1 4 10 11 8 1 0 0 00:00:15 0
Step 5: Next apply password protection to the BGP sessions. Once the password protection has
been applied you will start receving error messages on the console
On R1
R1(config-router)# neighbor 192.168.2.1 password PASSWORD
On R2
R2(config-router)# neighbor 10.0.0.10 password PASSWORD
Once the password protection has been applied you will start receving error messages on the
console stating that there is no MD5 digest in the received bgp packet
%TCP-6-BADAUTH: No MD5 digest from 192.168.2.1(179) to 10.0.0.10(34057)
A number here, any
number here means
the connect is up
Step 6: When two peers attempt to establish a BGP peering session with MD5 authentication the
ASA rewrites any TCP MD5 option included on a TCP datagram that goes through the device and
replaces the option kind, size and value with NOP option bytes. This effectively breaks BGP MD5
authentication, and results in error messages like this on each peering router:
In order for a BGP session with MD5 authentication to be successfully established, these two issues
must be resolved:
Disable TCP sequence number randomization
Disable TCP MD5 option rewriting
The TCP normalizer can also inspect the contents of the TCP options field to make sure
that they conform to limits you set in the TCP map
a. tcp-options range = Check to see whether the TCP option numbers are within the specified
range; if so, take action. (Default: Clear all TCP option numbers except 2, 3, 4, 5, and 8.)
A class-map and an access-list are used to select the traffic between the peers that must both be
exempted from the TCP sequence number randomization feature and allowed to carry an MD5
option without rewriting.
In the configuration below you will configure an ACL called ALLOW-BGP which match against BGP
packets (TCP port 179) between peers in both directions, the peers being 10.0.0.10 and
192.168.2.1 (An inside BGP speaker and an outside BGP speaker)
ciscoasa(config)# access-list ALLOW-BGP extended permit tcp host 192.168.2.1 eq bgp host
10.0.0.10
ciscoasa(config)# access-list ALLOW-BGP extended permit tcp host 192.168.2.1 host 10.0.0.10
eq bgp
ciscoasa(config)# access-list ALLOW-BGP extended permit tcp host 10.0.0.10 host 192.168.2.1
eq bgp
Step 7: The TCP map TCP-BGP allows option 19 to remain intact, go back into the tcp-map. Option
19 is used by the routers to negociate the MD5 hash value, if the ASA clears this field the BGP
peers will establish and adjencency.
ciscoasa(config)# tcp-map NORMALISE_TCP
ciscoasa(config-tcp-map)# tcp-options range 19 19 allow
Step 8: Next Create a class map called CM_BGP which will references the access list to match the
BGP traffic.
ciscoasa(config)# class-map CM_BGP
ciscoasa(config-cmap)# match access-list ALLOW-BGP
Step 9: Go back into the policy map PM_POLICY_MAP which you will use to reference the class
map to match the traffic and leverages the TCP normalizer through the TCP map.
ciscoasa(config-pmap)# class CM_BGP
ciscoasa(config-pmap-c)# set connection advanced-options NORMALISE_TCP
Note: This example will apply the TCP normalization to the traffic which is match by the class map
CM_BGP.
At this point you will start getting the following message on R2, This message Is simply stating that
the MD5 hash it is receiving is invalid meaning that R1 and R2 to not agree on the MD5 hash. This
is down to the ASA randomising the ISN in the BGP packet
%TCP-6-BADAUTH: Invalid MD5 digest from 10.0.0.10(43957) to 192.168.2.1(179)
Step 10: Once again to into the policy map and configure the ASA not to randomise the ISN
ciscoasa(config-pmap)# class CM_BGP
ciscoasa(config-pmap-c)# set connection random-sequence-number disable
Step 11: Verify the the BGP speakers have formed a peering.
R1# sho ip bgp summary
BGP router identifier 10.0.0.10, local AS number 1
BGP table version is 1, main routing table version 1
Neighbor V AS MsgRcvd MsgSent TblVer InQ OutQ Up/Down State/PfxRcd
192.168.2.1 4 10 19 17 1 0 0 00:00:08 0
Step 12: To verify the TCP Normalisation run the command sho service-policy interface outside
Step 13: End of lab clean up
ciscoasa(config)# no service-policy PM_POLICY_MAP interface outside
ciscoasa(config)# no policy-map PM_POLICY_MAP
ciscoasa(config)# no class-map CM_BGP
ciscoasa(config)# no class-map CM_ICMP
ciscoasa(config)# no class-map CM_DNS
ciscoasa(config)# no class-map CM_HTTP
ciscoasa(config)# no class-map CM_HTTPS
ciscoasa(config)# no tcp-map NORMALISE_TCP
ciscoasa(config)# clear configure access-list
A number here, any
number here means
the connect is up
Part 5: Configuring a Policy for Inspecting OSI Layers 57
The ASA has the ability to inspect application traffic at OSI Layers 5 through 7.
The ASA can analyze, verify and limit various aspects of the application traffic. The ASA perform
the can the four functions listed in below as part of its application inspection and control (AIC)
features.
Function Focus Strength
Protocol
verification
Drops malformed application
layer packets
Blocks covertly tunneled data
Prevents known and unknown
attacks
Protocol
minimization
Minimal set of protocol
features
Hides unnecessary features
and their
Vulnerabilities
Prevents both known and
unknown
attacks
Payload
minimization
Minimal set of protocol
payloads
Permits only expected content
Prevents both known and
unknown
attacks
Application layer
signatures
Detects malicious content Prevents mostly known attacks
Configuring HTTP Inspection Policy Maps and URL filtering Using the CLI
In general clients will send HTTP requests and servers respond with sending back HTTP
responses. An ASA can inspect the HTTP traffic and apply granular controls or security policies
In this lab you will use the CLI to configure an HTTP inspection policy map that is applied to the
HTTP inspector process.
You will use the following steps to build and apply an HTTP inspection policy map:
A. Define the HTTP inspection policy map.
B. Configure HTTP protocol verification.
C. Configure a minimization or signature detection, along with an action.
D. Apply the HTTP inspection policy map.
Step 1: Define the HTTP Inspection Policy Map and Configure HTTP Protocol Verification
You can use the following commands to verify that HTTP connections are conforming to the
protocol norms. The ASA can drop, log, or reset violating connections.
ciscoasa(config)# policy-map type inspect http HTTP_IPM_1
ciscoasa(config-pmap)# parameters
ciscoasa(config-pmap-p)# protocol-violation action drop-connection log
ciscoasa(config-pmap-p)# exit
WARNING: The above protocol violation check can break a lot of connections, so use with caution
Step 2: Configure a Minimization or Signature Detection, Along with an Action
The ASA supports protocol or payload minimization or HTTP signature by choosing a matching
criteria and entering the corresponding command.
The match command will match the parameters you select, while the match not command will
match against anything other than the parameters you enter.
Inspection policies can be build up by configuring multiple match and action pairs in a single HTTP
inspection policy map.
Matches are not tried in the order in which they are configured, the ASA has an internal mechanism
that it employs, for example. If a match command drops or resets an HTTP connection, then no
more matches are checked. Otherwise, a HTTP packet can be matched by subsequent match
commands in the policy map.
Continuing with the configuration from Step 1, add a security policy to minimize the HTTP protocol.
In this configuration only the HTTP request GET method will be permitted, other request methods
are be dropped.
ciscoasa(config-pmap-p)# match not request method get
ciscoasa(config-pmap-c)# drop-connection
Step 4: An inspection policy map can be made up of match-action pairsa single match command
and a corresponding action in each pair. In some cases, you might need to match multiple
conditions for a single action. You can achieve this by defining an HTTP inspect class map that
contains multiple matching conditions,
Define a class map called HTTP_CM that will be used to ultimately drop any HTTP connection that
is neither an HTTP GET request HTTP HEAD or HTTP POLL request
ciscoasa(config)# class-map type inspect http match-all HTTP_CM
ciscoasa(config-cmap)# match not request method get
ciscoasa(config-cmap)# match not request method poll
ciscoasa(config-cmap)# match not request method head
Note: HTTP Head asks for the response identical to the one that would correspond to a GET
request, but without the response body. This is useful for retrieving meta-information written in
response headers, without having to transport the entire content.
Step 5: Matching URLs with Regular Expressions
A class map can be configured with of one or multiple match regex commands, each one
referencing a one regular expression configured with the regex command.
Regex Command Guidelines:
1. Max Number of Characters 100
2. Match text literally
3. Use Meta Characters such as ( ) , ? , | , *. + , {n}
Configure a HTTP inspection policy that minimizes the HTTP payload by blocking anything under
cisco.com and urls that contain "/wiki/". We will create the regexes and match them in a class-map.
Configure the Regexs first in global config mode
ciscoasa(config)# regex HACKER-URl-1 "/wiki/"
ciscoasa(config)# regex HACKER-URl-2 "cisco\.com"
Next create the Class-maps to match the regexs
ciscoasa(config)# class-map type inspect http match-any BLOCK_URL_CLASS
ciscoasa(config-cmap)# match request uri regex HACKER-URl-1
ciscoasa(config-cmap)# match request header host regex HACKER-URl-2
Configure the Policy maps to call the Classmap above
ciscoasa(config)# policy-map type inspect http HTTP_IPM_1
ciscoasa(config-pmap-p)# class BLOCK_URL_CLASS
ciscoasa(config-pmap-c)# drop-connection log
Step 6: Testing your Regular Expressions
You can test a regular expression from the EXEC level prompt
Enter the regular expression you want to test. If the input text or regular expression contains any
spaces, be sure to surround the text string with quotation marks.
ciscoasa# test regex http://www.commsupport.co.uk/wiki /wiki
INFO: Regular expression match succeeded.
And
ciscoasa# test regex www.cisco.com cisco\.com
Step 7: Apply the HTTP Inspection Policy Map
After you configure an HTTP inspection policy map, you apply it to an HTTP inspection within a
service policy rule.
ciscoasa(config)# policy-map global_policy
ciscoasa(config-pmap)# class inspection_default
ciscoasa(config-pmap-c)# inspect http HTTP_IPM_1
Note: The following error ERROR: Multiple inspect commands cant be configured for a class
without match default-inspection-traffic|none in it. means that an inspect rule already exists
under this class.
Step 8: Open a browser window and go to any site and most probably you will be denied access
ciscoasa# sho service-policy global
Warning: Before you consider implementing any of the application layer inspection features, you
need to take the time to collect information about the applications used in your network so you can
understand the possible disruption that changes to the inspection might have on your network. Do
not start configuring Application inspection unless you have tested the configuring in depth and are
positive it will not break anything or leave you network wide open.
Step 9: To fix you will need to examine each entry in turn and determining if any single one
command is affecting your connections. In this case we have an issue with the protocol violations
entry, so in you go and remove this entry
ciscoasa(config-cmap)# policy-map type inspect http HTTP_IPM_1
ciscoasa(config-pmap-p)# protocol-violation action log
Once this setting has been set to log try browsing the web again, it ought to be successful
Step 10: Testing the url filtering
Go to google and type in cheese, one of the first links to appear will be for Wikipedia where the url
will have the word wiki present, click on this link, it ought to fail.
Next test is to go to Cisco website, this too ought to fail
Step 11: End of Lab clean up
ciscoasa(config-pmap-c)# no inspect http HTTP_IPM_1
ciscoasa(config-pmap-c)# end
ciscoasa(config)# no policy-map type inspect http HTTP_IPM_1
ciscoasa(config)# no class-map type inspect http match-any BLOCK_URL_CLASS
ciscoasa(config)# no class-map type inspect http match-all HTTP_CM
ciscoasa(config)# no class-map CM_ACL
ciscoasa(config)# clear configure access-list IN-TO-OUT
Part 6: Selective URL filtering
In this part you will configure the ASA to allow 10.0.0.10 access any website and all other users to
be blocked from specific websites.
Note: Is important that you understand the URL filtering in the previous example to be able to follow
the process of this example
Step 1: This access-list (IN-TO-OUT) will match all the users with the exception of the ones that
need unrestricted access.
ciscoasa(config)# access-list IN-TO-OUT extended deny tcp host 10.0.0.10 any eq www
ciscoasa(config)# access-list IN-TO-OUT extended permit tcp any any eq www
Step 2: Create the regex to match cisco.com OR uri containing "/wiki/")
ciscoasa(config)# regex DENY-URL1 "/wiki/"
ciscoasa(config)# regex DENY-URL2 "cisco\.com"
Step 3: Testing your Regular Expressions
You can test a regular expression from the EXEC level prompt
Enter the regular expression you want to test. If the input text or regular expression contains any
spaces, be sure to surround the text string with quotation marks.
ciscoasa# test regex http://www.commsupport.co.uk/wiki /wiki
And
ciscoasa# test regex www.cisco.com cisco\.com
Step 4a: Create two new Class maps, the first one will be a type inspect called MATCH-URL-CM
It will be matching the to regexs from step 2, which will in turn be matched in a separate policy-map
called MATCH-URL-PM
ciscoasa(config)# class-map type inspect http match-any MATCH-URL-CM
ciscoasa(config-cmap)# match request uri regex DENY-URL1
ciscoasa(config-cmap)# match request header host regex DENY-URL2
Step 4b: The second class map will be regular one called MATCH-USER-CM, this class map will
match the ACLs created in step 1. This class map will be used in a separate policy-map MATCH-
USER-URL-PM
ciscoasa(config-cmap)# class-map MATCH-USER-CM
ciscoasa(config-cmap)# match access-list IN-TO-OUT
Step 5: The Class Map configured in Step 4 which is matching the regexes will be matched in a
policy-map called MATCH-URL-PM
In a separate policy map MATCH-USER-URL-PM you will match class map MATCH-USER-CM
and it is this policy-map that the http inspection for the allowed websites policy-map MATCH-URL-
PM is taking place
The MATCH-USER-URL-PM will be applied to an interface with a service-policy. What this policy-
map is actually doing is to match on all the users except the unrestricted ones (class MATCH-
USER-CM) and block them from going to the specified websites.
ciscoasa(config)# policy-map type inspect http MATCH-URL-PM
ciscoasa(config-pmap-p)# class MATCH-URL-CM
ciscoasa(config-pmap-c)# drop-connection
ciscoasa(config-pmap-c)# policy-map MATCH-USER-URL-PM
ciscoasa(config-pmap)# class MATCH-USER-CM
ciscoasa(config-pmap-c)# inspect http MATCH-URL-PM
ciscoasa(config-pmap-c)# service-policy MATCH-USER-URL-PM interface inside
Step 6: Verification.
From your inside host browse the web, in particular wikis or cisco sites, this ought to be permitted.
Change the IP address of your corporate server to 10.0.0.11 and attempt to browse the same sites,
you will find that this will be denied
Step 7: End of Lab Clean up
ciscoasa(config)# no service-policy MATCH-USER-URL-PM interface inside
ciscoasa(config)# no policy-map MATCH-USER-URL-PM
ciscoasa(config)# no policy-map type inspect http MATCH-URL-PM
ciscoasa(config)# no policy-map type inspect http PM_MATCH_HTTP_URL
ciscoasa(config)# no class-map type inspect http match-any MATCH-URL-CM
ciscoasa(config)# no class-map MATCH-USER-CM
ciscoasa(config)# clear configure access-list IN-TO-OUT
ciscoasa(config)# no regex DENY-URL1 "/wiki/"
ciscoasa(config)# no regex DENY-URL2 "cisco\.com"
Intentionally Blank
SECTION 5: TRANSPARENT FIREWALL
Topology Diagram
Border_X Inside
FastEthernet 0/0
192.168.2.1/24
Border_X Outside
Fastethernet 0/1
192.168.1.1x /24
ASA Outside
Security 0
Eth0/0
BVI GROUP 1
ASA Inside
Security 100
Eth0/1
BVI GROUP 1
Corporate Server
IP: 192.168.2.100 /24
Default GW: 192.168.2.1
Ip route 0.0.0.0 0.0.0.0 192.168.1.254
Ip route 172.17.17.0 255.255.255.0 fa0/1
Border_X
R2
192.168.1.254 /24
Towards Internet or
192.168.1.10
route outside 0.0.0.0 0.0.0.0 192.168.2.1
BVI 1
192.168.2.10/24 VLAN 16
Fa0/1
Fa0/6
SW1
SW1
Fa0/7
Fa0/2
Vlan 27
Internet Server
192.168.1.2x /24
Default Gateway:
192.168.1.1X
SW2
All ports in Vlan 1
Fa0/2
Fa0/10
VLAN 1
R1
F0/0
Transparent Firewall
This Section will cover:
a. Setting up the Transparent Firewall
b. Configuring NAT in Transparent Mode
c. Configuring ACLs in Transparent Mode
d. Configuring Ether Type ACLs
e. Configuring ARP inspection
f. Modifying L2F Table Parameters
Task 1: Configure SW1 and SW2
NOTE: This task maybe skipped If you are using a virtual environment, go to Task 2
Step 1: Configure Switch SW1. Please enter the required housekeeping commands
SW1# reload
SW1# conf t
Step 2: Configure the Connection between R1 and the inside interface of the ASA
Step 3: On SW1 Configure the Connection between R2 and the outside interface of the ASA
SW1(config)# int fas 0/2
SW1(config-if)# int fas 0/7
Step 4: Configure Switch SW2. Please enter the required housekeeping commands
SW2# reload
switch# conf t
Step 5: Configure the Connection between R2 and the outside world, Fa0/10 leads to the class
gateway to the internet.
Task 2: Configure the Corporate Server
Router(config)# line con 0
Router(config-line)# logging sync
router(config-line)# exec-time 0 0
router(config-line)# exit
router(config)# hostname CORP_S
CORP_S(config)# no ip domain lookup
CORP_S(config)# no service timestamp
CORP_S(config)# int fa0/1
CORP_S(config-if)# ip address 192.168.2.100 255.255.255.0
CORP_S(config-if)# no shut
CORP_S(config-if)# no ip routing
CORP_S(config)# ip default-gate 192.168.2.1
CORP_S(config)# end
CORP_S# wri
Task 3: Configure the Border Router (R2)
Step 1: House keeping first
Router# conf t
Router(config)# line con 0
Router(config-line)# logging sync
Router(config-line)# exec-time 0 0
Router(config-line)# exit
Step 2: Configure Fa0/0 as the inside interface. Note that this interface will be the default gateway
for the Corporate server on the inside of the ASA
Border_x(config)# int fa0/0
Step 3: Configure Fa0/1 on R2 to be the outside interface and place a static default route pointing
to the class gateway
Border_x(config)# int fas 0/1
Border_x(config-if)# ip address 192.168.1.1x 255.255.255.0
Step 4: Configure NAT on R2 to translate traffic from 192.168.2.0/24, 192.168.1.0/24 and
172.17.17.0/24.
Border_x(config)# ip access-list extend FOR_NAT
Border_x(config-ext-nacl)# permit ip 192.168.1.0 0.0.0.255 any
Border_x(config-ext-nacl)# exit
Border_x(config)#
Border_x(config)# ip nat source list FOR_NAT interface fa0/1 overload
Step 5: Place a route on R2 to send all traffic with the destination address of 172.17.17.0/24 (i.e.
the returning traffic) back towards the ASA. This static route must specify the next hop as the local
outbound interface on R2
Border_x(config)# ip route 172.17.17.0 255.255.255.0 fa0/0
Note: 172.17.17.0/24 will be the subnet that you will translate inside ASA traffic to.
Step 6: Test R2s connectivety to the Internet
Border_x# ping 8.8.8.8
Sending 5, 100-byte ICMP Echos to 8.8.8.8, timeout is 2 seconds:
.!!!!
Success rate is 80 percent (4/5), round-trip min/avg/max = 20/21/24 ms
Task 4: Clear the ASA firewall
Please make sure that you pay close attention to the commands and the questions asked, make
notes and ask question, if there is some concept you do not understand please ask the instructor.
The first part of this lab requires that you clear all configurations from the ASA in your lab.
NOTE: At any point during the lab x represents your lab number if you are using the physical racks
in the classroom.
asa>enable
Password:
asa#write erase
[OK]
asa#reload
[OK]
below.
Task 5: Configure the ASA in Transparent Firewall mode
In this task you will configure the ASA in Transparent firewall mode.
Step 1: Enable Transparent Firewalls
You can change the default routed mode to transparent mode by using the firewall transparent
command.
WARNING: Even though you can convert the ASA to firewall mode either through a Telnet/SSH
connection or through a console connection it is wiser to carry out the process through the console
connection since you will lose network connectivity and will not be able to access the ASA through
Telnet or SSH once the mode has been changes
ciscoasa# conf t
ciscoasa(config)# firewall transparent
ciscoasa(config)# show firewall
Firewall mode: Transparent
ciscoasa(config)#
When you change the mode the ASA will wipe the running configuration as most of the routed mode
commands are not compatible in transparent mode.
If you issue a show run on the ASA you will note that the device is clean and the hostname is reset
to ciscoasa. There is no need to reset the ASA after you switch firewall modes.
To get back to the routered mode issue the no firewall transparent command. If you want to save
the transparent firewall configuration then simply save the configuration in The running configuration
is saved as transparent.cfg in disk0. To save the config you would issue the command.
ciscoasa# copy running-config disk0:/transparent.cfg
Source filename [running-config]?
Destination filename [transparent.cfg]?
Cryptochecksum: 345ab54 27f3d6971 54ab675
2231 bytes copied in 4.230 secs
Step 2: Set Up Interfaces
After you turn on the transparent firewall on the ASA, you have to define the inside and outside
interfaces and also you have to assign security levels on each of the interfaces.
Below you will configure the inside interface with security level 100, and the outside interface with
security level 0. By default, all interfaces are in the shutdown state, which you can enable by using
the no shutdown command.
ciscoasa(config)# interface eth0/1
INFO: Security level for "outside" set to 0 by default.
Note You cannot use ASDM until the interfaces are ready to pass traffic and the global/
management IP address is configured on the security appliance.
Note If the security appliance is configured to accept ASDM client connections and the IP
connectivity exists between the client and the ASA, you can navigate to Configuration > Device
Setup > Interface and modify the interfaces accordingly.
Step 3: Configure an IP Address
Unlike routed mode, the ASA in transparent mode does not allow you to configure IP addresses on
the physical or sub-interfaces. Instead the IP address is assigned under and new interface called a
BVI (Bridged Virtual Interface) this is used for management purposes, such as SSH, Telnet, ASDM,
SNMP traps and polling, AAA, and ARP resolution.
The transparent mode allows you to assign an IP address to a bvi interface. As below, an IP
address of 192.168.2.10/24 is configured for the Bvi interface. Configure the bvi interface below
onto your ASA.
ciscoasa# configure terminal
ciscoasa(config)# interface bvi 1
In the ASA IOS Versions 8.2 and prior it was possible to configure an IP address in global mode like
in the example below.
ciscoasa(config)# ip address 192.168.2.10 255.255.255.0
Note In an MMTF, (Multiple Mode Transparent Mode) an IP address must be configured for each
context.
Note Configuring an IP address from ASDM is useful if you have the security appliance in
multimode so that you can change contexts and assign global addresses for each context.
This is an example only
do NOT configure this
command
Step 4: Assign both inside and outside interfaces to BVI group 1. This is similair to how bridging is
carried out on an IOS router
ciscoasa(config-if)# bridge-group 1
ciscoasa(config)#
ciscoasa(config-if)# bridge-group 1
ciscoasa(config)#
Step 5: Setting up Routing on the ASA
The default gateway of the transparent firewall is typically the downstream router toward the inside
interface. The ASA sends traffic to the default gateway for the networks that it does not know about.
For example when you connect to the ASDM from the a network other than 192.168.2.0/24 the ASA
will simply pass it up to R2.
NOTE: The ASA will continue to pass traffic from inside to outside without the default route, this
route is simply for the ASAs own packets
Step 6: In this step we will allow ICMP traffic to transit the ASA and be inspected so that the return
ICMP traffic is permitted to enter, once this is done issue a ping from your Corp_Server (R1) to
192.168.2.1 address on the outside side interface of the ASA, the pings ought to be successful.
ciscoasa(config-pmap-c)# inspect icmp
ciscoasa(config-pmap-c)# end
ciscoasa# wri
Step 7: Verify the Mac Address table of the ASA, you ought to see the MAC address of the
Border_x router that is connected to the outside interface of the ASA and the MAC address of the
Corporate server
ciscoasa# show mac-address-table
interface mac address type Age(min)
------------------------------------------------------------------
inside xxxx.xxxx.xxxx dynamic 5
outside yyyy.yyyy.yyyy dynamic 5
Step 8: Test connectivity from the corporate server to the internet thorough the Transparent Firewall
by telneting to 192.168.2.1 on Port 80
CORP_S# telnet 192.168.2.1 80
Trying 192.168.2.1, 80 ... Open
qwerty
HTTP/1.1 400 Bad Request
Date: Sat, 16 Nov 2013 20:29:14 GMT
Server: cisco-IOS
Accept-Ranges: none
400 Bad Request
[Connection to 192.168.2.1 closed by foreign host]
CORP_S#
Step 9: Test Internet access to the Internet Server by ping 8.8.8.8 from Corp_Server (R1)
(If no internet access exists use the following address of 192.168.2.1)
MAC addresses of the
inside and outside devices
Type anything you like to get a
response. Your connection will
be automatically disconnected
Part 2: NAT Translation in Transparent Firewall
When the translated address is in the same subnet/network as the global IP address, the ASA
replies to ARP requests for the translated address.
Interface PAT (static or dynamic) is not supported because there is no IP address on the physical
interface of the security appliance.
The use of the alias command is not supported in transparent firewall mode.
If the translated address is not on the same network as the global IP address of the ASA, you
must add a static route on the upstream router (In this network that would be R2) for the translated
address or network. R2s next-hop IP address of the static route back to 172.17.17.0/24 would point
to a downstream router (R1 if it were acting as a residing behind the inside interface of the firewall).
NOTE: In our network R2 has a static route for 172.17.17.0/24 with the next hop set to its own local
outbound interface Fa0/1. The operation of this route will be explained later in the Proxy Arp
Section
You have to define static routes on the ASA if the original IP address/network is one or multiple
hops away from the ASA. The ASA does a route lookup rather than a MAC address lookup when
address translation is in use.
If a host on one side of the firewall ARPs for a host on the other side of the firewall, and the
original IP address of the initiating host is translated to an address on the same network, then the
ASA does not perform ARP inspection. This means that the original IP address may be exposed to
the outside network.
NOTE: In the Pre-7.2(1) releases of the ASA software, address translation was not supported in
transparent firewalls.
TASK 1: DYNAMIC NAT
Step 1: In this task we will use Dynamic NAT to translate the inside address to an external IP
address of 172.17.17.x/24.
The first task is to enable the HTTP server and trust the source of the HTTP traffic this is required if
you wish to perform the following tasks using the ASDM.
Step 2: Enter the following commands to configure dynamic NAT on the ASA to translate all traffic
from the inside subnet of 192.168.2.0/24 to the address range of 172.17.17.1 through to
172.17.17.100
ciscoasa(config)# object network DYNAMIC-OUT
ciscoasa(config-network-object)# range 172.17.17.1 172.17.17.100
ciscoasa(config)# nat (inside,outside) 1 source dynamic any DYNAMIC-OUT
Step 2 (ASDM Optional): Complete the following substeps to configure dynamic NAT for the inside
network via the ASDM
1. Go to Configure > Firewall > NAT rules panel, click Add
2. Choose Add Rule Before Network Object NAT Rule from the add menu. The Add
NAT Rule window opens
3. Choose inside from the Source interface drop-down list in the Original Packet area
4. Choose outside from the Destination interface drop-down list in the Original Packet
area
5. Leave the Destination Address field in the Original Packet area to any
6. In the Action: Translated Packet area choose Dynamic in the drop down Source NAT
Type field
7. In the Source Address field in the Action: Translated Packet area click on the click the
browse button choose an existing network object or group or create a new object or
group from the Browse Original Source Address dialog box, here you will create a new
Object group.
a. Click Add
b. In the Add Network Object enter the following details
NAME: DYNAMIC-OUT
TYPE: RANGE
START ADDRESS: 172.17.17.1
END ADDRESS: 172.17.17.100
c. Click OK and then OK again, and the name DYNAMIC-OUT will appear in the
Source Address field
8. Click Apply in the NAT Rules panel
Step 3: This step Is just in the event that the pings are not making it through R2 run the commands
below. The access-list needs to be added to recognise the traffic that has been translated by the
ASA so that the router can again translate the traffic coming from the corporate server.
The router will need to know too how to route the traffic back to the origin of the 172.17.17.0/24
traffic. We enter a static route on the router with the next hop going out of the local interface
Border_x# conf t
Border_x(config)# access-list 100 permit 172.17.17.0 0.0.0.255 any
Border_x(config)# ip route 172.17.17.0 255.255.255.0 fa0/0
Issue a ping from the corporate server, you ought to receive a reply, verify that the router is
translating the traffic correctly
Border_x#show ip nat nvi translations
Pro Inside global Inside local Outside local Outside global
icmp 192.168.1.1:1 172.17.17.57:1 192.168.1.100:1 192.168.1.100:1
Step 4: Verify the ASA xlate table, your display should appear similar to the following because a
global address chosen from the low end for the global pool range has been mapped to the
corporate server.
ciscoasa(config)# show xlate
e - extended
At the ASA look at the local host table. Notice that the display shows active connections on the
inside and the outside interfaces, the translation being used, and information about the current
connection.
ciscoasa(config)# show local-host 192.168.2.100
Interface mgmt: 0 active, 0 maximum active, 0 denied
Dynamic translation
local host: <192.168.2.100>,
Xlate:
Conn:
Ciscoasa# write memory
Cryptochecksum: 90c2435e 6fc1373b 18212ecb a02bbfed
[OK
Step 4: How many translation are in use in the translation table
ciscoasa# show xlate count
Flags: D - DNS, d - dump, I - identity, i - dynamic, n - no random,
r - portmap, s - static
NAT from inside:192.168.2.100 to outside:172.17.17.57 flags i
Step 5: Run the show conn command, do you see the i flag, this means incomplete TCP/UDP
connection.
S = awaiting inside SYN
U = Up
O = Outbound data
A = awaiting inside ACK to SYN
a = awaiting outside ACK to SYN
ciscoasa(config)# show conn
Step 6: Test Internet access to the Internet by pinging 8.8.8.8
Step 7: Use the show conn and the show xlate commands to observe the above connection. Do
you see the connections?
TASK 2: STATIC NAT
Step 1: Enter the following commands to configure Static NAT on the ASA to translate all traffic
from the inside host of 192.168.2.100/24 to the address of 172.17.17.200
ciscoasa(config)# object network STATIC-HOST
ciscoasa(config-network-object)# host
ciscoasa(config)# object network STATIC-OUTSIDE
Step 2: Create the NAT command which places create the Manual NAT command before the
Dynamic NAT statement in the previous exercise.
ciscoasa(config-network-object)#nat (inside,outside) 1 source static STATIC-HOST STATIC-
OUTSIDE
Step 3 (ASDM Optional): Complete the following substeps to configure Static NAT for the inside
host via the ASDM
9. Go to Configure > Firewall > NAT rules panel, click Add
10. Choose Add Rule Before Network Object NAT Rule from the add menu. The Add
NAT Rule window opens
11. Choose inside from the Source interface drop-down list in the Original Packet area
12. Choose outside from the Destination interface drop-down list in the Original Packet
area
13. Leave the Destination Address field in the Original Packet area to any
14. In the Action: Translated Packet area choose Dynamic in the drop down Source NAT
Type field
15. In the Source Address field in the Action: Translated Packet area click on the click the
browse button choose an existing network object or group or create a new object or
group from the Browse Original Source Address dialog box, here you will create a new
Object group.
a. Click Add
b. In the Add Network Object enter the following details
NAME: HOST-OUTSIDE
TYPE: HOST
START ADDRESS: 172.17.17.1
END ADDRESS: 172.17.17.100
c. Click OK and then OK again, and the name HOST-OUTSIDE will appear in the
Source Address field
16. Click Apply in the NAT Rules panel
Step 4: Test Internet access to the Internet by pinging 8.8.8.8 and repeating 10,000 times
Step 5: Verify the ASA xlate table. There ought to be a static entry.
ciscoasa# sho xlate
e - extended
NAT from inside:192.168.2.100 to outside:172.17.17.200
flags s idle 0:00:05 timeout 0:00:00
Step 6: At the ASA look at the local host table. Notice that the display shows active connections on
the inside and the outside interfaces, the translation being used, and information about the current
connection.
ciscoasa(config)# show local-host 192.168.2.100
local host: <192.168.2.100>,
Conn:
ICMP outside 8.8.8.8:0 inside 192.168.2.100:8, idle 0:00:00, bytes 1432
Static translation
Step 7: Take a look at R2 translation table. There ought to be an entry from 172.17.17.200
Border_x# sho ip nat nvi translations
Pro Source global Source local Destin local Destin global
icmp 192.168.1.1x:8 172.17.17.200:8 8.8.8.8:8 8.8.8.8:8
ciscoasa# write memory
Part 3: Configuring Access Control
Ethertype ACLs
ACLs in Transparent Firewall Mode can filter out IP packets by looking at various headers.
EtherType-based ACLs can be used to filter IP and non-IP-based traffic. Because the EtherType
ACLs can be used to analyze a frame at Layer 2, they behave differently from a typical extended
ACL. Consult the following guidelines when using the ACLs in your environment:
CDP PacketsThe ASA does not allow Cisco Discovery Protocol (CDP) packets to Transit
across it, not even if you permit CDP frames.
ARP PacketsBy deault ASA does not drop ARP packets in either direction to pass through..
With EtherType ACLs you can block ARP traffic. Other packets, like EIGRP, OSPF, BGP, DHCP,
RIP, BPDU, multicast, and MPLS packets, can be controlled by the EtherType ACL.
Note The ASA classifies DHCP, EIGRP, OSPF, Multicast streams, and RIP as special types. All
these types of traffic are considered connectionless and an extended access-list must be applied to
both interfaces to allow the traffic to pass
BPDUsCisco ASA does not forward BPDUs otherwise you cause bridging loops. Although with
Ethertypes BPDUs can pass through the ASA. If you have set up your ASA in failover mode you
will need to consider BPDUs.
Interaction with Extended ACLsEtherType ACL has an implicit deny at the end of it but this
implicit deny does not affect the IP traffic passing through the ASA.
It is possible to apply both EtherType and extended ACLs to each direction of an interface but i but
if you configure an explicit deny as the last statement at the end of an EtherType ACL it might deny
IP traffic even though an extended ACL is defined to allow the IP packets.
MPLSTo pass MPLS traffic through the ASA, you have to manually configure the router-id for
the TDP and LDP sessions. The router-id is be the IP address of the router interface that is
connected to the ASA
Note; The ASA supports only Ethernet II frames. The IEEE 802.3 frames contain a length field
instead of an EtherType code field and are not filtered by the EtherType ACLs.
The exception are BPDU frames, these are SNAP encapsulated but can still be matched by an
EtherType ACL.
Step 1: In this lab you will configure an ether type ACL to match all traffic with the Erhertype of
0x0800 which as you will know is that match IP. Once you have configured the ACL statements you
will apply it to the access group command in the inbound direction.
ciscoasa(config)# access-list ETHERTYPE_ACL ethertype deny 0x0800
ciscoasa(config)# access-list ETHERTYPE_ACL ethertype permit any
ciscoasa(config)# access-group ETHERTYPE_ACL in interface inside
Step 2: Send Pings from R1 to 8.8.8.8 or 192.168.2.1 if 8.8.8.8 is not available. These pings will not
be successful as all ICMP packets are carried in IP
Examine the ACL hit counter.
ciscoasa# sho access-list ETHERTYPE_ACL
access-list ETHERTYPE_ACL; 2 elements
access-list ETHERTYPE_ACL ethertype deny 800 (hitcount=31)
access-list ETHERTYPE_ACL ethertype permit any (hitcount=1)
Of course this is simply an example of how the Ethertype acls work, you can use them to match any
ethertype above 0x600 through to 0xffff. Also it is worth pointing out that you can have L3 ACLs
and Ethertype ACLs on the same interface at the same time.
Step 3: Remove the Ethertype ACLs from the ASA otherwise nothing IP will traverse the ASA.
ciscoasa(config)# no access-group ETHERTYPE_ACL in interface inside
ciscoasa(config)# no access-list ETHERTYPE_ACL ethertype permit any
ciscoasa(config)# no access-list ETHERTYPE_ACL ethertype deny 800
functions.
1. Permit any HTTP traffic
2. Permit any DNS traffic
3. Permit any HTTPS traffic
4. Deny outbound Telnet traffic
5. Permit any ICMP traffic
Step 1: Test web access to the Internet by opening telneting on R1 to 192.168.2.1 port 80.
Step 2: Test Telnet access to 192.168.2.1
Step 3: Complete the following substeps to create an access rule that permits all hosts on the
internal network to make outbound HTTP connections to any host
24. Click OK
Step 4: Complete the following substeps to create an access rule that allows host 192.168.2.100 on
the internal network to make outbound DNS requests to the internet
23. Enter udp/domain in the services field
24. Click OK
the internal network to make outbound HTTPS connections to the internet
7. Enter tcp/https in the services field
8. Click OK
Step 6: Complete the following substeps to create an access rule that Denies host 192.168.2.100
on the internal network to make outbound Telnet connections to 192.168.2.1
8. Click OK
Step 7: Complete the following substeps to create an access rule that permits host 192.168.2.100
on the internal network to make outbound Telnet connections to 192.168.1.254
8. Click OK
the internal network to send ICMP traffic
8. Click OK
the inside outbound, this statement is so that you may see the hit counts.
24. Click OK
Command line
access-list inside_access_in line 1 extended permit tcp 192.168.2.0 255.255.255.0 any eq http
access-list inside_access_in line 2 extended permit udp 192.168.2.0 255.255.255.0 any eq domain
access-list inside_access_in line 3 extended permit tcp 192.168.2.0 255.255.255.0 any eq https
access-list inside_access_in line 4 extended deny tcp 192.168.2.0 255.255.255.0 host 192.168.2.1
eq telnet
access-list inside_access_in line 5 extended permit tcp 192.168.2.0 255.255.255.0 host
192.168.1.254 eq telnet
access-list inside_access_in line 6 extended permit icmp 192.168.2.0 255.255.255.0 an
access-list inside_access_in line 7 extended deny ip any any
access-group inside_access_in in interface inside
Step 10: Test web access to the Internet by telneting from R1 to 192.168.2.1 port 80
Step 11: Test Telnet access to 192.168.2.1. This ought to be unsuccessful
Step 12: Test Telnet access to 192.168.1.254. This ought to be successful
Step 13: View your outbound ACL and look at the hit counts
ciscoasa# show access-list inside_access_in
access-list inside_access_in line 1 extended permit tcp 192.168.2.0 255.255.255.0 any eq www
(hitcnt=2) 0x3237aa23
access-list inside_access_in line 2 extended permit udp 192.168.2.0 255.255.255.0 any eq domain
(hitcnt=3) 0x132859c3
access-list inside_access_in line 3 extended permit tcp 192.168.2.0 255.255.255.0 any eq https
(hitcnt=15) 0x4d924445
access-list inside_access_in line 4 extended deny tcp 192.168.2.0 255.255.255.0 host 192.168.2.1
eq telnet (hitcnt=9) 0x27c2a8bb
access-list inside_access_in line 5 extended permit tcp 192.168.2.0 255.255.255.0 host
192.168.1.254 eq telnet (hitcnt=2) 0xaa2b5919
access-list inside_access_in line 6 extended permit icmp 192.168.2.0 255.255.255.0 any
(hitcnt=138) 0x940adf4a
LAB 2.1.4: Configure IP ARP inspection
Cisco ASA, deployed in transparent mode can prevent ARP spoofing attacks using called ARP
inspection
ARP Inspection looks at all the ARP packets both the reply and gratuitous ARPs before it will
forward them out of any interface.
The ASA will compare the Source Interface, the IP Address and the MAC address of the ARP
packets against the static entries in its ARP table.
By comparind the received ARPs to the local ARP it will be able to determine if there is a rogue
device attempted into spoof a legitimate device..
ARP inspection is disabled by default, and it can be enable on a per interface basis and it can also
be configured to flood the packet to other interfaces or drop the packet and generate a syslog..
When the Cisco ASA receives an ARP packet, it will check the packet against its local static ARP
table for a matc and takes one of the actions listed below:
If the MAC address matches and it finds a correct static ARP entry, it forwards the packet
If the MAC address matches against its local static ARP table but a mismatch either on the IP
address or the interface is detected, then the packet is dropped and may generate a syslog
message.
If the MAC address is not in the local static ARP table but the flood option is enabled, the ASA will
forwards the ARP out of the other interface.
If the MAC address is not in the static ARP table and the no-flood option is enabled, the packet is
dropped and generates a syslog message.
NOTE: The default behaviour for the ASA is to Flood the ARP packet.
With the ARP Inspection option enabled, all ARP packets are dropped unless they have a correct
static ARP entry defined. Therefore, the ASA must have all the ARP entries of all the hosts that
reside on that interface configured, this can lead to a lot of entires but it will make your network less
susceptible to attacks from ARP Spoofing.
Step 1: Change the MAC address on your Border_x router.
Warning if you have accessed the Web interface via this interface you will lose connectivity
Border_x(config-if)# mac-address 0001.aaaa.aaaa
Border_x# wri
Step 2: On the ASA you will now enable ARP inspection and enable it on the Outside interface
asa(config)# arp-inspection outside enable no-flood
You can define a static ARP entry in the ASDM by navigating to Configuration > Device
Management > Advanced > ARP > ARP Inspection, highlight the outside interface and clicking
the Edit option. And tick the Enable ARP Inspection box
Step 3: On the ASA enter the MAC address of the Border_x router on the outside interface.
asa(config)# arp outside 192.168.2.1 0001.aaaa.aaaa
.
You can define a static ARP entry in the ASDM by navigating to Configuration > Device
Management > Advanced > ARP > ARP Static Table, click the Add button
InterfaceSelect the interface to the outside interface from the drop-down list.
IP AddressSpecify the IP address of the host whose ARP entry is being defined, in this case
use 192.168.2.1
MAC AddressSpecify the MAC address of the host whose ARP entry is being defined. The
MAC address should be in 0001.aaaa.aaaa format.
Proxy ARPIn transparent mode, the security appliance does not utilize the proxy ARP feature
even if it is enabled, leave this unticked
Step 4: From R1 telnet to 192.168.2.1 this ought to work
Step 5: Next go back to the Border_x (R2) and change the mac address on Fa0/0 to
0000.bbbb.bbbb
Border_x(config-if)# mac-address 0001.bbbb.bbbb
Step 6: From R1 telnet to 192.168.2.1 this ought to fail
Step 7: To set ARP inspection back to the default on all interfaces, use clear configure arp-
inspection.
asa(config)# NO arp-inspection outside enable no-flood
asa(config)# NO arp outside 192.168.2.1 0001.aaaa.aaaa
Modify L2F Table Parameters
The default aging timer for the L2F table aging time can be changed from 5 minutes to a maximum
of 12 hours. Setting a higher aging timer for dynamically learnt entries allows the ASA to not age
hosts out so frequently.
Step 1: Configure the L2F table timer to 30 minutes
asa(config)# mac-address-table aging-time 30
Using ASDM, navigate to Configuration > Device Management > Advanced > Bridging > MAC
Address Table and specify timeout in minutes under the Dynamic Entry Timeout option.
Step 2: If your security policy does not allow the ASA to learn the L2F table dynamically on an
interface you can disable it using the command below.
asa(config)# mac-learn outside disable
Here you will disable the learning via ASDM by navigating to Configuration > Device Management
> Advanced > Bridging > MAC Learning highlight the outside interface and click disable
Step 3: Configure the static MAC address via the CLI enter the following command
asa(config)# mac-address-table static outside aaaa.bbbb.cccc
Define a static MAC address in the ASDM go to Configuration > Device Management >
Advanced > Bridging > MAC Address Table and enter the values entry for 0001.bbbb.bbbb
toward the outside and then apply
Note: You can also use the mac-learn disable command. After you disable the learning process on
an interface, you need to add static MAC address entries for the hosts toward that interface
ECTION 6: MULTI-CONTEXT
Border_X Inside
FastEthernet 0/1
192.168.2.1/24
Border_X Outside
Fastethernet 0/0
192.168.1.1x /24
Admin
Security 0
Eth0/0
192.168.2.252
Inside_CTX1
Security 100
Eth0/1
10.1.1.1
CXT1 Client
IP: 10.1.1.100 /24
Ip route 10.1.1.0 255.255.255.0 192.168.2.100
Ip route 20.1.1.0 255.255.255.0 192.168.2.200
Ip route 30.1.1.0 255.255.255.0 192.168.2.252
Ip route 0.0.0.0 0.0.0.0 192.168.1.254
ASA
Border_X - R2
192.168.1.254 /24
Outside_CXT1
Security 0
Eth0/0
192.168.2.100
CXT2 Client
IP: 20.1.1.100 /24
Inside_CTX2
Security 100
Eth0/2
20.1.1.1
ADMIN Client
IP: 30.1.1.100 /24
ADMIN
Security 100
Eth0/3
30.1.1.1
Outside_CXT2
Security 0
Eth0/0
192.168.2.200
Topology Diagram
SW1
Fa0/1 Fa0/4
Fa0/6 Fa0/12
SW1
Fa0/3
Fa0/13
SW1
Fa0/2
Fa0/7
VLAN 113
VLAN 27
VLAN 16 VLAN 412
SW2
Fa0/2
Fa0/10
R1
F0/0
R3
Fa0/0
R4
Fa0/0
Multiple Contexts
Task 1:
Please make sure that you pay close attention to the commands and the questions asked, make
notes and ask question, if there is some concept you do not understand please ask the instructor.
The first part of this lab requires that you clear all configurations from the ASA in your lab.
Clearing the configuration before starting on new labs is always a good idea, rather than
having to over write an existing configuration.
asa>enable
Password:
asa#write erase
[OK]
asa#reload
[OK]
***
*** --- START GRACEFUL SHUTDOWN ---
Shutting down File system
below.
Task 2: Assigning correct IP addressing to the Border Router R2
Step 1: Enter a host name on the Border_x router (Refer to the network diagram on the first page),
in this step you will also enter the command that stops console messages from interrupting your
input and the command that prevents typos from causing DNS name resolutions.
Router(config)#hostname Border_x
Border_x(config)#no ip domain-lookup
Border_x(config)#line con 0
Border_x(config-line)#logging synchronous
Border_x(config-line)#exit
this interface is the one which you will connect to the outside world
Border_x(config)#interface Fastethernet 0/1
Border_x(config)#description LINK_TO_OUTSIDE_WORLD
Border_x(config-if)#ip address 192.168.1.1X 255.255.255.0
At this point please type in no, if the prompt has
proceeded past this point then use the key
sequence control+z to come out of the setup
prompt
Border_x(config-if)#no shut
Border_x(config-if)#end
Border_x#copy run start
Step 3: Enter the correct interface modes and set the correct address on Border_x Fastethernet
0/01
Border_x(config)#interface Fastethernet 0/0
Border_x(config)#description LINK_TO_ASA
Border_x(config-if)#ip address 192.168.2.1 255.255.255.0
Border_x(config-if)#no shut
Border_x(config-if)#end
Border_x#copy run start
Task 3: NAT/PAT using the address of the interface
traffic coming from the inside network of the ASA.
Border_x#config t
Border_x(config)#access-list 100 permit ip 192.168.2.0 0.0.0.255 any
translate these inside addresses to the address on the interface and overload i.e PAT
Step 3: NAT must now be instructed as to which interfaces are facing the inside world in this lab the
inside is the fastthernet 0/0
Step 4: NAT must now be instructed as to which interfaces are facing the outside in this lab the
outside is the fastethernet 0/1
correct next hops
Border_x(config)#ip route 0.0.0.0 0.0.0.0 192.168.1.254
The fastethernet 0/0 interface in this
lab is the inside interface
The fastethernet0/1 interface in this lab
is the outside interface
Step 6: Now test the configuration. From R2you will need ping the following addresses:
Ping 1: Ping an outside machine, ask the instructor for this address, otherwise use the address
8.8.8.8 which is a Google DNS server, if you get a reply your internet connection is up
Ping 2: This time ping the Google DNS server once again but source it from the Fastethernet 0/0
interface.
Border_x# ping 8.8.8.8 source 192.168.2.1
This ping too ought to be successful, to verify that a translation has taken place run the following
command, since we are sourcing the traffic from the inside interface of the router we can be sure
that when traffic from the ASA hits the inside interface of the router that translation will take place
Border_x# show ip nat nvi translations
Pro Inside global Inside local Outside local Outside global
icmp 192.168.1.1x:1 192.168.2.1:1 X.X.X.X X.X.X.X
Lab : Configure the ASA in Multiple Context mode
Creating a virtual firewall enables a physical firewall to be logically partitioned into multiple firewalls.
Each standalone firewall will act independently with its own configuration, interfaces, security
policies, routing table, and administrators, these Virtual firewalls are also referred to as security
contexts.
The following are some example scenarios in which security contexts are useful in network
deployments:
A service provider providing firewall services to customers with each customer having their own
Firewall configuration.
Companies with different departments, and each department wants to implement its own
security policy.
Have a single physical Firewall Unit with multiple security contexts rather than multiple physical
devices with each one consuming power and rack space.
Architectural Overview
In a virtual firewall environment, the Cisco security appliance can be divided into three types:
A system execution space
An admin context
One or more user contexts (also known as User Defined Contexts)
NOTE: Contexts are independent virtual firewalls, but unless you configure the contexts correctly
one virtual firewall can affect the functionality and performance of another Virtual firewall on the
same box.
System Execution Space
This context is the place you go to create contexts, assign the interfaces, startup configuration files
and resources to the contexts.
The System execution space is also the place that you will configure other features such as failover,
and boot parameters.. The system execution space configuration resides in NVRAM area of the
ASA, but the configurations for USER security contexts are stored either in local Flash memory or
on a network storage server.
Admin Context
The admin context provides the administrator access to AAA or syslog servers. This is a very
powerful context and you would never allow access to this context as it can be used to access the
other contexts.
The Admin context is configured like any other Security Context. You must assign IP addresses to
the allocated interfaces just like you would with any other context.
Before you can go create any other context you must configure the Admin context first. Al so the
configuration has to reside on the local disk. If you want to designate a new admin context you can
by using the admin-context command.
When a Cisco ASA is converted from single mode to multi-mode, the network-related configuration
of the single-mode security appliance is saved as the admin context. The security appliance, by
default, names this context as admin.
Note: Changing the name of the admin context from admin is not recommended. The admin
context configuration is similar to a user context..
User Context
Each user context acts as a virtual firewall with its own configuration that contains nearly all the
options that are found in a standalone firewall. The number of user context is dependant on the
installed activation key.
Verifying the Number of Security Contexts
ciscoasa# show version | include Security Contexts
Objectives
In this activity you will configure the ASA in Multiple Context mode, for this lab to function you will
need to configure certain networking parameters.
Scenario: You are an ISP hosting provider, you have recently decided to provide managed firewall
services. You will host your customers servers in your racks and manage the firewall, but rather
than provide one individual Physical Cisco ASA firewall per customer you have decided to take
advantage of the Multiple Context feature on the ASA.
Step 1: Enable multiple security contexts globally.
The conversion process from single- to multiple-context mode must be done through the CLI. You
can start the conversion process either through a Telnet/SSH connection or through a console
connection. It is better to connect to the ASA via the Console initially, set up the configuration of the
Admin context then you can access the device via the SSH/Telnet interface.
ciscoasa> enable
Password:
ciscoasa# conf t
ciscoasa(config)# mode multiple
WARNING: This command will change the behavior of the device
WARNING: This command will initiate a Reboot
Proceed with change mode? [confirm]
Convert the system configuration? [confirm]
!
The old running configuration file will be written to flash
The admin context configuration will be written to flash
The old running configuration file will be written to flash
The admin context configuration will be written to flash
The new running configuration file was written to flash
Security context mode: multiple
***
*** --- SHUTDOWN NOW ---
***
*** Message to all terminals:
***
*** change mode
Process shutdown finished
Rebooting.....
Restarting system.
ciscoasa> enable
Password:
ciscoasa# show mode
Security context mode: multiple
ciscoasa#
After the appliance comes online, you can use show
mode to verify whether it is running in multiple mode.
Step 2: Set up the system execution space
To access the system execution space, do any one of the following:
Access via the console or the auxiliary port.
Log in to the admin context using SSH or Telnet, and then switch to the system execution
space.
Access through ASDM, using the IP address of an interface in the admin context.
Recall that the function of system execution space is to define and maintain the admin and user
contexts on the ASA.
If you manage the security appliances through the ASDM, navigate to Configuration > System >
Connect > Context Management > Security Contexts > Add. If using the CLI, you can add a
context by using the context command, followed by the name of the context under the configuration
mode.
Use the CLI to manage Cisco ASA, you will add two new contexts.. The security context name is
case sensitive, so double-check it when adding the contexts. The appliance takes you into the
context subconfiguration mode (config-ctx) to configure the necessary parameters.
In this step you will create two contexts named CXT1 and CXT2
ciscoasa# conf t
ciscoasa(config)# context ?
configure mode commands/options:
WORD Symbolic name of the context
ciscoasa(config)# context CXT1
Creating context CXT1... Done. (2)
ciscoasa(config-ctx)# EXIT
Creating context CXT2... Done. (3)
ciscoasa(config-ctx)# exit
ciscoasa(config)#
Step 3. Allocate the inside interfaces to the contexts
The next step is to allocate interfaces to each of the security contexts including the Admin context.
You can assign either a physical interface or a sub-interface to a security context.
Using ASDM, you can allocate one or multiple interfaces to a context in the Interface Allocation
section by clicking Add. Inerfaces can be assigned to new or existing contexts.
The security appliance, by default, displays the allocated interface as the interface ID in the context.
If you want to display the name for an interface instead of the interface ID, you can specify an alias
for that interface. This is extremely useful when you do not want the context administrator to find out
which physical interface is being used as the inside or the outside interface.
Using the CLI, you can assign interfaces to a context by entering into the context subconfiguration
mode and using the allocate-interface command
We will allocate interface Eth 0/1 to the Inside CXT1 and Eth0/2 to inside CXT2
ciscoasa# config
ciscoasa(config-ctx)# allocate-interface ethernet0/1 inside_CXT1 visible
ciscoasa(config-ctx)# context CXT2
ciscoasa(config-ctx)# allocate-interface ethernet0/2 inside_CXT2 visible
Step 4: Allocate the inside interfaces to the contexts
In this step you will give interface eth0/0 a description that can use to identify the eth0/0 for your
own documentation.
ciscoasa(config-subif)# description outside_CXT1_CXT2
Step 5: Allocate the OUTSIDE interfaces to the contexts
Next assign the outside interface to the individual contexts. If you were to execute a ? after the
allocate-interface you will see that there is no option to select an interface, you must know the
actual name of the interface you wish to assign to the particular context.
ciscoasa(config-ctx)# allocate-interface ethernet0/0 outside_CXT1 visible
ciscoasa(config-ctx)# allocate-interface ethernet0/0 outside_CXT2 visible
Step 6: Specify a configuration URL
The configuration URL, referred to as Config URL, specifies the location of the startup configuration
for each context.
The configured contexts (either admin or customer) are not active unless there is a configuration
URL. The supported storage locations include the local disk and a network drive that uses the
HTTP, HTTPS, FTP, or TFTP protocol.
After a configuration URL is specified, ASA attempts to retrieve the configuration from that location.
If the configuration file is not found the ASA will create a configuration file with the default settings.
The ASA saves the configuration of these security contexts when either write memory or copy
running-config startup-config is issued from within the security context.
NOTE: The ASA also saves the configuration files of all security contexts when write memory all is
issued from the system execution space.
In this exercise the two new security contexts, called CXT1 and CXT2 need their disk locations to
be created. The config URL for the newly defined security context, using the CLI, is as shown in the
steps below. After a configuration URL is added, you are ready to configure that virtual firewall by
changing into it the context.
ciscoasa# conf t
ciscoasa(config-ctx)# config-url disk0:/CXT1.cfg
WARNING: Could not fetch the URL disk0:/CXT1.cfg
INFO: Creating context with default config
ciscoasa(config-ctx)# config-url disk0:/CXT2.cfg
WARNING: Could not fetch the URL disk0:/CXT2.cfg
INFO: Creating context with default config
ciscoasa(config-ctx)#
Step 7: Configure an admin context
The Admin context is created by the Cisco ASA automatically, if you convert it from single to
multiple mode and you answer Yes to Convert the System Configuration?.
To manage an admin context, or any other user context, navigate to Configuration > Context >
Admin (or a user context) > Connect. Using the CLI, you can log in to the admin context by typing
the changeto context command, followed by the name of the context.
You can log in to the admin context called admin from the system context.
Before you designate a context as the admin context, it has to meet two requirements:
The config-url must point to a file in the local disk
The context must be predefined and have a config-url.
.
ciscoasa> en
ciscoasa# conf t
ciscoasa(config)# context admin
ciscoasa(config-ctx)# allocate-interface eth0/3
ciscoasa(config-ctx)# allocate-interface eth0/0
ciscoasa(config)# changeto context admin
Run the show interface ip brief command to view the status of the interfaces in the Admin context
ciscoasa/admin(config)# show int ip brief
Interface IP-Address OK? Method Status Protocol
Ethernet0/3 unassigned YES unset up up
Ethernet0/0 unassigned YES unset up up
Within the admin context enter the interface eth0/3 configuration mode and enter the following
details
ciscoasa/admin(config)# interface Ethernet0/3
ciscoasa/admin(config-if)# ip address 30.1.1.1 255.255.255.0
ciscoasa/admin(config-if)# nameif inside
ciscoasa/admin(config-if)# security-level 100
ciscoasa/admin(config-if)# no shut
ciscoasa/admin(config-if)# exit
Within the admin context enter the interface eth0/0 configuration mode and enter the following
details
ciscoasa/admin(config)# interface Ethernet0/0
ciscoasa/admin(config-if)# ip address 192.168.2.252 255.255.255.0
ciscoasa/admin(config-if)# nameif outside
INFO: Security level for outside set to 0 by default.
Ciscoasa/admin(config-if)# security-level 0
Within the admin context enable the http server and accept it to trust http connections from any ip
address.
ciscoasa/admin(config-if)# exit
ciscoasa/admin(config)# http server enable
ciscoasa/admin(config)# http 0.0.0.0 0.0.0.0 outside
ciscoasa/admin(config-if)# end
Now check the state of the interfaces once they have been configured. You ought to see that the ip
addresses have been applied and the states are up.
ciscoasa/admin# show interface ip brief
Ethernet0/3 30.1.1.1 YES manual up up
Ethernet0/0 192.168.2.252 YES manual up up
ciscoasa/admin #
Step 8: Configure user context CXT2
Any context that is not designated as the admin context is referred to as a user context. You can log
in to a user context through ASDM by navigating to Configuration > Contexts > <user context
name> and then clicking the Connect button.
Once again it is useful to check the state of the interfaces that have been associated to the CXT2
context, neither interface has any ip addresses applied but both of the interfaces are in the up/up
state.
ciscoasa(config)# changeto context CXT2
ciscoasa/CXT2(config)# show interface ip brief
inside_CXT2 unassigned YES unset up up
outside_CTX2 unassigned YES unset up up
Within the CTX2 context enter the interface outside_CTX2 configuration mode and enter the
following details
ciscoasa/CXT2(config)# interface outside_CXT2
ciscoasa/CXT2(config-if)# ip address 192.168.2.200 255.255.255.0
ciscoasa/CXT2(config-if)# security-level 0
ciscoasa/CXT2(config-if)# nameif outside
ciscoasa/CXT2(config-if)# exit
Within the CTX2 context enter the interface inside_CXT2 configuration mode and enter the following
details
ciscoasa/CXT2(config)# interface inside_CXT2
ciscoasa/CXT2(config-if)# nameif inside
ciscoasa/CXT2(config-if)# no shut
Within the CXT2 context enable the http server and accept it to trust http connections from any ip
address.
ciscoasa/CXT2(config)# http server enable
ciscoasa/CXT2(config)# http 0.0.0.0 0.0.0.0 outside
ciscoasa/CXT2(config)# http 0.0.0.0 0.0.0.0 inside
ciscoasa/CXT2(config)# exit
Have a go at pinging the outside interface on CXT2 on the ASA, you ought to receive 100 success
(or so) on the pings, of course this interface must be up.
ciscoasa/CXT2# ping 192.168.2.200
!!!!!
Step 9: Configure user context CXT1
Again it is useful to check the state of the interfaces that have been associated to the CXT1 context,
neither interface has any ip addresses applied but both of the interfaces are in the up/up state.
ciscoasa/CXT1(config)# show interface ip brief
inside_CXT1 unassigned YES unset up up
outside_CTX1 unassigned YES unset up up
Within the CXT1 context enter the interface outside_CXT1 configuration mode and enter the
following details
ciscoasa/CXT1(config)# interface outside_CXT1
ciscoasa/CXT1(config-if)# nameif outside
INFO: Security level for "outside" set to 0 by default.
Within the CXT1 context enter the interface inside_CXT1 configuration mode and enter the following
details
ciscoasa/CXT1(config)# interface inside_CXT1
ciscoasa/CXT1(config-if)# nameif inside
ciscoasa/CXT1(config-if)# no shut
Within the CXT1 context enable the http server and accept it to trust http connections from any IP
address.
ciscoasa/CXT1(config)# http server enable
ciscoasa/CXT1(config)# http 0.0.0.0 0.0.0.0 outside
ciscoasa/CXT1(config)# http 0.0.0.0 0.0.0.0 inside
ciscoasa/CXT1(config)# exit
Within CXT1 check that both of the interfaces have had the ip addresses assigned
ciscoasa/CXT1# show int ip brief
inside_CXT1 10.1.1.1 YES manual up up
outside_CTX1 192.168.2.100 YES manual up up
Next from the ASA ping the two outside interfaces on the ASA, both of these interfaces ought to
reply with 100% success.
!!!!!
!!!!!
Part 1: NAT configuration
Step 1: Configure Dynamic NAT on CXT1
The next important step is to configure NAT on the ASA, this is done in exactly the same way as
configuring NAT on the ASA in single mode, below the commands go through setting up dynamic
NAT in CTX1, notice that the pools in both the contexts are within the same subnet.
ciscoasa# conf t
ciscoasa/CXT1(config)# object network CXT1-INSIDE
ciscoasa/CXT1(config-network-object)# subnet 10.1.1.0 255.255.255.0
ciscoasa/CXT1(config-network-object)# exit
ciscoasa/CXT1(config)# nat (inside,outside) 1 source dynamic CXT1-INSIDE interface
ciscoasa/CXT1(config)#logout
ciscoasa/CXT1# exit
Logoff
ciscoasa>
Step 2: Configure Dynamic NAT on CXT2
ciscoasa# conf t
ciscoasa/CXT2(config)# object network CXT2-INSIDE
ciscoasa/CXT2(config-network-object)# subnet 20.1.1.0 255.255.255.0
ciscoasa/CXT2(config-network-object)# exit
ciscoasa/CXT2(config)# nat (inside,outside) 1 source dynamic CXT2-INSIDE interface
ciscoasa/CXT2(config)#logout
ciscoasa/CXT2# exit
Logoff
ciscoasa>
From R1, R3 and R4 which are acting as hosts within each context try to ping 8.8.8.8. We have not
configured NAT for the Admin context, have a go at that, you will also have to figure out the routing
for each context.
CXT1 HOST ADDRESS:
IP ADDRESS: 10.1.1.100
SUBNET MASK: 255.255.255.0
IP GATEWAY: 10.1.1.1
CXT2 HOST ADDRESS:
SUBNET MASK: 255.255.255.0
ADMIN HOST ADDRESS:
SUBNET MASK: 255.255.255.0
Intentionally Blank
SECTION 7: Active Standby Failover
Lab 7: FailoverTopology Diagram
PRIMARY
SECONDARY
Eth0/0
192.168.2.11/24
Eth0/1
10.0.0.11/24
Eth0/3
172.16.1.1
vlan 100
Fa0/0
192.168.2.1/24
BORDER
R2
Fa0/1
192.168.1.1x /24
IP: 10.0.0.100/24
GW: 10.0.0.11
Fa0/7
Fa0/6
Fa0/9
Fa0/8
SW1
SW1
R1
vlan 200
Fa0/1
Fa0/2
Eth0/0
192.168.2.12/24
Eth0/1
10.0.0.12/24
Eth0/3
172.16.1.2
SW2
Fa0/2 Fa0/10
PART 1: R2 configuration
Task 1: Configuring IP addresses on Ethernet interfaces
Step 1: Erase any existing configuration from all of the Devices
Clearing configurations before starting on new labs is always a good idea, rather than having to
over write an existing configuration.
Rz_x>enable
Rz_x#erase startup-config
Rz_x#reload
Step 2: When the routers finally boot you will be presented with an output that resembles the one
below.
--- System Configuration Dialog ---
Would you like to enter the initial configuration dialog? [yes/no]:no
Task 2: Log into R2 and Assign the correct IP addresses
Step 1: Enter a host name on R2 the Border_x, in this step you will also enter the command that
stops console messages from interrupting your input and the command that prevents typos from
causing DNS name resolutions.
Router(config)# hostname Border_x
Border_x(config)# no ip domain-lookup
Border_x(config)# line con 0
Border_x(config-line)# logging synchronous
Border_x(config-line)# exit
this interface is the one which you will connect to the outside world.
Border_x(config)# description LINK_TO_OUTSIDE_WORLD
Border_x(config-if)# ip address 192.168.1.1X 255.255.255.0
Border_x(config)# interface Fastethernet 0/0
Border_x(config)# description LINK_TO_ASA
X is your Lab Number, if in doubt ask your instructor
Task 3: NAT/PAT using the address of the interface
traffic coming from the inside network of the ASA, the DMZ (To be configured) and traffic from the
ASA
Border_x# config t
Border_x (config)# access-list 100 permit ip 192.168.2.0 0.0.0.255 any
Border_x (config)# access-list 100 permit ip 192.168.1.0 0.0.0.255 192.168.2.0 0.0.0.255
translate these inside addresses to the address on the interface and overload i.e PAT, the
reversible command allows the inbound traffic to be translated too
Step 3: NAT must now be instructed as to which interfaces are facing the outside world in this lab
the outside is the fastthernet 0/1
Step 4: NAT must now be instructed as to which interfaces are facing the inside in this lab the
inside is the fastethernet 0/0, but in this lab you will be allowing traffic from the outside to come in to
the inside part of the network so you will use the ip nat enable command
correct next hops
The fastethernet 0/1 interface in
this lab is the outside interface
On the inside interface use the
enable command
Part 2: Switch Configuration
SW1 Initial configuration and device management
Step 1: Erase start and reload SW_1 and SW_2 prior to commencing the configuration
Ports 2 , 7 and 9 are the outside interfaces on SW1, these ports have to be placed into VLAN 200
switch# conf t
switch(config)# hostname SW_1
SW_1(config)# int range fas 0/2 , fa0/7 , fa0/9
SW_1(config-if-range)# switchport mode access
SW_1(config-if-range)# spanning-tree portfast
SW_1(config-if-range)# switchport access vlan 200
SW_1(config-if-range)# exit
Ports 1 , 6 and 8 are the inside interfaces on SW1, these ports have to be placed into VLAN 100
SW_1(config)# int range fas 0/1 , fa0/6 , fa0/8
SW_1(config-if-range)# switchport mode access
SW_1(config-if-range)# spanning-tree portfast
SW_1(config-if-range)# switchport access vlan 100
SW_1(config-if-range)# exit
The spanning tree protocol on SW1 must be set to Rapid PVST
SW_1(config)# spanning-tree mode rapid pvst
SW_1(config)# end
SW_1# wri mem
[OK]
SW2 Initial configuration and device management
SW2# reload
switch# conf t
Step 2: Configure the Connection between R2 and the outside world, Fa0/10 leads to the internet.
Part 3: ASA Configuration
The first part of this lab requires that you clear all configuration from the ASA in your lab.
Clearing the configuration before starting on new labs is always a good idea, rather than having to
over write an existing configuration.
asa>enable
Password:
asa#write erase
[OK]
asa# conf t
asa(config# no firewall transparent
asa(config# mode single
asa#reload
[OK]
below.
Pre-configure Firewall now through interactive prompts [yes]? No
Part 4: Initialise the Primary security appliance
Step 1: In this next task you will configure the Primary ASA with the correct IP addresses and
prepare the Primary ASA to accept connections to the ASDM.
inside, when the Primary ASA sees this particular name being applied to an interface it will
automatically assign the interface the highest security level of 100. Even so you will enter the
security level of the interface manually. Apply the IP address of 10.0.0.11/24 to the eth0/1 interface
and then bring it live.
ciscoasa> enable
Password:
ciscoasa# conf t
ciscoasa(config-if)# ip address 10.0.0.11 255.255.255.0 standby 10.0.0.12
Primary ASA acts as web server to process the requests from the clients and therefore you must
enable the web server on the Primary ASA with the http server enable command.
ciscoasa(config)# http 10.0.0.0 255.255.255.0 inside
Step 3: In this step you will configure the Primary ASA with the correct IP address on the outside
interface
Go to the Ethernet 0/0 interface and setting the name on the interface, the name will be outside,
when the Primary ASA
Step 4: Create a route on the Primary ASA to send all traffic to the Border router
Step 5: Assign a hostname to the Primary router
ciscoasa(config)# hostname PRIMARY
Step 6: Configure the inspect engine to allow icmp through the firewall
PRIMARY# conf t
PRIMARY(config)# policy-map global_policy
PRIMARY(config-pmap)# class inspection_default
PRIMARY(config-pmap-c)# inspect icmp
PRIMARY(config-pmap-c)# end
PRIMARY# wri
Part 5: Initialise the Secondary security appliance
Step 1: In this next task you will configure the Secondary ASA with the correct IP addresses and
prepare the Secondary ASA to accept connections to the ASDM.
inside, when the Secondary ASA sees this particular name being applied to an interface it will
automatically assign the interface the highest security level of 100. Even so you will enter the
security level of the interface manually. Apply the IP address of 10.0.0.12/24 to the eth0/1 interface
and then bring it live.
ciscoasa> enable
Password:
ciscoasa# conf t
Secondary ASA acts as web server to process the requests from the clients and therefore you
must enable the web server on the Secondary ASA with the http server enable command.
ciscoasa(config)# http 10.0.0.0 255.255.255.0 inside
Step 3: In this step you will configure the Secondary ASA with the correct IP address on the
outside interface
Go to the Ethernet 0/0 interface and setting the name on the interface, the name will be outside,
on the Secondary ASA
Step 4: Create a route on the Primary ASA to send all traffic to the Border router
Step 5: Assign a hostname to the Secondary router
ciscoasa(config)# hostname SECONDARY
Active/Standby Failover Overview
Active/Standby failover enables you to use a standby ASA to take over the functionality of a failed
unit. When the active unit fails, it changes to the standby state while the standby unit changes to the
active state. The unit that becomes active assumes the IP addresses (or, for transparent firewall,
the management IP address) and MAC addresses of the failed unit and begins passing traffic.
The unit that is now in standby state takes over the standby IP addresses and MAC addresses.
Because network devices see no change in the MAC to IP address pairing, no ARP entries change
or time out anywhere on the network.
Primary/Secondary Status and Active/Standby Status
The main differences between the two units in a failover pair are related to which unit is active and
which unit is standby, namely which IP addresses to use and which unit actively passes traffic.
However, a few differences exist between the units based on which unit is primary (as specified in
the configuration) and which unit is secondary:
The primary unit always becomes the active unit if both units start up at the same time (and are
of equal operational health).
The primary unit MAC addresses are always coupled with the active IP addresses. The
exception to this rule occurs when the secondary unit is active and cannot obtain the primary unit
MAC addresses over the failover link. In this case, the secondary unit MAC addresses are used.
Device Initialization and Configuration Synchronization
Configuration synchronization occurs when one or both devices in the failover pair boot.
Configurations are always synchronized from the active unit to the standby unit. When the standby
unit completes its initial startup, it clears its running configuration (except for the failover commands
needed to communicate with the active unit), and the active unit sends its entire configuration to the
standby unit.
The active unit is determined by the following:
If a unit boots and detects a peer already running as active, it becomes the standby unit.
If a unit boots and does not detect a peer, it becomes the active unit.
If both units boot simultaneously, then the primary unit becomes the active unit, and the
secondary unit becomes the standby unit.
Note Standby Failover does not replicate the following files and configuration components:
AnyConnect images
CSD images
ASA images
AnyConnect profiles
Local Certificate Authorities (CA)
ASDM images
Prerequisites for Active/Standby Failover
Active/Standby failover has the following prerequisites:
Both units must be identical ASAs that are connected to each other through a dedicated failover
link and, optionally, a Stateful Failover link.
Both units must have the same software configuration and the proper license.
Both units must be in the same mode (single or multiple, transparent or routed).
Configure the Primary Unit
Step 1: Designates the unit as the primary unit.
PRIMARY(config)# failover lan unit primary
Step 2: Specify the interface to be used as the failover interface. This interface should not be used
for any other purpose (except, optionally, the Stateful Failover link).
PRIMARY(config)# failover lan interface FAIL_OVER_LINK eth0/3
INFO: Non-failover interface config is cleared on Ethernet0/3 and its sub-interfaces
Note Although you can use an EtherChannel as a failover or state link, to prevent out-of-order
packets, only one interface in the EtherChannel is used. If that interface fails, then the next interface
in the EtherChannel is used. You cannot alter the EtherChannel configuration while it is in use as a
failover link. To alter the configuration, you need to either shut down the EtherChannel while you
make changes, or temporarily disable failover; either action prevents failover from occurring for the
duration.
Step 3: Assigns the active and standby IP addresses to the failover link. You can assign either an
IPv4 or an IPv6 address to the interface. You cannot assign both types of addresses to the failover
link.
PRIMARY(config)# failover interface ip FAIL_OVER_LINK 172.16.1.1 255.255.255.0 standby
172.16.1.2
The standby IP address must be in the same subnet as the active IP address. You do not need to
identify the standby address subnet mask.
The failover link IP address and MAC address do not change at failover. The active IP address for
the failover link always stays with the primary unit, while the standby IP address stays with the
secondary unit.
Step 4: Enable the failover interface and enable failover globally
PRIMARY(config)# int eth0/3
PRIMARY(config-if)# no shut
PRIMARY(config-if)# exit
PRIMARY(config)# failover
PRIMARY(config)# end
PRIMARY# wri
Configure the Secondary Unit
Step 1: Assign the secondary role to the this unit, This step is optional because, by default, units
are designated as secondary unless previously configured
SECONDARY(config)# failover lan unit secondary
Step 2: Specify the interface to be used as the failover interface. This interface should not be used
for any other purpose (except, optionally, the Stateful Failover link).
SECONDARY(config)# failover lan interface FAIL_OVER_LINK eth0/3
Step 3: Assigns the active and standby IP addresses to the failover link. You can assign either an
IPv4 or an IPv6 address to the interface. You cannot assign both types of addresses to the failover
link.
SECONDARY(config)# failover interface ip FAIL_OVER_LINK 172.16.1.1 255.255.255.0 standby
172.16.1.2
Step 4: Enable the failover interface and enable failover globally, Enables failover. After you enable
failover, the active unit sends the configuration in running memory to the standby unit. As the
configuration synchronizes, the messages "Beginning configuration replication: Sending to mate"
and "End Configuration Replication to mate" appear on the active unit console.
SECONDARY(config)# int eth0/3
SECONDARY(config-if)# no shut
SECONDARY(config-if)# end
SECONDARY(config)# failover
SECONDARY(config)# end
SECONDARY# .
Detected an Active mate
Beginning configuration replication from mate.
End configuration replication from mate.
PRIMARY# wri
Step 5: Either on the Primary unit or the Secondary unit run the following command (The following
output was taken from the PRIMARY ACTIVE unit
PRIMARY# show failover
Failover On
Failover unit Primary
Failover LAN Interface: FAIL_OVER_LINK Ethernet0/3 (up)
Unit Poll frequency 1 seconds, holdtime 15 seconds
Interface Poll frequency 5 seconds, holdtime 25 seconds
Interface Policy 1
Monitored Interfaces 2 of 110 maximum
Version: Ours 8.4(3), Mate 8.4(3)
Last Failover at: 20:45:52 UTC June 1 2012
This host: Primary - Active
Active time: 702 (sec)
slot 1: empty
Other host: Secondary - Standby Ready
Active time: 0 (sec)
Step 6: From your Corporate host on the inside of your network send a continuous ping out to any
address past the Border router 8.8.8.8
Whilst the pings are in process go to the Active Primary device and enter the command to release it
role as active forwarder, pay attention to the pings and if you get any drops
PRIMARY# no failover active
PRIMARY#
Switching to Standby
PRIMARY#
This host is Active
This host is Standby
Did you lose any pings?, you may have lost one or maybe two but generally no pings would have
been lost in this exercise
View the status of the Primary device
PRIMARY# sho failover state
State Last Failure Reason Date/Time
This host - Primary
Standby Ready None
Other host - Secondary
Active None
====Configuration State===
Sync Done
====Communication State===
Mac set
Step 7: Whilst the pings are in process go to the Active Primary device and enter the command to
take back the role as active forwarder, pay attention to the pings and if you get any drops
PRIMARY# failover active
Switching to Active
PRIMARY#
Did you lose any pings?, you may have lost one or maybe two but generally no pings would have
been lost in this exercise
Primary is standby
Secondary is Active
View the status of the Primary device
PRIMARY# sho failover state
State Last Failure Reason Date/Time
This host - Primary
Active None
Other host - Secondary
Standby Ready None
====Configuration State===
Sync Done
====Communication State===
Mac set
Primary is Active
Secondary is standby
Configuring Stateful Failover
The stateful failover feature in the Cisco appliances replicates the state and translation tables from
the active unit to the standby unit. In the event of a failure, the standby unit becomes active and
begins passing traffic so that data flows are not disrupted. The stateful failover feature requires a
network connection between the two units to replicate the connection state information. The
appliances can use either a dedicated or the failover control interface to replicate the updates. You
can use the failover LAN interface if the stateful updates do not oversubscribe the interface
bandwidth. Set up a different interface for stateful failover if you are concerned about possibly
oversubscribing the failover control interface.
Step 1: Enter the Stateful failover on the primary along with the required IP addresses and unshut
eth0/2
PRIMARY(config)# failover link statelink ethernet0/2
PRIMARY(config)# failover interface ip statelink 172.16.2.1 255.255.255.0 standby
172.16.2.2
PRIMARY(config)# inter eth0/2
PRIMARY(config-if)# no shut
PRIMARY(config-if)# exit
The stateful failover does not replicate HTTP-based connections. HTTP connections usually have a
short lifetime and therefore are not replicated by default. Additionally, they add considerable load on
the security appliance if the amount of HTTP traffic is large in comparison to other traffic. If you want
to replicate the HTTP connections to the standby appliance, check the Enable HTTP Replication
option in ASDM. You can use failover replication http command via CLI
Step 2: Enter the command to replicate HTTP
PRIMARY(config)# failover replication http
PRIMARY(config)# wri
Step 3: Verify the failover settings on the Primary device
PRIMARY# sho failover interface
interface FAIL_OVER_LINK Ethernet0/3
System IP Address: 172.16.1.1 255.255.255.0
My IP Address : 172.16.1.1
Other IP Address : 172.16.1.2
interface statelink Ethernet0/2
System IP Address: 172.16.2.1 255.255.255.0
My IP Address : 172.16.2.1
Other IP Address : 172.16.2.2
Step 4: From the corporate device go to the BBC website and play the live news feed, when you
have the live news feed on the corporate device you can fail the Primary by switching the device off.
But make sure you have save the configuration.
Did you lose any traffic?

Firewall Manual

Загружено:

Сведения о документе

Авторское право

Доступные форматы

Поделиться этим документом

Поделиться или встроить документ

Параметры публикации

Этот документ был вам полезен?

Это неприемлемый материал?

Авторское право:

Доступные форматы

Firewall Manual

Загружено:

Авторское право:

Доступные форматы

ASA SECURITY FIREWALL

Copyright Commsupport Networks Ltd Page 2

Вам также может понравиться