Skip to main content

Proxy ARP

In today’s post I would like to look closer into one feature - proxy arp. On Cisco routers it is enabled by default and I think it’s worth of writing about possible pros and cons. To be on the same page just few words about ARP (Address Resolution Protocol). ARP is used to resolve IP addresses to MAC (physical). When we want to send packet to a host with known IP address, we need first know its MAC or MAC of a next hop. This is place where ARP start its job. Let’s look into below diagram.

proxy-arp-1.jpeg

Assume that R1 has never contacted with R3 and I’m going to check its ARP table:
 
R1#sh ip arp
Protocol  Address          Age (min)  Hardware Addr   Type   Interface
Internet  10.0.0.1                -   ca00.18c4.0008  ARPA   FastEthernet0/0
R1#

As you see I have only one entry with IP and MAC of the local interface. Before I ping R3 I enable debugging to see what’s happening behind the scene.
 
R1#debug arp
ARP packet debugging is on
R1#
R1#ping 10.0.0.3
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 10.0.0.3, timeout is 2 seconds:

*Jan 15 01:17:25.402: IP ARP: creating incomplete entry for IP address: 10.0.0.3 interface FastEthernet0/0
*Jan 15 01:17:25.402: IP ARP: sent req src 10.0.0.1 ca00.18c4.0008,
                 dst 10.0.0.3 0000.0000.0000 FastEthernet0/0
*Jan 15 01:17:25.506: IP ARP: rcvd rep src 10.0.0.3 ca02.1634.0008, dst 10.0.0.1 FastEthernet0/0.!!!!
Success rate is 80 percent (4/5), round-trip min/avg/max = 32/52/84 ms
R1#

As you see above ARP first created an incomplete entry for the destination IP:
 
*Jan 15 01:17:25.402: IP ARP: creating incomplete entry for IP address: 10.0.0.3 interface FastEthernet0/0

and then ARP sends request and you can see R3 MAC unknown (0000.0000.0000):
 
*Jan 15 01:17:25.402: IP ARP: sent req src 10.0.0.1 ca00.18c4.0008,
                 dst 10.0.0.3 0000.0000.0000 FastEthernet0/0

and then R3 responds and we see next message:
 
*Jan 15 01:17:25.506: IP ARP: rcvd rep src 10.0.0.3 ca02.1634.0008, dst 10.0.0.1 FastEthernet0/0.!!!!

The same process captured by Wireshark:

proxy-arp-2.jpg

So, now the ARP table contains:
 
R1#sh ip arp
Protocol  Address          Age (min)  Hardware Addr   Type   Interface
Internet  10.0.0.1                -   ca00.18c4.0008  ARPA   FastEthernet0/0
Internet  10.0.0.3               11   ca02.1634.0008  ARPA   FastEthernet0/0
R1#

In case when we send packet to host behind a router, ARP resolve the destination IP to the MAC address of the next hop (within the same broadcast domain).

Let’s start with proxy ARP now. The general idea was to have ability to connect to any host in different segment network (neighboring), you don’t have a route for. Considering above diagram assume R2 doesn’t have any routing towards R1 and we try to ping it.

The routing and ARP tables:
 
R2#sh ip ro
R2#sh ip route
Codes: L - local, C - connected, S - static, R - RIP, M - mobile, B - BGP
       D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter area
       N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2
       E1 - OSPF external type 1, E2 - OSPF external type 2
       i - IS-IS, su - IS-IS summary, L1 - IS-IS level-1, L2 - IS-IS level-2
       ia - IS-IS inter area, * - candidate default, U - per-user static route
       o - ODR, P - periodic downloaded static route, H - NHRP, l - LISP
       + - replicated route, % - next hop override

Gateway of last resort is not set

      10.0.0.0/8 is variably subnetted, 2 subnets, 2 masks
C        10.0.1.0/24 is directly connected, FastEthernet0/1
L        10.0.1.2/32 is directly connected, FastEthernet0/1
R2#
R2#sh ip arp
Protocol  Address          Age (min)  Hardware Addr   Type   Interface
Internet  10.0.1.2                -   ca01.18c4.0006  ARPA   FastEthernet0/1
Internet  10.0.1.3               50   ca02.1634.0006  ARPA   FastEthernet0/1
R2#
R2#

Before I start I enable debugging on R2 too:
 
R2#debug arp
ARP packet debugging is on
R2#
R2#
R2#
R2#ping 10.0.0.1
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 10.0.0.1, timeout is 2 seconds:
.....
Success rate is 0 percent (0/5)
R2#

As you see nothing happened. I can’t ping R1 without a route. I’m going now to do one change in mask of R2 IP address:
 
R2#sh run int fa0/1
Building configuration...

Current configuration : 93 bytes
!
interface FastEthernet0/1
 ip address 10.0.1.2 255.255.255.0
 duplex auto
 speed auto
end

R2#
R2#conf t
Enter configuration commands, one per line.  End with CNTL/Z.
R2(config)#int fa0/1
R2(config-if)#ip add
R2(config-if)#ip address 10.0.1.2 255.255.0.0
R2(config-if)#end
R2#
*Jan 15 01:48:22.866: ARP: flush cache for interface FastEthernet0/1, by 61B0D528
*Jan 15 01:48:22.870: IP ARP: sent rep src 10.0.1.2 ca01.18c4.0006,
                 dst 10.0.1.2 ffff.ffff.ffff FastEthernet0/1
*Jan 15 01:48:22.894: ARP: flushing ARP entries for interface FastEthernet0/1
*Jan 15 01:48:22.902: IP ARP: sent rep src 10.0.1.2 ca01.18c4.0006,
                 dst 10.0.1.2 ffff.ffff.ffff FastEthernet0/1
R2#
*Jan 15 01:48:23.990: %SYS-5-CONFIG_I: Configured from console by console
R2#

Now from R2 (10.0.1.2/16) perspective, the R1 subnet (10.0.0.1/24) is in its range. Let’s try to ping R1 once again:
 
R2#ping 10.0.0.1
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 10.0.0.1, timeout is 2 seconds:

*Jan 15 01:54:39.266: IP ARP: creating incomplete entry for IP address: 10.0.0.1 interface FastEthernet0/1
*Jan 15 01:54:39.266: IP ARP: sent req src 10.0.1.2 ca01.18c4.0006,
                 dst 10.0.0.1 0000.0000.0000 FastEthernet0/1
*Jan 15 01:54:39.318: IP ARP: rcvd rep src 10.0.0.1 ca02.1634.0006, dst 10.0.1.2 FastEthernet0/1.!!!!
Success rate is 80 percent (4/5), round-trip min/avg/max = 28/56/84 ms
R2#
R2#ping 10.0.0.1
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 10.0.0.1, timeout is 2 seconds:
!!!.!
Success rate is 80 percent (4/5), round-trip min/avg/max = 36/58/76 ms
R2#

So, now we are able to reach R1 without any routing towards it. Let’s analyze what happened.

The first message it is ARP request:
 
*Jan 15 01:54:39.266: IP ARP: sent req src 10.0.1.2 ca01.18c4.0006,
                 dst 10.0.0.1 0000.0000.0000 FastEthernet0/1

and then we received respond from R3:
 
*Jan 15 01:54:39.318: IP ARP: rcvd rep src 10.0.0.1 ca02.1634.0006, dst 10.0.1.2 FastEthernet0/1.!!!!

but here we see the MAC address belongs to R3 (as the next hop), not R1:
 
R3#sh int fa0/1
FastEthernet0/1 is up, line protocol is up
  Hardware is i82543 (Livengood), address is ca02.1634.0006 (bia ca02.1634.0006)
  Internet address is 10.0.1.3/24

What we have seen here, it is proxy ARP. Sometimes it can be useful but in some cases very dangerous. You can need it for some hosts which don’t accept subnets (only class full addressing) but I’m not sure if it is still a problem nowadays. I’m more concern about this feature rather than excited. Let’s check what is needed to turn it off.

On R3 fa0/1 interface we can see:
 
R3#sh run all | b interface FastEthernet0/1
interface FastEthernet0/1
 mtu 1500
 ip address 10.0.1.3 255.255.255.0
 ip redirects
 ip unreachables
 ip proxy-arp
...

and also in the global settings:
 
R3#sh run all | i ip arp proxy
no ip arp proxy disable
R3#

You can disable the feature per interface or in the global settings, depends on your needs. Of course you can leave it and use it. Definitely you should turn it off on your edge (WAN) router. The important thing is to understand how your current settings work and take own decision.
Labels:

Comments

Post a Comment

Popular posts from this blog

What should you know about HA 'override enabled' setting on Fortigate?

High availability is mandatory in most of today's network designs. Only very small companies or branches can run their business without redundancy. When you have Fortigate firewall in your network you have many options to increase network availability. You can use Fortigate Clustering Protocol ( FGCP ) or Virtual Router Redundancy Protocol ( VRRP ). FGCP has two modes: 'override' disabled (default) and 'override' enabled . I'm not going to explain how to set up HA as you can find many resources on Fortinet websites: https://cookbook.fortinet.com/high-availability-two-fortigates-56/ https://cookbook.fortinet.com/high-availability-with-fgcp-56/ Let's recap what is the main difference between them. The default HA setting is 'override' disabled and this is an order of selection an active unit: 1) number of monitored interfaces - when both units have the same number of working (up) interfaces check next parameter 2) HA uptime - an ...
8 comments
Read more

FortiGate and GRE tunnel

Recently I worked on one project where a client requested to re-route web traffic to the GRE tunnel to perform traffic inspection. I would like to share with you what is required if you configure it on FortiGate. We need a new GRE interface and policy base routing (PBR) to change the route for specific source IPs. Of course you need firewall policies to permit the traffic. Let's start with GRE interface. Unfortunately you can't configure it using the GUI, only CLI is the option: config system gre-tunnel edit "gre1" set interface "port1" set local-gw 55.55.55.55 set remote-gw 44.44.44.44 next end When the end peer is Cisco router, you need to set the IP for the GRE interface: config system interface edit gre1 set ip 192.168.10.10 255.255.255.255 set remote-ip192.168.10.20 end In next step we need to fix routing. We need the alternate path via GRE but to keep the route in the active routing table you need to set the same AD (adminis...
Post a Comment
Read more

Inpection of asymmetric sessions on FortiGate

There is one feature available on FortiGate, and I think you should know it, as it modifies a bit what we know about stateful firewalls. In past every packet was treated individually and you had to create policies in both directions. With stateful firewalls we can track connections, and by checking couple of attributes, we can treat them as part of the same session. For example when you initiate connection from a host1 to host2, the returning connection from host2 to host1 will be treated as part of the same connection (session). They have to have the same source/destination and destination/source IPs, port numbers and interfaces.There is an exception from this rule and FortiGate in some specific cases can accept connections on port which was not used in the initial connection. Let me explain how it works on the below example:      The host1 has a default gateway on R1 (10.0.1.2), but you may notice that it is not the optimal path to host2 subnet. When we analyze ...
1 comment
Read more