tinc - Feb 2016 - 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

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

On 2/16/2016 9:04 AM, Eric Yau wrote:
> 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.
Here's an example of firewall rules I run in my home router.  I've named
the interface 'tinc' in my case.

iptables -I INPUT -p udp --dport 655 -j ACCEPT
iptables -I INPUT -p tcp --dport 655 -j ACCEPT
iptables -I INPUT -i tinc -j ACCEPT
iptables -I FORWARD -i tinc -j ACCEPT

Cheers,
Lance

Hi Eric,

> Once I modify the firewall FORWARD rule to ACCEPT.
you should probably take a closer look at the openwrt firewall documentation
[1].
As you already noticed "ACCEPT" is surely not a good idea since it
allows
traffic from the specified firewall zone to _all_ zones.
Instead you should edit the firewall zone (e.g. via the web interface) and add
the target network (your tinc vpn) as an allowed destination zone.
I assume that you already assigned a new zone to your tinc network interface.

Lars

[1] http://wiki.openwrt.org/doc/uci/firewall

Dear Lance,

It is not work. Any idea?

Regards,
Eric

-----Original Message-----
From: Lance Fredrickson [mailto:lancethepants at gmail.com] 
Sent: Wednesday, February 17, 2016 12:53 AM
To: tinc at tinc-vpn.org
Subject: Re: Tinc Router Mode - PING RESULT is destination host unreachable

On 2/16/2016 9:04 AM, Eric Yau wrote:
> 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.
Here's an example of firewall rules I run in my home router.  I've named
the
interface 'tinc' in my case.

iptables -I INPUT -p udp --dport 655 -j ACCEPT iptables -I INPUT -p tcp
--dport 655 -j ACCEPT iptables -I INPUT -i tinc -j ACCEPT iptables -I
FORWARD -i tinc -j ACCEPT

Cheers,
Lance