4

Summary of the problem: a ping from client does not go to rpi1, its ARP call is not answerd at srv.

enter image description here

  • host0and tap0 are bridged by br0.
  • vpninand lan0 are two independent interfaces.
  • All traffic between the interfaces is allowed on srv (IP forwading is enabled and I have successful traffic between rpi1 and other interfaces not visible here, among others one which is the gateway to Internet)

Details: client successfully pings itself (10.20.1.2), 10.20.1.1, 10.20.1.254 and 10.10.10.254. When trying to ping 10.10.10.11:

root@client:~# ping 10.10.10.11
PING 10.10.10.11 (10.10.10.11) 56(84) bytes of data.
From 10.20.1.1: icmp_seq=2 Redirect Host(New nexthop: 10.10.10.11)
From 10.20.1.1 icmp_seq=1 Destination Host Unreachable
From 10.20.1.2 icmp_seq=3 Destination Host Unreachable
From 10.20.1.2 icmp_seq=4 Destination Host Unreachable
From 10.20.1.2 icmp_seq=5 Destination Host Unreachable

Please note the flip-flap in the From, between 10.20.1.1 and 10.20.1.2.

When running a tcpdumpon srv (where the ping ability is lost) I see ARP requests, but no replies:

root@srv ~# tcpdump -i vpnin -nn
17:10:54.463072 ARP, Request who-has 10.10.10.11 tell 10.20.1.1, length 28
17:10:55.459489 ARP, Request who-has 10.10.10.11 tell 10.20.1.1, length 28
17:10:56.459459 ARP, Request who-has 10.10.10.11 tell 10.20.1.1, length 28
17:10:56.473683 ARP, Request who-has 10.10.10.11 tell 10.20.1.2, length 28
17:10:57.469788 ARP, Request who-has 10.10.10.11 tell 10.20.1.2, length 28
17:10:58.469608 ARP, Request who-has 10.10.10.11 tell 10.20.1.2, length 28

Again, both 10.20.1.1 and 10.20.1.2 request an answer.

The ARP table on srv does have an answer

root@srv ~# arp -a
(...)
rpi1.10.in-addr.arpa (10.10.10.11) at f4:f2:6d:09:35:1b [ether] on lan0

What can be the reason

  • for the lack of reply?
  • and for this strange switch between 10.20.1.1 and 10.20.1.2?
WoJ
  • 3,607
  • 9
  • 49
  • 79

1 Answers1

5

ARP only works on the same LAN (layer-2 broadcast domain) because an ARP request is a broadcast. Broadcasts do not cross a layer-3 boundary. MAC addresses are layer-2 addresses, and they are only significant, or even seen, on the same layer-2 broadcast domain.

A host wishing to send traffic to a different layer-3 network will send the traffic to the layer-2 address of its configured gateway, using ARP to find the layer-2 address of its configured gateway, if necessary. Then, it is the responsibility of the configured gateway to get the traffic to the next hop on the path to the destination.

If the traffic is supposed to be routed to a different network, you need to configure the gateway on the hosts to be the addresses in the layer-3 networks where the hosts exist, at the point where the networks meet (srv). The configured gateway for client should be 10.20.1.254, and the configured gateway for rp1 should be 10.10.10.254.

Ron Maupin
  • 3,243
  • 1
  • 12
  • 20
  • The configured gateway for client should be `10.20.1.254`. This. Thank you, I realized that I automatically set the gateway to `10.20.1.1`. This explains how "far" the ping was going. As a side note: would you know the reason for the flip-flap between `10.20.1.1` and `10.20.1.2` in my incorrect setup? – WoJ Jul 15 '16 at 18:44
  • That's because `client` at `10.20.1.2` was sending the traffic for the other network to its configured gateway at `10.20.1.1`, and the configured gateway had no idea where to find the other network. – Ron Maupin Jul 15 '16 at 18:54