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
