ARP Inspection on Transparent ASA

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:
SMTF-Single Mode Trans Firewall with ARP Inspection
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,

0 comments:

About US

Network Bulls is Best Institute for Cisco CCNA, CCNA Security, CCNA Voice, CCNP, CCNP Security, CCNP Voice, CCIP, CCIE RS, CCIE Security Version 4 and CCIE Voice Certification courses in India. Network Bulls is a complete Cisco Certification Training and Course Coaching Institute in Gurgaon/Delhi NCR region in India. Network Bulls has Biggest Cisco Training labs in India. Network Bulls offers all Cisco courses on Real Cisco Devices. Network Bulls has Biggest Team of CCIE Trainers in North India, with more than 90% of passing rate in First Attempt for CCIE Security Version 4 candidates.
  • Biggest Cisco Training Labs in India
  • More than 90% Passing Rate in First Attempt
  • CCIE Certified Trainers for All courses
  • 24x7 Lab Facility
  • 100% Job Guaranteed Courses
  • Awarded as Best Network Security Institute in 2011 by Times
  • Only Institute in India, to provide CCIE Security Version 4.0 Training
  • CCIE Security Version 4 Training available
  • Latest equipments available for CCIE Security Version 4

Network Bulls Institute Gurgaon

Network Bulls Institute in Gurgaon is one of the best Cisco Certifications Training Centers in India. Network Bulls has Biggest Networking Training and Networking courses labs in North India. Network Bulls is offering Cisco Training courses on real Cisco Routers and Switches. Labs of Network Bulls Institute are 24x7 Available. There are many coaching Centers in Delhi, Gurgaon, Chandigarh, Jaipur, Surat, Mumbai, Bangalore, Hyderabad and Chennai, who are offering Cisco courses, but very few institutes out of that big list are offering Cisco Networking Training on real Cisco devices, with Live Projects. Network Bulls is not just an institute. Network Bulls is a Networking and Network Security Training and consultancy company, which is offering Cisco certifications Training as well support too. NB is awarded in January 2012, by Times, as Best Network Security and Cisco Training Institute for the year 2011. Network Bulls is also offering Summer Training in Gurgaon and Delhi. Network Bulls has collaboration with IT companies, from which Network Bulls is offering Networking courses in Summer Training and Industrial Training of Btech BE BCA MCA students on real Live projects. Job Oriented Training and Industrial Training on Live projects is also offered by network bulls in Gurgaon and Delhi NCR region. Network Bulls is also providing Cisco Networking Trainings to Corporates of Delhi, Gurgaon, bangalore, Jaipur, Nigeria, Chandigarh, Mohali, Haryana, Punjab, Bhiwani, Ambala, Chennai, Hyderabad.
Cisco Certification Exams are also conducted by Network Bulls in its Gurgaon Branch.
Network Bulls don't provide any Cisco CCNA, CCNP simulations for practice. They Provide High End Trainings on Real topologies for high tech troubleshooting on real Networks. There is a list of Top and best Training Institutes in India, which are providing CCNA and CCNP courses, but NB has a different image from market. Many students has given me their feedbacks and reviews about Network bulls Institute, but there were no complaints about any fraud from this institute. Network Bulls is such a wonderful place to get trained from Industry expert Trainers, under guidance of CCIE Certified Engineers.

About Blog

This Blog Contains Links shared by sites: Cisco Guides, Dumps collection, Exam collection, Career Cert, Ketam Mehta, GodsComp.co.cc.

NB

NB
Cisco Networking Certifications Training

Cisco Training in Delhi

ccna training in gurgaon. ccnp course institute in gurgaon, ccie coaching and bootcamp training near gurgaon and delhi. best institute of ccna course in delhi gurgaon india. network bulls provides ccna,ccnp,ccsp,ccie course training in gurgaon, new delhi and india. ccsp training new delhi, ccie security bootcamp in delhi.

Testimonials : Network Bulls

My Name is Rohit Sharma and i Have done CCNA and CCNP Training in Gurgaon Center of Network Bulls and it was a great experience for me to study in Network Bulls.

Cisco Networking Certifications

Myself Komal Verma and i took CCSP Training from Network Bulls in Gurgaon. The day i joined Network Bulls, the day i get addicted with Networking Technologies and I thank Mr. Vikas Sheokand for this wonderful session of Networking. :)
I must say that Network Bulls is Best Institute of CCNA CCNP CCSP CCIE Course Training in Gurgaon, New Delhi and in India too.
Komal Verma

About a wonderfull CCIE Training Institute in Gurgaon

I am Kiran shah from New Delhi. I have recently completed my CCNA CCNP & CCIE Training in Gurgaon from Network Bulls and i recommend Network Bulls for Cisco Training in India.

Kiran Shah

Cisco Coaching and Learning Center

Disclaimer: This site does not store any files on its server. I only index and link to content provided by other sites. If you see any file on server that is against copy right you can inform me at (sidd12341 [at] gmail.com). I will delete that materials within two days. This Website is not official Website of any Institute like INE, Network Bulls, IP Expert. Thanks

CCIE Security Version 4

Cisco Finally updated CCIE Security Lab exam blueprint. WSA Ironport and ISE devices are added in CCIE Security Version 4 Lab Exam Syllabus Blueprint. In Updated CCIE Security Version 4 Syllabus blueprint, new technologies like Mobile Security, VoIP Security and IPV6 Security along with Network Security, are added. As in CCIE Security Version 3 blueprint, Cisco had focused on Network Security only, but now as per market demand, Cisco is looking forward to produce Internet gear Security Engineer, not only Network Security engineers.
In CCIE Security Version 4 Bluerpint, Lab Exam is going to be more interested than before. What is Difference in CCIE Security Version 3 and Version 4? Just go through the CCIE Security Version 4 Lab Equipment and Lab Exam Syllabus Blueprints and find out!