Tinc Router Mode - PING RESULT is destination host unreachable

[Ramses II]

Eric, Tinc uses the 655 port if you have not changed it in the configuration
file.


Regards,

Ramses

>-----Mensaje original-----
>De: tinc [mailto:tinc-bounces at tinc-vpn.org] En nombre de Eric Yau
>Enviado el: martes, 16 de febrero de 2016 17:04
>Para: tinc at tinc-vpn.org
>Asunto: RE: Tinc Router Mode - PING RESULT is destination host unreachable
>
>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
>
>_______________________________________________
>tinc mailing list
>tinc at tinc-vpn.org
>http://www.tinc-vpn.org/cgi-bin/mailman/listinfo/tinc