Tinc Router Mode - PING RESULT is destination host unreachable

Lars Kruse lists at sumpfralle.de
Sun Feb 14 13:58:44 CET 2016


Hi Eric,

Am Sun, 14 Feb 2016 01:26:22 +0800
schrieb Eric Yau <ericyaukhy at hotmail.com>:

> I have no experience to use tcpdump, here is the output from TCPdump for
> your reference. Any idea?

A good start for understanding tcpdump is to imagine beforehand which packets
you do expect (request, response with source and target addresses).


> Use my home PC to ping company PC
> 
> 01:00:25.154706 ethertype IPv4, IP 192.168.1.2 > 10.0.0.2: ICMP echo
> request, id 1, seq 17, length 40
> 01:00:25.154706 IP 192.168.1.2 > 10.0.0.2: ICMP echo request, id 1, seq 17,
> length 40
> 01:00:25.154706 IP 192.168.1.2 > 10.0.0.2: ICMP echo request, id 1, seq 17,
> length 40
> 01:00:25.155177 IP 192.168.1.1 > 192.168.1.2: ICMP 10.0.0.2 protocol 1 port
> 19786 unreachable, length 68
> 01:00:25.155225 IP 192.168.1.1 > 192.168.1.2: ICMP 10.0.0.2 protocol 1 port
> 19786 unreachable, length 68

I understand the packets above like this:
* 192.168.1.2 sends a packet via 192.168.1.1 to 10.0.0.2 (according to your
  network graph)
* It is a bit confusing, that the same packet passes twice through the host
  that is watching the traffic. I am not sure about this.
* 192.168.1.1 sends an "unreachable" reply. Thus 192.168.1.1 is the crucial
  point of misconfiguration - either due to routing, firewalling or physical
  disconnection.
* Since the "unreachable" packets are returned quite quickly (within a few
  milliseconds) I assume that 192.168.1.1 did not even try to reach 10.0.0.2 -
  thus it is probably a firewalling issue.

I am not sure, at which position / on which host you recorded the tcpdump
output. Next time you could add this information, as well.


> Use OpenWrt router to ping
> 
> [..]
>
> 01:17:24.715863 IP 10.0.0.1 > 10.0.0.2: ICMP echo request, id 25125, seq 0,
> length 64
> 01:17:24.867369 IP 10.0.0.2 > 10.0.0.1: ICMP echo reply, id 25125, seq 0,
> length 64

This proves the 10.0.0.1 can reach 10.0.0.2 and vice versa.


> 01:17:37.717665 IP 10.0.0.1 > 192.168.2.1: ICMP echo request, id 25381, seq
> 0, length 64
> 01:17:37.915851 IP 192.168.2.1 > 10.0.0.1: ICMP echo reply, id 25381, seq 0,
> length 64

Same connection as above - but with different IPs - it works.


> Use company PC to ping
> 
> 01:23:05.211811 IP 10.0.0.2 > 192.168.1.1: ICMP echo request, id 1, seq
> 2853, length 40
> 01:23:05.212180 IP 192.168.1.1 > 10.0.0.2: ICMP echo reply, id 1, seq 2853,
> length 40

Same connection as above - but with different IPs - it works.


> 01:23:16.165304 IP 10.0.0.2 > 10.0.0.1: ICMP echo request, id 1, seq 2857,
> length 40
> 01:23:16.165707 IP 10.0.0.1 > 10.0.0.2: ICMP echo reply, id 1, seq 2857,
> length 40

Already tested above, as well.


> 01:23:29.808414 IP 10.0.0.2 > 192.168.1.2: ICMP echo request, id 1, seq
> 2865, length 40
> 01:23:29.808828 IP 10.0.0.1 > 10.0.0.2: ICMP 192.168.1.2 protocol 1 port
> 16938 unreachable, length 68

Again: the openwrt router (192.168.1.1) denies packets between 192.168.2.1 and
192.168.1.2 - this time from the other direction.

Thus 192.168.1.1 seems to cause the problem. Probably you did not allow the
traffic flow that you are going after.
This should be strictly an firewalling or openwrt issue. You should check your
firewall zones (as openwrt calls it) and the allowed packet flows between these
zones.

Cheers,
Lars


More information about the tinc mailing list