Last week I had the opportunity to spend time with several CCIE security candidates in Texas, and had a blast. One of the questions that came up was regarding ARP inspection on the ASA in transparent mode. This topic comes up a lot, so I wanted to share it with y’all   in this blog.
Here is the diagram we can work with:

ARP inspection on the ASA in transparent mode, is really very simple. The intent is to stop attackers from spoofing the L2 address of another host, such as a default gateway or some other critical system. The ASA does this by verifying that all ARP traffic is accurate for the specific key devices you are protecting against spoofing.
As we already know, ARP packets are allowed through the ASA in transparent mode, in both directions, by default.
ARP inspection is NOT on by default, but we can enable it on one or both of the interfaces. When enabled, ARP traffic is checked against static ARP entries, if they have been configured, and that is the key: STATIC ARP ENTRIES MUST BE CONFIGURED.
A static ARP entry consists of 3 items: MAC address, IP address, and a single ASA interface.
If there are no static ARP entries, ARP packets are still allowed, just as if ARP inspection wasn’t even enabled. If we want to protect a default gateway, for example, from being spoofed, we could create a static entry just for the gateway, then any ARP packets attempting to spoof the gateway’s address would be denied at the ASA. Once we have created static ARP entries, any ARP packets seen by the ASA are checked against the static ARP entries regarding MAC address, IP address and ASA interface specified in the static ARP entry. If there is a conflict, then the ARP packet is dropped. If the ARP traffic exactly matches what is in the static ARP entry, then the ARP traffic is forwarded. If the ARP packet doesn’t match a static ARP entry (and doesn’t conflict with one either), and if the “FLOOD” option is used as part of the configuration for ARP inspection (which is the default if we leave the option off), the ARP traffic is forwarded. If the ARP packet doesn’t match any part of a static ARP entry and the “NO-FLOOD” option is used, then all ARP traffic not matching one of the static ARP entries configured is dropped .
Here are the relevant portions of the configuration on the ASA:

firewall transparent

hostname ASA1
interface Ethernet0/1
 no nameif
 no security-level
!
interface Ethernet0/1.210
 vlan 210
 nameif inside
 security-level 100
!
interface Ethernet0/1.310
 vlan 310
 nameif outside
 security-level 0

access-list free extended permit ip any any
access-list OSPF extended permit ospf any any 

ip address 23.0.0.10 255.255.255.0

access-group free in interface inside
access-group OSPF in interface outside

Here are the relevant portions of R2 and R3.  Notice that we hard-coded the mac addresses so that spotting them and knowing who they belong to will be super easy:

R2#
interface Loopback0
 ip address 2.2.2.2 255.255.255.0
!
interface FastEthernet0/0
 mac-address 0000.2222.2222
 ip address 23.0.0.2 255.255.255.0

router ospf 1
network 0.0.0.0 255.255.255.255 area 0
!

R3#
interface Loopback0
 ip address 3.3.3.3 255.255.255.0
!
interface FastEthernet0/0
 mac-address 0000.3333.3333
 ip address 23.0.0.3 255.255.255.0

router ospf 1
network 0.0.0.0 255.255.255.255 area 0

Before we enable ARP inspection on the ASA, lets verify basic connectivity between R2 and R3, and check out the ARP table on R2.

R2#ping 23.0.0.3

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 23.0.0.3, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 1/3/4 ms
R2#show ip arp
Protocol  Address          Age (min)  Hardware Addr   Type   Interface
Internet  23.0.0.2                -   0000.2222.2222  ARPA   FastEthernet0/0
Internet  23.0.0.3                0   0000.3333.3333  ARPA   FastEthernet0/0
R2#debug arp
ARP packet debugging is on
R2#clear arp
ARP: flushing ARP entries for all interfaces
IP ARP: sent rep src 23.0.0.2 0000.2222.2222,
                 dst 23.0.0.2 ffff.ffff.ffff FastEthernet0/0
IP ARP: sent req src 23.0.0.2 0000.2222.2222,
                 dst 23.0.0.3 0000.3333.3333 FastEthernet0/0
! Note:  We are receiving the ARP response from R3 below.
IP ARP: rcvd rep src 23.0.0.3 0000.3333.3333, dst 23.0.0.2 FastEthernet0/0
R2#

On the ASA, lets verify the default setting, which is ARP inspection being disabled.

ASA1(config)# show arp-inspection
interface                arp-inspection         miss
----------------------------------------------------
inside                   disabled                -
outside                  disabled                -

Now, lets enable ARP inspection on the ASA. We’ll enable it for both interfaces.

ASA1(config)# arp-inspection inside enable
ASA1(config)# arp-inspection outside enable

Let’s take a look at the show command that can assist us in verifying that it is configured.

ASA1(config)# show arp-inspection
interface                arp-inspection         miss
----------------------------------------------------
inside                   enabled                flood
outside                  enabled                flood
ASA1(config)#

Notice above, that the “miss” column is set to “flood”. This represents that if the ARP packet doesn’t match a static ARP entry, it will simply be forwarded through to the other interface, which is the default behavior for ARP traffic on the ASA in transparent mode.
We also can see, that with ARP inspection configured as above, that there is still no problem on R2 with ARP resolution to R3 through the ASA.

R2#clear arp
R2#
ARP: flushing ARP entries for all interfaces
IP ARP: sent rep src 23.0.0.2 0000.2222.2222,
                 dst 23.0.0.2 ffff.ffff.ffff FastEthernet0/0
IP ARP: sent req src 23.0.0.2 0000.2222.2222,
                 dst 23.0.0.3 0000.3333.3333 FastEthernet0/0

!   Note the received ARP response from R3 below.   ARP traffic is flowing!
IP ARP: rcvd rep src 23.0.0.3 0000.3333.3333, dst 23.0.0.2 FastEthernet0/0

And we still have the L3 connectivity as before, which we can verify with a PING.

R2#ping 23.0.0.3
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 23.0.0.3, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 1/3/4 ms
R2#

Now lets enable ARP inspection with the “no-flood” option. Remember, the no-flood option says to the ASA that if there is no static ARP entry that can be matched, just drop the ARP traffic.

ASA1(config)# arp-inspection outside enable no-flood
ASA1(config)# arp-inspection inside enable no-flood
ASA1(config)# show arp-inspection
interface                arp-inspection         miss
----------------------------------------------------
inside                   enabled                no-flood
outside                  enabled                no-flood
ASA1(config)#

Lets also take a look at the MAC address table. Even though the ASA knows which interface these devices live on based on its L2 table, with the no-flood for ARP inspection, all transit ARP packets will be denied unless they explicitly match a configured static ARP entry, (which we haven’t configured yet).

ASA1(config)# show mac-address-table
interface                   mac  address          type      Age(min)
------------------------------------------------------------------
outside                    0000.3333.3333          dynamic    5
inside                     0000.2222.2222          dynamic    5

Now lets test to see if R2 is still able to forward ARP traffic through the ASA. Warning: this may not be pretty.

R2#clear arp
ARP: flushing ARP entries for all interfaces
IP ARP: sent rep src 23.0.0.2 0000.2222.2222,
                 dst 23.0.0.2 ffff.ffff.ffff FastEthernet0/0
IP ARP: sent req src 23.0.0.2 0000.2222.2222,
                 dst 23.0.0.3 0000.3333.3333 FastEthernet0/0

! Notice, we did NOT get a ARP response back from R3 this time, as we did earlier.
! The AGE below of 5, represents the ARP refresh that happened 5 minutes ago.

R2#show arp
Protocol  Address          Age (min)  Hardware Addr   Type   Interface
Internet  23.0.0.2                -   0000.2222.2222  ARPA   FastEthernet0/0
Internet  23.0.0.3                5   0000.3333.3333  ARPA   FastEthernet0/0

!  R2 is still going for the ARP request, to refresh it’s ARP table.
!  We love that determination.

IP ARP: sent req src 23.0.0.2 0000.2222.2222,
                 dst 23.0.0.3 0000.3333.3333 FastEthernet0/0

! A couple more clear ARP commands, to speed it along.

R2#clear arp
IP ARP: sent req src 23.0.0.2 0000.2222.2222,
                 dst 23.0.0.3 0000.3333.3333 FastEthernet0/0
R2#clear arp
R2#
ARP: flushing ARP entries for all interfaces
IP ARP: sent rep src 23.0.0.2 0000.2222.2222,
                 dst 23.0.0.2 ffff.ffff.ffff FastEthernet0/0

! Finally, the aged ARP entry couldn’t be refreshed, and is gone.

R2#show arp
Protocol  Address          Age (min)  Hardware Addr   Type   Interface
Internet  23.0.0.2                -   0000.2222.2222  ARPA   FastEthernet0/0
R2#

Meanwhile, back at the ranch, the ASA was spitting out console messages saying:

%ASA-3-322003: ARP inspection check failed for arp request received from host 0000.2222.2222 on interface inside. This host is advertising MAC Address 0000.2222.2222 for IP Address 23.0.0.2, which is not bound to any MAC Address

Now, let’s create a static ARP entry for both R2 on the inside, and R3 on the outside. This would be important, because ARP inspection is still enabled on both interfaces with the no-flood option.

ASA1(config)# arp inside 23.0.0.2 0000.2222.2222
ASA1(config)# arp outside 23.0.0.3 0000.3333.3333

!  Note, we can also verify the entries with the command below.

ASA1(config)# show arp
        inside 23.0.0.2 0000.2222.2222 -
        outside 23.0.0.3 0000.3333.3333 -

Over on R2, lets test to see if R2 will be able to perform L3 to L2 resolution via ARP now that the ASA has static entries that should match.

R2#show arp
Protocol  Address          Age (min)  Hardware Addr   Type   Interface
Internet  23.0.0.2                -   0000.2222.2222  ARPA   FastEthernet0/0

! Note:  with the debug still on, lets initiate traffic that will trigger the ARP.

R2#ping 23.0.0.3
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 23.0.0.3, timeout is 2 seconds:
.!!!!
Success rate is 80 percent (4/5), round-trip min/avg/max = 1/3/4 ms
R2#
IP ARP: creating incomplete entry for IP address: 23.0.0.3 interface FastEthernet0/0
IP ARP: sent req src 23.0.0.2 0000.2222.2222,
                 dst 23.0.0.3 0000.0000.0000 FastEthernet0/0
! Note:  Payday.   Just below is the ARP response from R3, indicating R3 saw our request and
! was also able to send the ARP response back to us through the ASA.
IP ARP: rcvd rep src 23.0.0.3 0000.3333.3333, dst 23.0.0.2 FastEthernet0/0
R2#

We have verified that with the static ARP entries in place, that the ARP traffic is permitted through the firewall.
Thanks for joining me on a quick trip through ARP inspection on the ASA. There are tons more examples and practice labs in our SC Vol1 and Vol2 workbooks.
Happy studies,

It was a dark, cold night in late December, and Bob, (the optimistic firewall technician), had a single ASA to deploy before going home for the holidays.  The requirements for the firewall were simple.   Bob read them slowly as follows:

1. R1 should be able to ping the server “Radio.INE.com” by name.
2. PC should be able to ping the server “Radio.INE.com” by name.

Bob also read the background information to see if this was something he could finish before leaving the office.   Bob read the following:

DNS Server is mapping radio.ine.com to the global address of 136.1.122.100
All devices have appropriate routes in place.
R1 and the PC are both configured to use the DNS server at 136.1.122.2
DNS Server, PC, R1  and supporting L2 switchports for the ASA are configured correctly.
Bob also looked at the diagram:
Bob put the following together in notepad, and then quickly pasted it into the ASA using Secure CRT:
!************ begin ASA configuration ************
enable
conf  t
clear config all
no nat-control
hostname ASA1
interface Ethernet0/0
nameif outside
ip address 136.1.122.10 255.255.255.0
interface Ethernet0/1
nameif inside
ip address 172.16.16.10 255.255.255.0
interface Ethernet0/2
nameif dmz
ip address 10.0.0.10 255.255.255.0
nat (inside) 1 172.16.16.0 255.255.255.0
nat (dmz) 1 10.0.0.0 255.255.255.0
global (outside) 1 interface
access-list outside permit tcp any host 136.1.122.100 eq www
access-list outside permit icmp any host 136.1.122.100 echo
access-group outside in interface outside
static (dmz,outside) 136.1.122.100 10.0.0.100
wr
!************end ASA configuration*************
After waiting a few moments, Bob went to R1, issued the following command and hoped for the best:
Ping radio.INE.com
The ping failed.    He tried the same ping from the PC which also failed.    As much as Bob “hoped” it would work, it didn’t, and Bob secretly wished he had the skills and knowledge of a Security CCIE that would allow him to quickly solve the configuration problem so he could go home for the holidays.
My fellow CCIE bloggers and INE fans, your mission, should you choose to accept it, is to identify the missing and/or incorrect elements that need to be in place for successful pings to radio.ine.com from the PC and R1.
There is more than 1 way to solve this, and there are between 5 and 7 corrections that need to take place.
Will you assist BOB?

After returning from vacation, Bob (the optimistic firewall technician) decided that he wanted to take some time and get a little bit more familiar with firewall configuration. He was able to get permission to use some spare equipment for practice.


He started with a basic configuration on the firewall:

hostname INEASA1
password cisco
enable password cisco

interface e0/1
 nameif inside
 no shut
 ip address 172.16.16.10 255.255.255.0
 security-level 90

interface e0/0
 nameif outside
 ip address 136.1.122.10 255.255.255.0
 security-level 10
 no shut

Bob verified that he could ping both R1 and his PC from the Firewall. Now, he wants to configure the firewall to allow telnet from his PC. He remembers that there was some additional configuration that needed to be done on the firewall to allow this to work, but doesn’t remember exactly what is needed. Since his PC isn’t connected to the internet, he is not able to access the online documentation.
What additional configuration will allow Bob to telnet to the firewall from his PC?
There is more than one possible solution for this challenge. Feel free to post your proposed answer in the comments section. We will try to keep comments hidden from public view, so that the fun isn’t spoiled for others.
____
OK, so let’s look at the problem here. The PC is on the outside of the firewall, and according to multiple responses, you can’t telnet to the outside interface. (or can you?)
A few helpful hints when studying for the CCIE lab.
1. Don’t be afraid to go to the documentation, even for topics you think you know.
2 Re-read the question, to see just what you are asked to do and what your restrictions are.
So, where does the confusion about being able to telnet to the firewall come from? Perhaps it comes from trying in earlier versions, perhaps some confusion about what the documentation says, or perhaps someone read somewhere in the past that it just wouldn’t work.
Let’s start by carefully re-reading the documentation. ASA – Config guide – system administration – managing system access – allowing telnet
This section states:
“…The security appliance allows Telnet connections to the security appliance for management purposes. You cannot use Telnet to the lowest security interface unless you use Telnet inside an IPSec tunnel. …”
So, it doesn’t explicitly mention the outside, it mentions the “lowest security interface”. In most cases that is the outside, but not always.
A few “solutions”
1. Configure the switch so that Bob’s PC is on VLAN 121 instead of VLAN 122, configure the firewall to allow telnet on the inside interface. (Technically would meet requirements, but not much of a challenge.)
2. Change the security levels for the interfaces, making them the same or making the outside higher.
3. Add another interface with a lower security level
int eth0/1.1
vlan 123
nameif DMZ
sec 9
4. Configure a VPN for the firewall, so that the telnet traffic to the lower security (outside) interface is encrypted and therefore allowed.
5. Configure the firewall to allow transit traffic through to R1. Telnet to R1, and then Telnet to the ASA from R1, after configuring the ASA to allow telnet on the inside interface.

We all remember from the wireless section of CCENT that we need to update the firmware of our devices to ensure they are running as efficiently and reliabably as possible. This Training Simulation from the course walks you through the steps on a common Linksys router. Just click the link below to use the simulation and enjoy!

as promised before, we posted the initial update to our Security Workbook VOL1 matching new new CCIE Security v3.0 blueprint. It covers the “ASA Firewall” section of the lab exam blueprint and contains 50 technology focused mini-scenarios. All customers with active subscription to the existing version of IEWB-SC VOL1 should see the new material under their members site accounts. The new content has been rewritten from scratch, with the task wording changed along with breakdowns, comments and explanatins added. You will see the mini-labs presented in “challenging” format, matching our new philosophy for the updated line of CCIE products. Of course, there are new scenarios covering the updated CCIE Security lab blueprint. If you are wondering why we jumped from version 3.2 to v5.0, there are few good reasons. Firstly, it symbolizes the unified design philosophy of our RS and SC products as the most recent version of RS products is v5.0. Secondly, you should remember how they jumped to IPv6 from IPv4. We thought that’s a good idea too. And last, but not least – Cisco did the same trick to their line of unified communication products!
Finally, Here is the list of topics covered in this update. The highlighted topics correspond to the completely new scenarios added to the section. Notice however, that all other tasks have been completely updated as well! Happy studying!

ASA Firewall
VLANs and IP Addressing
RIPv2
OSPF
EIGRP
Advanced Routing
IP Access-Lists
Object Groups
Administrative Access
ICMP Traffic
URL Filtering
Dynamic NAT and PAT
Static NAT and PAT
Dynamic Policy NAT
Static Policy NAT and PAT
Identity NAT and NAT Exemption
Outside Dynamic NAT
DNS Doctoring using “Alias”
DNS Doctoring using “Static”
Fragmented Traffic
IDENT Issues
BGP across the Firewall
Stub Multicast Routing
PIM Multicast Routing
Network Time Protocol
System Logging
Filtering System Logs
SNMP Monitoring
DHCP Server
HTTP Traffic Inspection
FTP Traffic Inspection
SMTP Traffic Inspection
TCP Inspection
Management Traffic Inspection
ICMP Traffic Inspection
Threat Detection
Un-Stealthing the Firewall
Traffic Policing
Low Latency Queuing
Traffic Shaping
Hierarchical Queuing
Transparent Firewall
ARP Inspection
Ethertype Access-Lists
Transparent Firewall NAT
Firewall Contexts
Firewall Contexts Routing
Firewall Contexts Classification
Resource Management
Active/Standby Failover
Active/Active Failover

 Device Manager

I. IPS CLI

In this final part of our blog series on QoS with the PIX/ASA, we examine the remaining two tools that we find on some devices – traffic shaping and traffic policing.

Traffic Shaping

Traffic shaping on the security appliance allows the device to limit the flow of traffic. This mechanism will buffer traffic over the “speed limit” and attempt to send the traffic later. On the 7.x security device, traffic shaping must be applied to all outgoing traffic on a physical interface. Shaping cannot be configured for certain types of traffic. The shaped traffic will include traffic passing though the device, as well as traffic that is sourced from the device.
In order to configure traffic shaping, use the class-default class and apply the shape command in Policy Map Class Configuration mode. This class-default class is created automatically for you by the system. It is a simple match any class map that allows you to quickly match all traffic. Here is a sample configuration:

pixfirewall(config-pmap)#policy-map PM-SHAPER
pixfirewall(config-pmap)# class class-default
pixfirewall(config-pmap-c)# shape average 2000000 16000
pixfirewall(config-pmap-c)# service-policy PM-SHAPER interface outside

Verification is simple. You can run the following to confirm your configuration:

pixfirewall(config)# show run policy-map
!
policy-map PM-SHAPER
 class class-default
shape average 2000000 16000
!

Another excellent command that confirms the effectiveness of the policy is:

pixfirewall(config)# show service-policy shape
Interface outside:
 Service-policy: PM-SHAPER
Class-map: class-default
shape (average) cir 2000000, bc 16000, be 16000
Queueing
     queue limit 64 packets
 (queue depth/total drops/no-buffer drops) 0/0/0
      (pkts output/bytes output) 0/0

Traffic Policing

With a policing configuration, traffic that exceeds the “speed limit” on the interface is dropped. Unlike traffic shaping configurations on the appliance, with policing you can specify a class of traffic that you want the policing to effect. Let’s examine a traffic policing configuration. In this configuration, we will limit the amount of Web traffic that is permitted in an interface.

pixfirewall(config)# access-list AL-WEB-TRAFFIC permit tcp host 192.168.1.110 eq www any
pixfirewall(config-if)# class-map CM-POLICE-WEB
pixfirewall(config-cmap)# match access-list AL-WEB-TRAFFIC
pixfirewall(config-cmap)# policy-map PM-POLICE-WEB
pixfirewall(config-pmap)# class CM-POLICE-WEB
pixfirewall(config-pmap-c)# police input 1000000 conform-action transmit exceed-action drop
pixfirewall(config-pmap-c)# service-policy PM-POLICE-WEB interface outside

Notice we can verify with similar commands that we used for shaping!

pixfirewall(config)# show run policy-map
!
policy-map PM-POLICE-WEB
 class CM-POLICE-WEB
  police input 1000000
!
pixfirewall(config)# show ser
pixfirewall(config)# show service-policy police
Interface outside:
  Service-policy: PM-POLICE-WEB
    Class-map: CM-POLICE-WEB
      Input police Interface outside:
        cir 1000000 bps, bc 31250 bytes
        conformed 0 packets, 0 bytes; actions:  transmit
        exceeded 0 packets, 0 bytes; actions:  drop
        conformed 0 bps, exceed 0 bps

I hope that you enjoyed this four part series on QoS on the PIX/ASA! Please look for other posts about complex configurations on the security appliances very soon. I have already been flooded with recommendations!

PIX/ASA 7.2

AAA

debug radius
debug tacacs
show aaa-server protocol PROTOCOL_NAME
test aaa-server

Access Control Lists

show access-list
show run | include ACCESS_LIST_NAME
show run object-group
show run time-range

Application Inspection

show conn state STATE_TYPE detail
show service-policy

Configuring Interfaces

show firewall
show int
show int ip brief
show ip
show mode
show nameif
show run interface INTERFACE_NAME
show version

Connections and Translations

clear xlate
show conn
show conn detail
show local-host all
clear local-host all (clears all connections)
show log
show run | begin policy-map
show run global
show run nat
show xlate
test regex

Failover

debug fo rxip
debug fo txip
show failover
show ip

IP Routing

deug ospf event
debug rip
show ospf database
show ospf interface
show ospf neighbor
show ospf PROCESS_ID
show ospf virtual-links
show route

Multicast

show igmp interface
show mroute
show pim interface
show pim neighbor

PKI

debug crypto ca messages
debug crypto ca transactions
show crypto ca certificates
show crypto ca crls
show crypto key mypubkey rsa

Quality of Service

show priority-queue statistics
show run class-map
show run policy-map
show service-policy global
show service-policy interface INTERFACE_NAME
show service-policy priority
show service-policy shape

Security Contexts

show admin-context
show context
show mode

System Management

show clock
show crypto key mypubkey rsa
show logging
show ntp status
show running-config
show snmp-server statistics
show ssh sessions
show startup-config

Transparent Firewall

debug arp-inspection
debug l2-indication
debug mac-address-table
show access-list
show arp-inspection
show conn
show firewall
show mac-address-table

VPNs

debug crypto ipsec
debug crypto isakmp
show crypto ipsec sa
show crypto isakmp sa detail
show route

WebVPN

debug menu wbvpn
debug ssl cipher
show vpn-sessiondb summary
show vpn-sessiondb webvpn