Hello, and welcome to this demonstration on proxy ARP and blackholes.
In this section, you will see how a network problem and data flow,
which sometimes happens,
called a blackhole combined with proxy ARP and leads
to confusion when troubleshooting.
I will show the subtle difference in reaction when data is sent to a
blackhole with and without proxy ARP configured.
If using proxy ARP in your network,
it is important to understand where problems can occur and what
they look like so you can better respond.
I will also introduce how this may be used as the basis for attacks,
something which I will cover in more detail in a
module on ARP related security issues.
At the end,
I will show what needs to be done to remove the proxy ARP
configuration and fix the blackholes.
Let's take a look at the demonstration setup.
I have a Windows 10 sender at 20.
1.
15 configured with a /8 mask so it will request ARPs
for anything starting with 20.
The router is configured with the default proxy ARP
configuration and will respond with proxy ARP replies.
The remote target is a fake Globomantics web server at 20.
2.
201.
To create a blackhole,
I will simply alter the ARP cache on the router and insert a
false static ARP entry for the web server.
This will create a blackhole where the router will
believe it has a path to the web server,
but it is incorrect.
I will also create a routed blackhole situation by adding a
loopback interface to a network which does not exist.
When the Windows 10 host tries to send data to these two destinations
and its transmissions are blackholed by the router,
you will see the difference between when the router is
providing proxy ARP and when it is not.
This will give you the ability to better pinpoint issues in
your network given similar conditions.
At the end, I will show the remediation on the router and the end host.
Let's get started by verifying the proxy ARP is working and that my hosts
have connectivity to remote systems through that proxy ARP.
I'll open my Windows command prompt and I'll check out my IP address and mask.
I can see I'm connected to the 20.
0.
0 network,
meaning my system will believe that anything that starts with 20 is on this LAN.
I'll check my ARP cache and here I can see the default-gateway at 20.
1.
1, but also 20.
2.
201 shows up at my router's MAC address.
This is a pretty clear sign that I learned that through proxy ARP,
especially if my router is using a /24 mask.
To verify connectivity, I'll ping 20.
2.
201 and I've got good replies.
I'll also bring up the web browser and I'll put in the
address of my fake Globomantics web server 20.
2.
201.
It looks like it's coming up.
Now let's switch over to my router and see what I can
do to create false information.
I'll log in and I'll show its ARP cache.
Right here, I see that remote web server at 20.
2.
201 with the specially configured MAC address 0000.
0000.
0200.
In an earlier demonstration,
I showed how 4-hour Cisco ARP cache timer can lead to stale and false entries
and how a static entry could create a loss of connectivity.
To show how that affects this proxy ARP situation,
I'm going to bring up my Windows command prompt,
I'm going to start a continuous ping for 20.
2.
201 and currently that's functioning.
I'll return to my router,
I'll go to global configuration mode and I'll create an ARP entry for 20.
2.
201 to an incorrect MAC address, 0000.
aaaa.
bbbb.
So let's check out what happened to the Windows command prompt.
At this point, my system is encapsulating data to 20.
2.
201 and using the router's MAC address and its ARP cache.
Even if I clear my ARP cache with arp -d and an asterisk and
check my ARP cache to make sure it's gone,
if I ping 20.
2.
201, of course,
it will time out because of the routers incorrect ARP cache information,
but if I check my ARP cache again,
proxy ARP has filled in my router's MAC address.
Now to be clear, turning off proxy ARP is not going to fix this problem.
As proof,
if I return to my router and I move to the interface servicing my LAN and
turn off proxy ARP with the no ip proxy-arp command,
go back to my Windows and ping the remote system,
it still times out.
So proxy ARP is not causing our issue.
Our issue is that the router is not able to encapsulate data,
but check out what the difference is.
Now when I check my ARP cache, I don't have any entries for 20.
2.
201 because proxy ARP is not responding.
Now I'm routing the data through the router and the router has dropped it.
Subtle difference.
This can lead to confusion as to whether proxy ARP is
actually causing an issue in your network.
In this case, it's not.
I maintain that it's generally better to shut it off if you don't need it,
but don't let a false positive lead you down the wrong path.
Now let's check out how a different piece of false
information in our router can lead to a blackhole.
I'll return to my router and this time I want it to be a
false piece of routing information.
So I'll look at the routing table with show ip route and this
router is simply routing between my two networks.
If I ping 20.
77.
77, we'll see that we get destination host unreachables from my card,
as well as the default-gateway.
This means the default-gateway is telling me it can't get there.
Now if I return to my default-gateway, if I go to global configuration mode,
back to my interface servicing my LAN, return it to proxy ARP service,
then I exit out and I create an interface loopback 10.
I'll give it an IP address of 50.
50.
1, now this is a software interface, it doesn't go anywhere,
but if I exit out and I create an IP route to some unknown network,
20.
77.
0, and I send it to the loopback 10,
then this router believes that it has a route to the 20.
77.
0 network.
Now this is just a proof of concept, however,
this router could have learned about any route through a static route
or through a routing update from a routing protocol telling it how to
get to a destination that doesn't exist.
In this case,
I'm just simulating it by creating a static route to a loopback interface.
If I return to my host, previously my router told me it couldn't get there.
Now if I ping that IP address,
proxy ARP will respond because my router believes it has a way to get to 20.
77.
If I check my ARP cache, we see an entry there for 20.
77.
77 through my router.
This is not proxy ARPs failure,
the failure is that the router has false forwarding information,
but the results are suddenly different.
In one case,
my router provided no proxy ARP response and told my system
that that destination host was unreachable.
Now that there is false information and a proxy ARP configuration,
my system is tricked into trying to forward it and the router then
tries to forward that data into a false blackhole.
Although this isn't a problem of proxy ARP,
it does apply to what you'll be seeing in a security module on ARP
where hackers will spoof the default-gateway and provide proxy ARP
forwarding legitimate user traffic into a blackhole creating a
Denial of Service attack.
Now to clean up my mess, I'm going to return to my router,
I'll remove my false route by putting no in front of it,
I'll also take off my interface loopback 10,
and since I don't need proxy ARP,
I'll return to interface FastEthernet 0/0 and I'll
issue the no ip proxy-arp command.
Let's change that to proxy-arp so that we make sure we get it shut off.
Then don't forget to go to all your client stations and change their
properties on their IP addressing to set them to a proper mask.
In this case,
I'm just going to set them to use DHCP and that should take care of
the problem because my DHCP servers are correct.
Let's also exit out of here and remove the false static ARP cache entry.
Now, even though I've removed it, don't forget to check your ARP cache,
and if that entry is still there, make sure to clear it out.
Let's go ahead and fill that in by pinging 20.
2.
201, check my ARP cache, and you can see dynamic ARP has done its job.
Return to my host and ping 20.
2.
201, I can get there,
and I've returned to normal routing and connectivity in the inner network.
If proxy ARP is part of your networks, when problems occur,
be sure to check the information in both the end systems and the path
to a destination to find the source of an issue.
Subtle output differences and system behaviors are important to observe.
In this case, proxy ARP was not the issue,
however,
its removal reduces the risk of misdiagnoses as well as other problems and is highly recommended if not needed in your network.