0

I have a ASA 5506-X version 9.8(2). The ASA has two interfaces: g1/1 (outside, ip: 209.165.0.2/30), and g1/3 (inside, ip: 209.165.0.5/30).

g1/1 is connected to a 881-W router (Router-A), whose ip is 209.165.0.1/30. Router-A's internal interface is 192.168.0.1/24.

g1/3 is connected to a 2821 router (Router-B), whose ip is 209.165.0.6/30. Router-B's internal interface is 10.0.0.1/24.

This is what the topology looks like: (Note that I have an actual physical lab, I just diagrammed it in Packet Tracer so that it's easier to visualize. Also the model numbers on the Packet Tracer diagram do not correspond with the actual physical models)

enter image description here


Below are my additional configurations:

881-W's routes:

ip route 209.165.0.4 255.255.255.252 vlan 2 <------------ (I would like to test if a directly connected route can result in a successful ping. If I change this to a next hop route (ip route 209.165.0.4 255.255.255.252 209.165.0.2), ping is successful. But as of now, ping is unsuccessful if I use the directly connected route.)

ip route 10.0.0.0 255.255.255.0 209.165.0.2


2821's routes:

ip route 192.168.0.0 255.255.255.0 209.165.0.5

ip route 209.165.0.0 255.255.255.252 209.165.0.5


ASA's routes and ACL:

route outside 192.168.0.0 255.255.255.0 209.165.0.1

route inside 10.0.0.0 255.255.255.0 209.165.0.6

access-list PERMIT extended permit ip any any

access-group PERMIT in interface outside

access-group PERMIT in interface inside

access-group PERMIT out interface outside

access-group PERMIT out interface inside


I added arp permit-nonconnected on the ASA, but pinging from 192.168.0.1 to 10.0.0.1 does not work. Why?


debug arp on ASA outputs:

arp-in: request at outside from 209.165.0.1 588d.09a4.f3cc for 10.0.0.1 0000.0000.0000 having smac 588d.09a4.f3cc dmac ffff.ffff.ffff arp-set: added arp outside 209.165.0.1 588d.09a4.f3cc and updating NPs at 19:52:01.599


Shouldn't it work even if the source (209.165.0.1) and destination address (10.0.0.1) of the ARP packet are in different subnets, since I configured arp permit-nonconnected?

Thanks for the help!

3
  • 1
    ARP requests are broadcast, and broadcasts cannot be routed from one network to another.
    – Ron Maupin
    Feb 20 at 20:09
  • I see. Shouldn't the ASA have an ARP entry for 10.0.0.1, so it can respond back to 881-W's ARP request? Why isn't the ASA responding back to the ARP request? Feb 20 at 20:21
  • No, that is proxy-ARP. A host sending to another host on a different network will use the layer-2 address of its own gateway for the frame. Remember that frames are stripped and discarded by routers, so any layer-2 addressing is only ever seen or valid on the local LAN.
    – Ron Maupin
    Feb 20 at 20:25

2 Answers 2

1

pinging from 192.168.0.1 to 10.0.0.1 does not work. Why?

RouterA has no route for 10.0.0.1. It can only drop the packet. There is no apparent problem with ARP.

  • RouterA requires a route for 10.0.0.0/24 via the ASA, or a less specific router, or default.
  • The ASA requires a route for 10.0.0.0/24 via RouterB.

Return route:

  • RouterB requires a route for 192.168.0.0/24 via the ASA.
  • The ASA requires a route for 192.168.0.0/24 via RouterA.
0

Updated to provide an alternative solution.

Updated to include an additional use of the command.

Essentially, no, this should not work. The reason is that the arp permit-nonconnected command mainly applies when using bridge-groups or when you have NATs configured for IP addresses that are not in the same subnet as the interface itself.

Let's start from the beginning.

Routers are fundamentally used to connect networks. The goal is to let things talk. That's why they have things like "proxy-arp", which is when the router responds to an ARP for an IP that is not itself, saying "send it to my MAC", because I will forward it. The router is capable of responding to an ARP request for any (and every!) IP address on the planet (providing the request entered an interface where proxy-arp is enabled), because it is being helpful to the hosts on that local subnet. (Proxy-arp isn't applicable for anyone who is not in the broadcast domain, because ARPs are broadcasts.)

In contrast, firewalls are fundamentally used to limit connectivity and provide security. The goal is to analyze traffic and ensure rules are being followed. That's why firewalls don't have things like proxy-arp. Basically, the firewall is unwilling to forward traffic for a host unless the host is following the rules, and is forming packets correctly.

I know what you're thinking: "Everybody says the ASA can do proxy-arp! The documentation even says so!" Here's my opinion on that: Cisco has labeled it wrong. Proxy-arp is when a device responds to an ARP request on behalf of a different device. In reality, what the ASA is actually doing is responding to an ARP request for an IP that is configured upon the device (like, in a NAT statement), found in the config of the ASA. The ASA is legitimately responding to the request, saying "send it to my MAC", because that is me! Subsequently, it then translates headers, or whatever! The point is that the ASA has the IP address configured. The same is NOT true when a router responds to ARP requests for IP addresses it has no knowlege of.

Okay, so what does arp permit-nonconnected actually do?

When you configure the ASA with bridge-groups, the ASA (being a security device, remember?) will keep track of an ARP table in a similar way that switches keep track of MAC tables. (This is called the ARP cache.) The ASA will only pass traffic between the left and right halves of the bridge-group if the MAC and IP addresses in the packet agree with the ARP table that the firewall is tracking. So, if a host is being lured by a man-in-the-middle attack (happening at layer2 with ARP), the ASA will see the MAC address and the IP address of the packet and notice that they do not agree with the table the ASA is keeping. Thus, the ASA will drop the packet.

If a packet arrives at the ASA (when running bridge-groups) and the ASA does not have an ARP entry for the IP, the ASA generates an ARP request to build that ARP cache entry. By default, the ASA will add ARP replies to its table only if the ARP is for the directly attached subnet. If you need ARP replies to be populated in the table for subnets that are not directly connected, you use the arp permit-nonconnected command.

A second use for the command is when you have NATs where the inside-global IP address is not contained within the subnet of the firewall interface. In this scenario, the ASA will happily discard ARP requests for the inside-global IP address. If you apply the arp permit-nonconnected command, the ASA will respond to those ARP requests with its own MAC address. A workaround for this is to apply a static route at the upstream layer3 device to point at the ASA. Then the ARP request is not for the inside-global IP address, but rather for the ASA's own interface. This workaround is not always possible when your ISP is difficult to work with.

So, in your lab scenario, I think the ASA is doing exactly what it's supposed to. If you swapped out the ASA for a router, and you configured "ip proxy-arp" on the left interface, I think your entire scenario would work as expected.

Here's another way to handle the situation. If you set the arp permit-nonconnected back to default (which is to remove it using no arp permit-nonconnected), and then you apply identity NATs for the inside subnets, the ASA will essentially perform the behavior you're expecting.

object network inside_transit
 subnet 209.165.0.4 255.255.255.252
 nat (inside,outside) static inside_transit
object network inside_net
 subnet 10.0.0.0 255.255.255.0
 nat (inside,outside) static inside_net

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.