Hi Julien, Am Mon, 14 Jan 2019 18:04:40 +0100 schrieb Julien dupont <marcelvierzon at gmail.com>:> Investigating with tcpdump withoug guidelines is beyond my skills I'm > afraid.Try this on your VPN_office host: tcpdump -npi any icmp and host 192.168.1.3 In parallel you start a ping from the other network: ping 192.168.1.1 I assume, that tcpdump will show all packets from your source. Probably you will see two packets each (with a slight delay of a few milliseconds). These are the packets forwarded to the outgoing interface. Furthermore I assume, that you do not see any return traffic. Feel free to share a few lines of seemingly relevant output from tcpdump with us. Another (unrelated) test: Please run "ping SOME_IP_FROM_THE_OTHER_NETWORK" on 192.168.1.1. Please share the output with us. I assume, that the packet goes out via your WAN (instead of flowing towards 192.168.1.3) and is thus rightfully rejected.> I used tinc in router mode because it is proposed like in most howto I > found... Would just switching to switch mode makes things easier or that's > not related?No, router mode should be fine for your purpose. Cheers, Lars
Hi Lars, Thanks for the help ** 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. 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 ... ** 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.3PING 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. Le lun. 14 janv. 2019 à 19:43, Lars Kruse <lists at sumpfralle.de> a écrit :> Hi Julien, > > > Am Mon, 14 Jan 2019 18:04:40 +0100 > schrieb Julien dupont <marcelvierzon at gmail.com>: > > > Investigating with tcpdump withoug guidelines is beyond my skills I'm > > afraid. > > Try this on your VPN_office host: > tcpdump -npi any icmp and host 192.168.1.3 > In parallel you start a ping from the other network: > ping 192.168.1.1 > > I assume, that tcpdump will show all packets from your source. Probably you > will see two packets each (with a slight delay of a few milliseconds). > These > are the packets forwarded to the outgoing interface. > Furthermore I assume, that you do not see any return traffic. > > Feel free to share a few lines of seemingly relevant output from tcpdump > with > us. > > Another (unrelated) test: > Please run "ping SOME_IP_FROM_THE_OTHER_NETWORK" on 192.168.1.1. > Please share the output with us. > I assume, that the packet goes out via your WAN (instead of flowing towards > 192.168.1.3) and is thus rightfully rejected. > > > > I used tinc in router mode because it is proposed like in most howto I > > found... Would just switching to switch mode makes things easier or > that's > > not related? > > No, router mode should be fine for your purpose. > > Cheers, > Lars > _______________________________________________ > tinc mailing list > tinc at tinc-vpn.org > https://www.tinc-vpn.org/cgi-bin/mailman/listinfo/tinc >-------------- next part -------------- An HTML attachment was scrubbed... URL: <http://www.tinc-vpn.org/pipermail/tinc/attachments/20190114/2ed09bf7/attachment-0001.html>
Hello Julien, Am Mon, 14 Jan 2019 22:15:47 +0100 schrieb Julien dupont <marcelvierzon at gmail.com>:> ** 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)> 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. 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?