Le mar. 15 janv. 2019 à 03:13, Lars Kruse <[email protected]> a écrit :
> Hello Julien, > > > Am Mon, 14 Jan 2019 22:15:47 +0100 > schrieb Julien dupont <[email protected]>: > > > > ** Test 1 ** > > On VPN_office I use 'tcpdump -npi any icmp and host 192.168.1.3' > > When pinging 192.168.1.1 from client 1, with no success, I see no packet > > passing. > > Sorry - the tcpdump command should end with "192.168.1.1" instead of > "192.168.1.3". > (everything following "any" is a filter for the interesting traffic) > > Yes obviously. In that case I see: IP 172.16.0.3 > 192.168.1.1: ICMP echo request, id2135, seq1, length 64 IP 172.16.0.3 > 192.168.1.1: ICMP echo request, id2135, seq2, length 64 IP 172.16.0.3 > 192.168.1.1: ICMP echo request, id2135, seq3, length 64 Packet goes through but no PONG back if I understand correctly. That's probably where it goes wrong. > > > When pinging 192.168.1.3 from client 1, with success, I see packet > passing: > > IP 172.16.0.3 > 192.168.1.3: ICMP echo request, id 2648, seq 23, length > 64 > > IP 192.168.1.3 > 172.16.0.3: ICMP echo request, id 2648, seq 23, length > 64 > > ... > > OK. As you said, this works. > > > > ** Test 2 * > > I use a machine from the office LAN with IP 192.168.1.100 to ping > > VPN_office (172.16.0.2), VPN_out (172.16.0.1) and VPN_client > (172.16.0.3) - > > I can't access the router right now. They all work. Here is the output of > > VPN_client: > > > ping 172.16.0.3 > > PING 172.16.0.3 (172.16.0.3) 56(84) bytes of data. > > From 192.168.1.1 icmp_seq=2 Redirect Host (New nexthop: 192.168.1.3) > > From 192.168.1.1: icmp_seq=2 Redirect Host (New nexthop: 192.168.1.3) > > ... > > > > This is the result of the traffic redirection rule I put in the router. > > OK. So the route is properly configured on your router. > > Now you should check whether such a ping results in the expected traffic. > E.g. you could execute "tcpdump -npi any icmp" on 192.168.1.3. Here you > should > see incoming packets from 192.168.1.100 and (a few milliseconds later) > forwarded > packets towards the VPN. If this works, then you could check, whether the > forwarded traffic really goes into the tinc VPN > (e.g. "tcpdump -npi YOUR_TINC_INTERFACE icmp"). > If everything goes well, then you can check, whether your tinc node on the > other side also sees the expected traffic (using tcpdump on "any" interface > again): incoming as well as forwarded. Play around with the selected > network > interface for tcpdump on different hosts until you understand, where your > packets get lost. > > On VPN_office 'tcdump -npi any icmp', on 192.168.1.100 'ping 172.16.0.3': 192.168.1.100 > 172.16.0.3: ICMP echo request, id 11452, seq1, length 64 192.168.1.100 > 172.16.0.3: ICMP echo request, id 11452, seq2, length 64 192.168.1.100 > 172.16.0.3: ICMP echo request, id 11452, seq3, length 64 ... Does that mean there is no PONG back? On VPN_office 'tcdump -npi any icmp', on 192.168.1.100 'ping 172.16.0.2' (VPN_office): 192.168.1.100 > 172.16.0.2: ICMP echo request, id 40111, seq1, length 64 172.16.0.2 > 192.168.1.100: ICMP echo reply, id 40111, seq1, length 64 > Happy packet hunting! > > Cheers, > Lars > > PS: currently you are using the two of the most popular private IP ranges > (172.16.0.0/24 and 192.168.1.0/24) for your two networks. This will > inevitably > cause problems as soon as people want to work within these networks from > home > (e.g. via a VPN). Maybe this is the right time to change these subnets into > something less widely used? > _______________________________________________ > tinc mailing list > [email protected] > https://www.tinc-vpn.org/cgi-bin/mailman/listinfo/tinc >
_______________________________________________ tinc mailing list [email protected] https://www.tinc-vpn.org/cgi-bin/mailman/listinfo/tinc
