blog
    ARP Inspection on Transpa ...
    14 March 10

    ARP Inspection on Transparent ASA

    Posted byINE
    facebooktwitterlinkedin
    news-featured

    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:<strong> ARP inspection check failed</strong> 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.

    Hey! Don’t miss anything - subscribe to our newsletter!

    © 2022 INE. All Rights Reserved. All logos, trademarks and registered trademarks are the property of their respective owners.
    instagram Logofacebook Logotwitter Logolinkedin Logoyoutube Logo