Eric Yau
2016-Feb-16 16:04 UTC
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 68I 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 64This 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 64Same 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 40Same 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 40Already 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 68Again: 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
Ramses II
2016-Feb-16 16:21 UTC
Tinc Router Mode - PING RESULT is destination host unreachable
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 isnot 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 passthrough>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 orphysical> 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 reach10.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 checkyour>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
Lance Fredrickson
2016-Feb-16 16:52 UTC
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
Lars Kruse
2016-Feb-16 23:11 UTC
Tinc Router Mode - PING RESULT is destination host unreachable
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
Eric Yau
2016-Feb-17 16:52 UTC
Tinc Router Mode - PING RESULT is destination host unreachable
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
Apparently Analagous Threads
- Tinc Router Mode - PING RESULT is destination host unreachable
- Tinc Router Mode - PING RESULT is destination host unreachable
- Tinc Router Mode - PING RESULT is destination host unreachable
- Tinc Router Mode - PING RESULT is destination host unreachable
- Tinc Router Mode - PING RESULT is destination host unreachable