Mar
14

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,

Keith.


You can leave a response, or trackback from your own site.

8 Responses to “ARP Inspection on Transparent ASA”

 
  1. Mohamed Gazzaz says:

    Excellent Post. Thanks Keith.

  2. SickMonkey says:

    And if we throw in the ole’ HSRP monkey wrench?

  3. Rizzo says:

    Sweet! Great Stuff

    I like it very much. Its much better explained then Cisco Doc. :) It nicely burnt into my brain. ;)

  4. TacACK says:

    Great stuff Keith :) Would love to see more CCIE-sec articles from you.

  5. Gawel says:

    It’s been ages since the last CCIE Security blog entry like this. Thank you.

  6. TheEvilMuffin says:

    Awesome as always.

    Thank you Keith.

  7. Sab says:

    Hi Keith,

    As usuall great article.

    How about mac-learn and how it is suited in this example!

    Kindest regards,
    Sab

  8. Praveen says:

    Hi Keith,

    Very good explanation. You take things step by step very well. Its really easy to follow your steps. Those are lucky who attended your training session live.
    Regards,
    Praveen

 

Leave a Reply

Categories

CCIE Bloggers