In this section, we will be covering the issues associated with proxy ARP.
We will review the logic of proxy ARP so you can clearly
understand its function in your systems.
Because there are several variations on how it might be
implemented and how it is supported in vendor equipment,
this will give you the basis for knowing when you need it.
As a rule,
I generally do not want the complexity the network and administrative
overhead and security issues that proxy ARP add.
There are, however, some use cases where network communication requires it.
You will see how based on vendor equipment and network design choices,
it may be necessary to the proper function and
communication of systems in your network.
By the end,
you will have a clear understanding of where and when you can
disable proxy ARP and the consequences of doing so.
I'll show you how sending data to a non-existent destination called
blackholing could be combined with proxy ARP.
Although this is not an issue caused by ARP or proxy ARP directly,
it does lead to confusion and possible false positives and troubleshooting.
It is also a critical piece related to certain denial of service and spoofing
attacks you will see in the module on ARP and security.
Finally,
we will look at the overhead that proxy ARP creates in networks
and on systems and what you can do about it.
First, let's review some basics of proxy ARP.
Proxy ARP is simply when one system on a LAN answers ARP requests
for other hosts not on the same broadcast network.
To understand how and where it breaks,
let's analyze some of the logic of proxy ARP function.
First,
the sender must believe the remote target is on the same local broadcast subnet.
At that point, the sender will check its ARP cache finding nothing,
send a broadcast ARP request to the network asking who has that IP.
In this case, who has IP 4.
Secondly,
the proxy ARP provider must have some knowledge of the
target for which it is acting as proxy.
This can be in the form of an ARP cache entry on another interface.
For example, here,
the router will have an ARP cache entry on its interface
at MAC C for the host at IP 4 MAC D.
It could also be a route to the destination in its routing table.
The knowledge of the target could be from secondary or other
interfaces or NAT translation tables on the device as well.
Regardless of the source of knowledge,
it implies that if the device does not know anything about the destination,
it will not answer as a proxy for it.
Last,
the proxy ARP provider must be able to provide proxy
ARP responses to ARP requests.
If either the proxy ARP is disabled or a firewall
process prevents it from responding, of course,
it can't do its job.
As long as proxy ARP is not disabled or blocked for some reason,
we will see it respond.
So here,
we see the proxy ARP provider sending a response to the
ARP request that IP 4 is at MAC B.
In this way,
the gateway is acting as a proxy by providing its MAC B for the host at IP 4.
Finally,
the sender can put this in its ARP cache and
encapsulate data to IP 4 using MAC B.
Now let's look at where proxy ARP can go wrong.
First, we'll cover what happens when proxy ARP is unavailable.
Just like our previous scenario,
we have a sender who believes the target is on the same broadcast
subnet and will therefore send ARP requests.
If we look at the sender's IP and mask,
it believes that anything starting with the first
octet of 20 is in the local subnet.
The target IP address fits this and so our sender broadcasts a
who has message for the target IP of 20.
2.
201.
In this case,
our gateway does not have proxy ARP enabled either because the default was
disabled or it was enabled by default and was disabled.
Whatever the reason, with proxy ARP disabled,
the gateway will not respond to ARP requests for the target IP 20.
2.
201.
Now how the original sender handles a lack of ARP
replies dependent on the OS stack, for example,
I will show in the demonstration that not having gotten and ARP reply for 20.
2.
201, Ubuntu Linux will stop right there and never encapsulate nor send data.
We will see that Windows 10, however,
will fall back on routing and try to use the default-gateway to send data to 20.
2.
201, this will succeed.
How your systems will respond to proxy ARP being unavailable is
something you can determine using sniffer traffic just like you
will see in the demonstration.
Solutions to these problems include enabling proxy ARP for clients
which require it or as long as all your clients can handle routing and
assuming you're not using proxy ARP as a stop gap for things like IP
migration or some other use case,
correct the senders IP and mask to match your network.
Disable proxy ARP and use Layer-3 routing.
This will provide better isolation, limit ARP overhead,
and improve the security of the network.
Remember that some firewall and NAT agencies variations on
proxy ARP to be able to answer for and forward traffic to
systems on the other side of the firewall.
In this case, the scenario is similar.
The sending router needs to send data to the outside address of the web server.
The web server is at 172.
18.
2.
201, but looking at the NAT table,
the target web server is only available from the outside through the NAT IP 10.
0.
201, therefore, the router sees 10.
0.
201 in the same subnet as its own IP, 10.
0.
2 and will therefore send who has ARPs for 10.
0.
201.
If the firewall is not configured for proxy ARP,
it will likely not reply and the router cannot encapsulate and send data.
Please note that the firewall's ability to send proxy ARP replies
for the NAT IP addresses in its table is usually independent of
the NAT and firewall configurations.
This means you can have the firewall properly configured for filtering
and NAT and traffic may not flow without proxy ARP.
The need to and methods of enabling proxy ARP will be
dependent on your firewall vendor.
So what are the options here.
Option one is to follow the vendor's guidelines and enable proxy ARP.
This is not generally considered a security risk in and
of itself and will allow data to flow.
Ultimately,
the security of the traffic through the firewall is
dependent on the configured firewall rules and not the
existence and behavior of proxy ARP.
Another option is to change the NAT IP addresses and configuration
on the firewall to use IP space different from the subnet shared on
the router to firewall connection.
This way, the router can route traffic, will not require ARPs,
and proxy ARP can be disabled on the firewall.
It does require that the router have routes to the destination IP
addresses listed in the NAT table and that all firewall and NAT
configurations are changed for these IP addresses.
Of course, another consideration is whether IP addresses can be changed at all.
You may be constricted by your organizational needs in the limitations
of your IP provider to supply new IP space for this.
Proxy ARP can also facilitate connectivity between the LAN and remote clients.
When remove clients join the network through dial-up or VPN connections,
they are provided IP addresses through the connection.
If they are provided IP addresses in the same space as the LAN,
then the LAN clients will use ARP requests during communication as
they see the remote target is in the same network.
This is not a subnet mask issue, however.
If proxy ARP is not functioning on a remote access server,
you will not answer any LAN side ARP requests.
The solutions include enabling proxy ARP at the server.
The server will then respond to LAN ARP requests and traffic and flow.
This can create some security issues depending on the trust or
rather the distrust you have with the remote clients,
as well as the security of the remote connection facing the internet.
A better solution is to create one or more different subnets for all
remote connected clients and routing can be used.
This solution allows for better segregation based on zones of trust and
filtering of traffic per your organizational policies.
Our next issue is a proxy ARP blackhole.
Now although I have depicted this using the gateway router scenario,
this also applies to a firewall with NAT and remote access servers as well.
As usual,
our sender wants to send data to a host that appears local and
naturally sends ARP requests for the remote target.
A proxy ARP provider, in this case, our router,
is properly configured for proxy ARP and believes it has a path to the remote
host and responds with an ARP reply using its own MAC address.
The problem is that the router has false information.
This can happen in various ways.
It could have a stale or static ARP cache entry for the server
which has gone off or had some change not reflected in the router's
ARP cache or the router could have a route configuration pointing
to a non-existent destination.
Whatever the cause,
the proxy ARP provider cannot actually get data to the
remote target but believes it can.
The host, having received an ARP reply,
will encapsulate and send data to the proxy MAC B at the router.
The router having incorrect ARP cache entry on the other interface or
the false routing information will send the data,
but it will not be received by the destination our host intended.
This is the blackhole.
The solutions include fixing the false information.
Since the fault here is not proxy ARP,
it is the false forwarding information in the router,
this would correct the blackhole problem and connectivity.
Leaving proxy ARP enabled, however,
might falsely lead one to think it is causing the issue.
As proxy ARP is rarely needed and not at all in this situation,
its removal simplifies the network and relies on a more
solid design using Layer-3 routing.
You will also see that the use of proxy ARP has
other security and overhead issues,
so I recommend not only fixing any Layer-3 route or Layer-2 MAC
ARP cache forwarding issues in the router,
but also stop using proxy ARP.
If you do not have clients or network design
requirements which require proxy ARP,
its configuration and complexity should be removed
from your network and systems.
Our last problem associated with proxy ARP is overhead.
As with all the previous,
our sender is simply trying to communicate with another
system it believes is in the local subnet.
The problem is the volume of ARP requests coming from the LAN for
which the router is required to send proxy replies.
If the gateway is responsible for the listed remote subnets,
it could potentially be answering ARPs for about 75,
000 different IP addresses.
This is then multiplied by every host in the sender's LAN.
This will require more processing on the router,
reduced interface resources for forwarding traffic,
and larger ARP caches on nodes in the network.
In this case,
the best solution is to correct masks on any host systems relying on proxy ARP,
disable the proxy ARP, and move to a Layer-3 routed solution.
Reviewing proxy ARP's problems and solutions.
If you have proxy ARP disabled and you don't need it,
good for you,
but assuming you have some use case or current clients which require it,
you can either enable it,
which may cause some of the other issues we've talked
about like overhead and security,
or you can see if there is a way to eliminate the
need and move to a routed solution.
Proxy blackholes can occur because proxy ARP replies are
being sent for unreachable destinations.
As long as this is not some form of an attack,
it either means that you need to repair the proxy ARP server's false
information or work again to eliminate it for a Layer-3 solution.
If you have firewalls and NAT appliances or remote access systems,
it is possible that proxy ARP is a necessary part of
the solution to enable connectivity.
It stems from using IP addresses for remote hosts or NAT
translations in the same range as your LAN.
Generally,
enabling proxy ARP is not a security issue on the
firewall if configured properly,
but can be a security risk if permitting untrusted
access to your LAN from the internet.
Both of these could have proxy ARP disabled as long as you
have the ability to change the target IP addressing away
from the local use IP addressing.
Finally,
proxy ARP does create overhead and processing the request and replies in
traffic on the network and in increased ARP caches.
You should look at the role proxy ARP is playing in your systems
and weigh its benefits against the negatives. If possible, look for design opportunities which allow it to be disabled.