Tinc Router Mode - PING RESULT is destination host unreachable

[Eric Yau]

Hi Lars,

Once I modify the firewall FORWARD rule to ACCEPT. I can ping and access my
company PC at home. All traffic can pass through that. But I think it is not
a good practice to change the FORWARD rule to ACCEPT. Any idea to check and
just allow the tinc VPN traffic only? Instead of allow everything pass
through the FORWARD rule.

Regards,
Eric

-----Original Message-----
From: Lars Kruse [mailto:lists at sumpfralle.de] 
Sent: Sunday, February 14, 2016 8:59 PM
To: tinc at tinc-vpn.org
Subject: Re: Tinc Router Mode - PING RESULT is destination host unreachable

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