If you do not already understand what ARP is, then you will need to understand that before this article will make much sense. ARP, which stands for “Address Resloution Protocol”, in simple terms is a mechanism that makes it possible for devices that are on an Ethernet-like network communicate. Let’s take a very simple example where we have 2 devices plugged into an Ethernet switch using IP addresses 192.168.1.1 for device A and 192.168.1.2 for device B and subnet mask /24 (255.255.255.0). These devices can communicate at layer 3 directly, because they are in the same subnet. If Device A needs to send an IP packet to Device B, it will need to send that packet via the Ethernet switch. This means that the IP packet will need to be framed in an Ethernet frame. Device A already knows the IP address it needs to communicate with, but it needs a method to determine which MAC (Ethernet address) is associated with that IP address. This is where ARP comes in.
In the above circumstance, Device A will know that Device B is plugged into the same Ethernet segment because it’s subnet is the same as it’s own. In order to determine which MAC address is associated with the IP 192.168.1.2, Device A will send a packet onto the Ethernet segment that is destined to the Ethernet Broadcast address. This address is one that every device plugged into the switch will “hear” and “inspect”. This packet includes a request asking “Who has 192.168.1.2?”. Every device on the segment will “hear” this request, but only one device will “own” that IP and respond. The response will be something like “192.168.1.2 is at 00:12:34:56:78:9A”. Now Device A knows the MAC address that is associated with the IP address 192.168.1.2 and it can frame the IP packet and send it out the Ethernet interface.
The above description is very much shortened, but should give you some understanding of the process. It is important to note that both Device A and Device B MUST be connected to the same LAN segment. The ARP process is needed only for LAYER 2 addressing purposes.
So, let’s take a look at a situation where proxy arp would be necessary. Consider this network diagram:
In the above network, we have a client device that could be a Windows PC, Laptop or another router. For the purpose of this explanation, we need to assume it is not a router. The reason for this assumption is that the behaviour of a router may (or may not) be different than I will describe. Let’s assume for a moment that the router (on the right) assigns this client device with an IP of 192.168.2.1. When the client sends IP traffic to the server at 192.168.1.2, that packet will have a source address of 192.168.2.1 (the tunnel IP). The server “sees” that packet and responds to the IP 192.168.2.1, which is not on it’s local subnet. The server would send the packet through it’s “gateway” at 192.168.1.1.
Let’s consider another scenario where the router assigns the pptp client with the IP address 192.168.1.10. Again, when the client sends IP traffic to the server, the source IP address will be the tunnel IP of 192.168.1.10. The server will need to respond to the IP address 192.168.1.10. The problem here is that although the server will ASSUME that the device with the IP address 192.168.1.10 exists on the local LAN, it does not. When the server sends it’s ARP request to the LAN asking “Who has 192.168.1.10″, there is NO device on the LAN with that IP and therefore the communication will fail. If, however, on the router’s LAN interface, we configured it to answer ARP requests “by proxy” for the tunnels it knows about, the ROUTER will answer the server’s arp request. In this way, the server would “deliver” the Ethernet frame (with the IP packet inside) to the router, which in turn will deliver the IP packet to the PPtP client over the tunnel. I am certain that you’ve already figured out the rest, but I’ll say it anyway…the configuration we need to do on the router is to turn on proxy arp on the LAN interface.
In the Mikrotik, this is very simple to do. If the interface is named “LAN”, then the following command would do it:
/interface ethernet set LAN arp=proxy-arp
That’s IT! In MOST circumstances, I recommend using IP space that is NOT in the LAN subnet for tunnels. If it is necessary, due to limited IP space or for any other reason (Active Directory issues are one situation), setting proxy arp will be necessary and will allow this to function.
As always, I hope this article has been helpful to you. If you find it of use, by all means “Digg it” above to let others know about it.
http://blog.butchevans.com/2010/06/when-and-why-proxy-arp/
