Eric, Tinc uses the 655 port if you have not changed it in the configuration file.
Regards, Ramses >-----Mensaje original----- >De: tinc [mailto:[email protected]] En nombre de Eric Yau >Enviado el: martes, 16 de febrero de 2016 17:04 >Para: [email protected] >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:[email protected]] >Sent: Sunday, February 14, 2016 8:59 PM >To: [email protected] >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 <[email protected]>: > >> 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 >[email protected] >http://www.tinc-vpn.org/cgi-bin/mailman/listinfo/tinc _______________________________________________ tinc mailing list [email protected] http://www.tinc-vpn.org/cgi-bin/mailman/listinfo/tinc
