Showing posts with label ARP. Show all posts
Showing posts with label ARP. Show all posts

Saturday, February 22, 2020

DAI (Dynamic ARP Inspection)

Dynamic ARP Inspection (DAI) is a security feature that protects ARP (Address Resolution Protocol) which is vulnerable to an attack like ARP poisoning.
DAI checks all ARP packets on untrusted interfaces, it will compare the information in the ARP packet with the DHCP snooping database and/or an ARP access-list. If the information in the ARP packet doesn’t matter, it will be dropped. In this lesson I’ll show you how to configure DAI. Here’s the topology we will use:
dynamic arp inspection topology
Above we have four devices, the router on the left side called “host” will be a DHCP client, the router on the right side is our DHCP server and on top we have a router that will be used as an attacker. The switch in the middle will be configured for dynamic ARP inspection.

Configuration



We’ll start with the switch, first we need to make sure that all interfaces are in the same VLAN:
SW1(config)#interface range fa0/1 - 3
SW1(config-if-range)#switchport mode access
SW1(config-if-range)#switchport access vlan 123
SW1(config-if-range)#spanning-tree portfast
Now we can configure DHCP snooping:
SW1(config)#ip dhcp snooping 
SW1(config)#ip dhcp snooping vlan 123
SW1(config)#no ip dhcp snooping information option 
The commands above will enable DHCP snooping globally, for VLAN 123 and disables the insertion of option 82 in DHCP packets. Don’t forget to make the interface that connects to the DHCP server trusted:
SW1(config)#interface FastEthernet 0/3
SW1(config-if)#ip dhcp snooping trust 
The switch will now keep track of DHCP messages. Let’s configure a DHCP server on the router on the right side:
DHCP(config)#ip dhcp pool MY_POOL
DHCP(dhcp-config)#network 192.168.1.0 255.255.255.0
That’s all we need, let’s see if the host is able to get an IP address:
HOST(config)#interface FastEthernet 0/0
HOST(config-if)#ip address dhcp 
A few seconds later we see this message:
%DHCP-6-ADDRESS_ASSIGN: Interface FastEthernet0/0 assigned DHCP address 192.168.1.1, mask 255.255.255.0, hostname HOST
Let’s check if our switch has stored something in the DHCP snooping database:
SW1#show ip dhcp snooping binding 
MacAddress          IpAddress        Lease(sec)  Type           VLAN  Interface
------------------  ---------------  ----------  -------------  ----  --------------------
00:1D:A1:8B:36:D0   192.168.1.1      86330       dhcp-snooping   123   FastEthernet0/1
Total number of bindings: 1
There it is, an entry with the MAC address and IP address of our host. Now we can continue with the configuration of DAI. There’s only one command required to activate it:
SW1(config)#ip arp inspection vlan 123
The switch will now check all ARP packets on untrusted interfaces, all interfaces are untrusted by default. Let’s see if this will work or not…I’ll configure the IP address of our host on our attacker:
ATTACK(config)#interface FastEthernet 0/0
ATTACK(config-if)#ip address 192.168.1.1 255.255.255.0
Now let’s see what happens when we try to send a ping from the attacker to our DHCP router:
ATTACK#ping 192.168.1.254
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 192.168.1.254, timeout is 2 seconds:
.....
Success rate is 0 percent (0/5)
The ping is failing…what does our switch think of this?
SW1#
%SW_DAI-4-DHCP_SNOOPING_DENY: 1 Invalid ARPs (Req) on Fa0/2, vlan 123.([0017.5aed.7af0/192.168.1.1/0000.0000.0000/192.168.1.254/01:20:08 UTC Tue Mar 2 1993])
%SW_DAI-4-DHCP_SNOOPING_DENY: 1 Invalid ARPs (Req) on Fa0/2, vlan 123.([0017.5aed.7af0/192.168.1.1/0000.0000.0000/192.168.1.254/01:20:10 UTC Tue Mar 2 1993])
%SW_DAI-4-DHCP_SNOOPING_DENY: 1 Invalid ARPs (Req) on Fa0/2, vlan 123.([0017.5aed.7af0/192.168.1.1/0000.0000.0000/192.168.1.254/01:20:10 UTC Tue Mar 2 1993])
%SW_DAI-4-DHCP_SNOOPING_DENY: 1 Invalid ARPs (Req) on Fa0/2, vlan 123.([0017.5aed.7af0/192.168.1.1/0000.0000.0000/192.168.1.254/01:20:10 UTC Tue Mar 2 1993])
Above you can see that all ARP requests from our attacker are dropped. The switch checks the information found in the ARP request and compares it with the information in the DHCP snooping database. Since it doesn’t match, these packets are discarded. You can find the number of dropped ARP packets with the following command:
SW1#show ip arp inspection 

Source Mac Validation      : Disabled
Destination Mac Validation : Disabled
IP Address Validation      : Disabled

 Vlan     Configuration    Operation   ACL Match          Static ACL
 ----     -------------    ---------   ---------          ----------
  123     Enabled          Active                         

 Vlan     ACL Logging      DHCP Logging      Probe Logging
 ----     -----------      ------------      -------------
  123     Deny             Deny              Off          

 Vlan      Forwarded        Dropped     DHCP Drops      ACL Drops
 ----      ---------        -------     ----------      ---------
  123              0              5              5              0

 Vlan   DHCP Permits    ACL Permits  Probe Permits   Source MAC Failures
 ----   ------------    -----------  -------------   -------------------
  123              0              0              0                     0

 Vlan   Dest MAC Failures   IP Validation Failures   Invalid Protocol Data
 ----   -----------------   ----------------------   ---------------------
          
 Vlan   Dest MAC Failures   IP Validation Failures   Invalid Protocol Data
 ----   -----------------   ----------------------   ---------------------
  123                   0                        0                       0
Above you see the number of drops increase. So far so good, our attacker has been stopped. We still have one problem though, let me first shut the interface on our attacker before we continue:
ATTACK(config)#interface FastEthernet 0/0
ATTACK(config-if)#shutdown
Let me show you what happens when we try to send a ping from the host to our DHCP router:
HOST#ping 192.168.1.254
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 192.168.1.254, timeout is 2 seconds:
.....
Success rate is 0 percent (0/5)
This ping is failing but why? We are not spoofing anything…here’s what the switch tells us:
SW1#
%SW_DAI-4-DHCP_SNOOPING_DENY: 1 Invalid ARPs (Res) on Fa0/3, vlan 123.([0016.c7be.0ec8/192.168.1.254/001d.a18b.36d0/192.168.1.1/01:24:48 UTC Tue Mar 2 1993])
%SW_DAI-4-DHCP_SNOOPING_DENY: 1 Invalid ARPs (Res) on Fa0/3, vlan 123.([0016.c7be.0ec8/192.168.1.254/001d.a18b.36d0/192.168.1.1/01:24:50 UTC Tue Mar 2 1993])
%SW_DAI-4-DHCP_SNOOPING_DENY: 1 Invalid ARPs (Res) on Fa0/3, vlan 123.([0016.c7be.0ec8/192.168.1.254/001d.a18b.36d0/192.168.1.1/01:24:52 UTC Tue Mar 2 1993])
%SW_DAI-4-DHCP_SNOOPING_DENY: 1 Invalid ARPs (Res) on Fa0/3, vlan 123.([0016.c7be.0ec8/192.168.1.254/001d.a18b.36d0/192.168.1.1/01:24:54 UTC Tue Mar 2 1993])
%SW_DAI-4-DHCP_SNOOPING_DENY: 1 Invalid ARPs (Res) on Fa0/3, vlan 123.([0016.c7be.0ec8/192.168.1.254/001d.a18b.36d0/192.168.1.1/01:24:56 UTC Tue Mar 2 1993])
Our switch is dropping ARP replies from the DHCP router to our host. Since the DHCP router has no idea how to reach the host, the ping is failing:
HOST#show ip arp
Protocol  Address          Age (min)  Hardware Addr   Type   Interface
Internet  192.168.1.1             -   001d.a18b.36d0  ARPA   FastEthernet0/0
Internet  192.168.1.254           0   Incomplete      ARPA
DHCP#show ip arp
Protocol  Address          Age (min)  Hardware Addr   Type   Interface
Internet  192.168.1.1             0   001d.a18b.36d0  ARPA   FastEthernet0/0
Internet  192.168.1.254           -   0016.c7be.0ec8  ARPA   FastEthernet0/0
Why is the switch dropping the ARP reply? The problem is that the DHCP router is using a static IP addresses. DAI checks the DHCP snooping database for all packets that arrive on untrusted interfaces, when it doesn’t find a match…the ARP packet is dropped. To fix this, we need to create a static entry for our DHCP router:
SW1(config)#arp access-list DHCP_ROUTER
SW1(config-arp-nacl)#permit ip host 192.168.1.254 mac host 0016.c7be.0ec8
First we create an ARP access-list with a permit statement for the IP address and MAC address of the DHCP router. Now we need to apply this to DAI:
SW1(config)#ip arp inspection filter DHCP_ROUTER vlan 123 ?     
  static  Apply the ACL statically
We use the ip arp inspection filter command for this but you have to be careful…if you use the “static” parameter then we tell the switch not to check the DHCP snooping database. It will only check our ARP access-list and when it doesn’t find an entry, the ARP packet will be dropped. Make sure you add the filter without the static parameter:
SW1(config)#ip arp inspection filter DHCP_ROUTER vlan 123
There we go. The switch will now check the ARP access-list first and when it doesn’t find a match, it will check the DHCP snooping database. Let’s try that ping again:
HOST#ping 192.168.1.254
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 192.168.1.254, timeout is 2 seconds:
.!!!!
Success rate is 80 percent (4/5), round-trip min/avg/max = 1/1/1 ms
Excellent our ping is now working because of the static entry for the DHCP router. Another way to deal with this issue is to configure the interface as trusted. DAI will allow all ARP packets on trusted interfaces:
SW1(config)#interface FastEthernet 0/3
SW1(config-if)#ip arp inspection trust
Anything else we can do with DAI? There are some additional security checks you can enable if you want:
SW1(config)#ip arp inspection validate ?
  dst-mac  Validate destination MAC address
  ip       Validate IP addresses
  src-mac  Validate source MAC address
Here’s what these options mean:
  • dst-mac: checks the destination MAC address in the Ethernet header against the target MAC address in the ARP packet. This check is performed for ARP replies. ARP replies with different MAC addresses will be dropped.
  • ip: checks for invalid and unexpected IP addresses. For example 0.0.0.0, 255.255.255.255 and multicast addresses.
  • src-mac: checks the source MAC address in the Ethernet header against the sender’s MAC address in the ARP packet. This check is performed for both ARP requests and replies. ARP packets with different MAC addresses will be dropped.
You can only enable one of these options at the same time. Here’s an example how to enable the dst-mac check:
SW1(config)#ip arp inspection validate dst-mac
Last but not least, we can also configure ARP rate-limiting. By default there is a limit of 15 pps for ARP traffic on untrusted interfaces. Here’s how you can change it:
SW1(config)#interface FastEthernet 0/1
SW1(config-if)#ip arp inspection limit rate 10
This interface now only allows 10 ARP packets per second.

Conclusion

That’s all we have for DAI (Dynamic ARP Inspection). It’s a nice security feature but make sure that you have ARP access-lists in place for all devices with static IP addresses before you enable this. You don’t want to block most of your traffic after enabling this.
hostname SW1
!
ip dhcp snooping vlan 123
no ip dhcp snooping information option
ip dhcp snooping
ip arp inspection vlan 123
ip arp inspection validate src-mac 
!
interface FastEthernet0/1
 switchport access vlan 123
 switchport mode access
 ip arp inspection limit rate 10
 spanning-tree portfast
!
interface FastEthernet0/2
 switchport access vlan 123
 switchport mode access
 spanning-tree portfast
!
interface FastEthernet0/3
 switchport access vlan 123
 switchport mode access
 ip arp inspection trust
 spanning-tree portfast
 ip dhcp snooping trust       
!
arp access-list DHCP_ROUTER
 permit ip host 192.168.1.254 mac host 0016.c7be.0ec8 
! end
hostname HOST
!
interface FastEthernet0/0
 ip address dhcp
 duplex auto
 speed auto
!end
hostname ATTACK
!
interface FastEthernet0/0
 ip address 192.168.1.2 255.255.255.0
 shutdown
 duplex auto
 speed auto
!
end
hostname DHCP
!
ip dhcp pool MY_POOL
 network 192.168.1.0 255.255.255.0
!
interface FastEthernet0/0
 ip address 192.168.1.254 255.255.255.0
 duplex auto
 speed auto
!
end
I hope you enjoyed this lesson, if you have any questions feel free to leave a comment below.

ARP Poisoning

The ARP (Address Resolution Protocol) is used to find the MAC address of any IP address that you are trying to reach on your local network, it’s a simple protocol and vulnerable to an attack called ARP poisoning (or ARP spoofing).
ARP poisoning is an attack where we send fake ARP reply packets on the network. There are two possible attacks:
  • MITM (Man in the middle): the attacker will send an ARP reply with its own MAC address and the IP address of a legitimate host, server or router. When the victim receives the ARP reply it will update its ARP table. When it tries to reach the legitimate device, the IP packets will end up at the attacker.
  • DOS (Denial of Service): the attacker will send many ARP replies with the MAC address of a legitimate server. All devices in the network will update their ARP tables and all IP packets in the network will be sent to the server, overloading it with traffic.

In this lesson we’ll take a look at a MITM attack performed through ARP poisoning, to demonstrate this we’ll use the following topology:
ARP Poisoning Example Topology
Above we have a switch that connects two computers and a router, which is used for Internet access. The computer on the left side is a Windows computer with a user browsing the Internet, the computer on the top is our attacker.

Traffic Pattern without ARP Poisoning

Let’s take a look at the MAC addresses and ARP tables of the host on the left side (192.168.1.1) and the router:
C:\Users\host1>ipconfig /all

Windows IP Configuration

   Host Name . . . . . . . . . . . . : vmware
   Primary Dns Suffix  . . . . . . . :
   Node Type . . . . . . . . . . . . : Hybrid
   IP Routing Enabled. . . . . . . . : No
   WINS Proxy Enabled. . . . . . . . : No

Ethernet adapter Ethernet0:

   Connection-specific DNS Suffix  . :
   Description . . . . . . . . . . . : Intel(R) 82574L Gigabit Network Connection
   Physical Address. . . . . . . . . : 00-50-56-8E-5E-33
   DHCP Enabled. . . . . . . . . . . : Yes
   Autoconfiguration Enabled . . . . : Yes
   Link-local IPv6 Address . . . . . : fe80::e8b4:ac21:751f:fa34%12(Preferred)
   IPv4 Address. . . . . . . . . . . : 192.168.1.1(Preferred)
   Subnet Mask . . . . . . . . . . . : 255.255.255.0
   Lease Obtained. . . . . . . . . . : Tuesday, October 6, 2015 1:46:34 AM
   Lease Expires . . . . . . . . . . : Wednesday, October 7, 2015 2:02:04 AM
   Default Gateway . . . . . . . . . : 192.168.1.254
   DHCP Server . . . . . . . . . . . : 192.168.1.254
   DHCPv6 IAID . . . . . . . . . . . : 251678806
   DHCPv6 Client DUID. . . . . . . . : 00-01-00-01-1D-13-64-E8-00-50-56-8E-5E-33
   DNS Servers . . . . . . . . . . . : 8.8.8.8
   NetBIOS over Tcpip. . . . . . . . : Enabled
Above you can see the MAC address and IP address of the host on the left side, this is a Windows 8 computer. The default gateway is 192.168.1.254 (R1). Here’s the ARP table:
C:\Users\host1>arp -a

Interface: 192.168.1.1 --- 0xc
  Internet Address      Physical Address      Type
  192.168.1.254         00-22-90-35-64-8a     dynamic
The output above is the IP address and MAC address of the router. We can verify the MAC address of the router like this:
R1#show interfaces FastEthernet 0/0 | include bia
  Hardware is Gt96k FE, address is 0022.9035.648a (bia 0022.9035.648a)
And here’s the ARP table of the router with an entry for the host on the left side:
R1#show ip arp | include 192.168.1.1
Internet  192.168.1.1             8   0050.568e.5e33  ARPA   FastEthernet0/0
This is how it should be, our traffic pattern looks like this:
ARP poisoning normal internet flow
Now let’s see what happens when we perform an ARP poisoning attack…

Traffic Pattern with ARP Poisoning

There are a number of tools you can use for ARP poisoning, I decided to use Kali which is a great Linux distribution with plenty of security tools. Kali comes with an application called Ettercap which offers a couple of MITM (Man in the Middle) attacks.
Do yourself a favor and never try ARP poisoning on any production network, you should always use a lab environment to test any security tools. There are methods to detect ARP poisoning which we will cover in the DAI (Dynamic ARP Inspection) lesson.
I will launch Ettercap on the host with IP address 192.168.1.2. Before we launch Ettercap, there’s a couple of configuration changes we have to make. First open the etter.conf file:
# vim /etc/ettercap/etter.conf
Now change the “ec_uid” and “ec_gid” values to 0:
[privs]
ec_uid = 0          
ec_gid = 0
These values allow Ettercap to get root access which is required to open network sockets. Also make sure that you have the following two rules in your etter.conf file:
redir_command_on = "iptables -t nat -A PREROUTING -i %iface -p tcp --dport %port -j REDIRECT --to-port %rport"
redir_command_off = "iptables -t nat -D PREROUTING -i %iface -p tcp --dport %port -j REDIRECT --to-port %rport"
The lines above are required so that Kali will forward IP packets. After saving your changes you can start Ettercap:
# ettercap -G
You will be greeted with the following screen:
ettercap main screen
Open the “Sniff” menu and select “Unified sniffing”:
ettercap unified sniffing
Select your interface and click “OK”:
ettercap sniff select interface
Now open the “Hosts” menu and select “Hosts list”:
ettercap hosts list
It should show you the following screen:
ettercap hosts list
Above you can see our host (192.168.1.1) and our router (192.168.1.254), we can ignore the IPv6 address. Now open the “Mitm” menu and select ARP poisoning:
ettercap arp poisoning
Select the “Sniff remote connections” option. This means that Ettercap will send ARP replies to the host and the router:
ettercap arp poisoning sniff remote connections
Once you have clicked OK, Ettercap will start sending ARP replies. This is what it looks like in Wireshark:
ettercap arp reply to host
Above you can see the ARP reply that it sent towards the host, the sender MAC address is of the attacker and the sender IP address is from the router. Here’s the ARP reply that it sends to the router:
ettercap arp reply to router
Above we see the sender MAC address which is the attacker and the sender IP address is the host.
Once our host and router receives these ARP replies, they will update their ARP tables:
C:\Users\host1>arp -a

Interface: 192.168.1.1 --- 0xc
  Internet Address      Physical Address      Type
  192.168.1.254         00-50-56-8e-ee-89     dynamic
R1#show ip arp | include 192.168.1.1
Internet  192.168.1.1             0   0050.568e.ee89  ARPA   FastEthernet0/0
Above you see the MAC address of the attacker in both entries in the ARP tables. We can verify the MAC address of the attacker with the ifconfig command:
# ifconfig eth0
eth0      Link encap:Ethernet  HWaddr 00:50:56:8e:ee:89  
          inet addr:192.168.1.2  Bcast:192.168.1.255  Mask:255.255.255.0
          inet6 addr: fe80::250:56ff:fe8e:ee89/64 Scope:Link
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:342507 errors:0 dropped:0 overruns:0 frame:0
          TX packets:340164 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000 
          RX bytes:309578070 (295.2 MiB)  TX bytes:303335663 (289.2 MiB)
Our traffic pattern now looks like this:
ARP poisoning traffic flow
Our MITM attack is successful, all traffic now flows through the attacker’s computer. It’s up to your imagination what kind of bad stuff you want to do now…let me give you an example, Kali has an application called “driftnet” that shows you all images that are requested. Let’s start it on the attacker’s computer:
# driftnet -i eth0
On the victim’s computer I visited Cisco.com and opened a few pages, here’s what driftnet shows us:
driftnet examples
Above you see a nice overview with some of the images on the Cisco website. This is a fun example but there are also applications that let you capture authentication information for protocols like FTP, POP3, etc.

Conclusion

ARP poisoning is something you definitely don’t want to see on your network. How do we stop or prevent this? You can use static ARP entries on certain devices or you can use DAI (Dynamic ARP Inspection) which is a feature on Cisco Catalyst switches that detects and mitigates ARP poisoning. This is something I will show you in the next lesson.
Want to take a look at the wireshark captures from Ettercap?
ARP Poisoning PCAP file
I hope you enjoyed this lesson, if you have any questions feel free to leave a comment.

Thursday, February 20, 2020

Proxy ARP Explained

Most networking students are familiar with ARP (Address Resolution Protocol) but Proxy ARP doesn’t always ring a bell. In this tutorial I will explain how proxy ARP works, we’ll use the following topology for this:
Proxy Arp Topology
In the example above we have two subnets: 10.1.1.0 /24 and 10.2.2.0 /24. The router in the middle is connected to both subnets. On the bottom you see two hosts (H1 and H2) and on top we have a server (S1).
When you take a close look at the hosts you can see that H1 has a /24 subnet mask and H2 has a /8 subnet mask. When H1 tries to reach the server at 10.2.2.100 the following will happen:
  1. H1 compares its IP address and subnet mask to the IP address of the server (10.2.2.100) and decides that the server is in another subnet.
  2. H1 decides to send the packet for the server to its default gateway (10.1.1.254).
  3. H1 checks its ARP table to see if there is an entry for 10.1.1.254, if not it will send an ARP request.
  4. The router will respond to the ARP request, sending its MAC address of its FastEthernet 0/0 interface.
This is how ARP works normally, when H2 tries to send an IP packet towards the server something else will happen:
  1. H2 compares its IP address and subnet mask to the IP address of the server (10.2.2.100) and decides that the server is in the same subnet.
  2. H2 checks its ARP table to see if there is an entry for 10.2.2.100, if not it will send an ARP request.
The server however is not on the 10.1.1.0 /24 subnet and routers do not forward broadcast traffic so the ARP request never makes it to the server. All hope is not lost however….this is where proxy ARP comes to the rescue!
When proxy ARP is enabled on the router, this is what happens:
  1. The router sees the ARP request from H2 on the 10.1.1.0 /24 subnet and sees that this is an ARP request for something in the 10.2.2.0 /24 subnet.
  2. The router realizes that it knows how to reach the 10.2.2.0 /24 subnet and decides to respond to the ARP request in order to help H2.
  3. The router sends an ARP reply to H2 with its MAC address on the FastEthernet 0/0 interface.
Are you following me so far? Let me show you what this looks like on a real router.

Configuration

I will use the following topology to demonstrate proxy ARP:
Proxy Arp Lab Topology
It’s the same as the picture as I just showed you but I am using the routers in my lab. By disabling “ip routing” I can turn the routers into ordinary host devices. Let’s start by disabling routing on R1, R2 and the server:
H1, H2 & S1(config)#
no ip routing
Let’s configure the default gateway on those devices:
H1 & H2(config)#
ip default-gateway 10.1.1.254
S1(config)#ip default-gateway 10.2.2.254
Let’s configure all the IP addresses that we require:
H1(config)#interface fastEthernet 0/0
H1(config-if)#ip address 10.1.1.1 255.255.255.0
H2(config)#interface fastEthernet 0/0
H2(config-if)#ip address 10.1.1.2 255.0.0.0
S1(config)#interface FastEthernet 0/0
S1(config-if)#ip address 10.2.2.100 255.255.255.0
Note that I used the /8 subnet mask on H2 here. Here’s the router:
R1(config)#interface FastEthernet 0/0
R1(config-if)#ip address 10.1.1.254 255.255.255.0
R1(config-if)#interface FastEthernet 0/1
R1(config-if)#ip address 10.2.2.254 255.255.255.0
That’s all we have to configure…let’s verify our work!

Verification

To test proxy ARP I will first send some traffic from H1 to the server so you can see what normal ARP looks like, and then we will send some traffic from H2 to the server.
Proxy ARP is enabled by default as you can see here:
R1#show ip interface FastEthernet 0/0 | include Proxy
  Proxy ARP is enabled
To see in realtime what is going on, I will use the following debug on R1:
R1#debug arp
ARP packet debugging is on
Let’s send some pings from host A to the server:
H1#ping 10.2.2.100

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 10.2.2.100, timeout is 2 seconds:
.!!!!
Success rate is 80 percent (4/5), round-trip min/avg/max = 44/311/1068 ms
The ping is working, the first one failes because of some ARPs, you can see them in the debug below:
R1#
IP ARP: rcvd req src 10.1.1.1 c204.07ec.0000, dst 10.1.1.254 FastEthernet0/0
IP ARP: sent rep src 10.1.1.254 c206.13b8.0000,
                 dst 10.1.1.1 c204.07ec.0000 FastEthernet0/0
R1 receives an ARP request from H1 who is looking for the IP address of its default gateway and replies with its MAC address.
R1#
IP ARP: creating incomplete entry for IP address: 10.2.2.100 interface FastEthernet0/1
IP ARP: sent req src 10.2.2.254 c206.13b8.0001,
                 dst 10.2.2.100 0000.0000.0000 FastEthernet0/1
IP ARP: rcvd rep src 10.2.2.100 c207.13b8.0000, dst 10.2.2.254 FastEthernet0/1
Before R1 can deliver the packet to the server it has to know the MAC address of the server, so R1 does an ARP request and receives a reply from the server.
R1#
IP ARP: rcvd req src 10.2.2.100 c207.13b8.0000, dst 10.2.2.254 FastEthernet0/1
IP ARP: sent rep src 10.2.2.254 c206.13b8.0001,
                 dst 10.2.2.100 c207.13b8.0000 FastEthernet0/1
R1 also receives an ARP request from the server who is looking for the MAC address of its default gateway, a reply is sent with the MAC address of FastEthernet 0/1. Here’s what the ARP table of H1 looks like now:
H1#show ip arp
Protocol  Address          Age (min)  Hardware Addr   Type   Interface
Internet  10.1.1.1                -   c204.07ec.0000  ARPA   FastEthernet0/0
Internet  10.1.1.254              3   c206.13b8.0000  ARPA   FastEthernet0/0
H1 has saved the MAC address of its default gateway in the ARP table. What you have seen so far is just regular ARP.
Now we’ll see how proxy ARP works by looking at H2. To see the logic of H2 in action I will enable ARP debugging:
H2#debug arp
ARP packet debugging is on
Let’s ping the server:
H2#ping 10.2.2.100

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 10.2.2.100, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 36/249/1076 ms
Our ping is working and here’s the debug of H2:
H2#
IP ARP: creating incomplete entry for IP address: 10.2.2.100 interface FastEthernet0/0
IP ARP: sent req src 10.1.1.2 c205.07ec.0000,
                 dst 10.2.2.100 0000.0000.0000 FastEthernet0/0
IP ARP: rcvd rep src 10.2.2.100 c206.13b8.0000, dst 10.1.1.2 FastEthernet0/0
H2 sends an ARP request, looking for 10.2.2.100 and receives an ARP reply. Here’s what you will see on R1:
R1#
IP ARP: rcvd req src 10.1.1.2 c205.07ec.0000, dst 10.2.2.100 FastEthernet0/0
IP ARP: creating entry for IP address: 10.1.1.2, hw: c205.07ec.0000
IP ARP: sent rep src 10.2.2.100 c206.13b8.0000,
                 dst 10.1.1.2 c205.07ec.0000 FastEthernet0/0
R1 receives the ARP request, adds the MAC address / IP address of H2 to its own ARP table and sends an ARP reply to H2. This ARP reply contains its own MAC address and the IP address of the server. Let’s see what the ARP table of H2 looks like now:
H2#show ip arp
Protocol  Address          Age (min)  Hardware Addr   Type   Interface
Internet  10.1.1.2                -   c205.07ec.0000  ARPA   FastEthernet0/0
Internet  10.2.2.100              0   c206.13b8.0000  ARPA   FastEthernet0/0
You see the IP address of the server and the MAC address of R1, to verify this you can check the interface of R1 like this:
R1#show interface FastEthernet 0/0 | include address
  Hardware is Gt96k FE, address is c206.13b8.0000 (bia c206.13b8.0000)
  Internet address is 10.1.1.254/24
That’s all there is to it! I hope this example has been useful to you. If you have any questions feel free to leave a comment.