On 12/1/19 2:29 pm, Lars Kruse wrote:> Hello > > > Am Thu, 10 Jan 2019 11:58:33 +0100 > schrieb Julien dupont <marcelvierzon at gmail.com>: > >> The two tunnels are working. From a client I can ping or ssh VPN_office on >> both tunnel and LAN IPs 172.16.0.2 and 192.168.1.3. I cannot however ping >> any other computer on the LAN, I get no pong back but it is not complaining >> he has no route to host. > wild guess: maybe the response fails to find its way back to the source? > In this case you could either masquerade (SNAT) traffic when it leaves the > tunnel at VPN_office or you could configure a suitable route on the default > gateway of your network (this should work for all local hosts via ICMP > redirects).In my experience the ICMP redirects don't really work. I had TINC running on a machine other than the default gateway at one node recently and it was a major pain - I had to configure static routes on every machine because the ICMP redirect just didn't work. I since replaced the router (default gateway) with an OpenWRT setup with TINC included and everything is much simpler. Hamish
I cannot even ping the LAN router on 192.168.1.1, but if I ssh though the tunnel to 192.168.1.3, I can ping it. Investigating with tcpdump withoug guidelines is beyond my skills I'm afraid. 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? Le sam. 12 janv. 2019 à 05:17, Hamish Moffatt <hamish at moffatt.email> a écrit :> On 12/1/19 2:29 pm, Lars Kruse wrote: > > Hello > > > > > > Am Thu, 10 Jan 2019 11:58:33 +0100 > > schrieb Julien dupont <marcelvierzon at gmail.com>: > > > >> The two tunnels are working. From a client I can ping or ssh VPN_office > on > >> both tunnel and LAN IPs 172.16.0.2 and 192.168.1.3. I cannot however > ping > >> any other computer on the LAN, I get no pong back but it is not > complaining > >> he has no route to host. > > wild guess: maybe the response fails to find its way back to the source? > > In this case you could either masquerade (SNAT) traffic when it leaves > the > > tunnel at VPN_office or you could configure a suitable route on the > default > > gateway of your network (this should work for all local hosts via ICMP > > redirects). > > > In my experience the ICMP redirects don't really work. I had TINC > running on a machine other than the default gateway at one node recently > and it was a major pain - I had to configure static routes on every > machine because the ICMP redirect just didn't work. > > I since replaced the router (default gateway) with an OpenWRT setup with > TINC included and everything is much simpler. > > > Hamish > > _______________________________________________ > 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/24ef74f5/attachment.html>
Take a look at the routing tables on all your devices and see if they all know how to route to each other. If not, you may need to add some manual. On Mon, Jan 14, 2019 at 12:04 PM Julien dupont <marcelvierzon at gmail.com> wrote:> > I cannot even ping the LAN router on 192.168.1.1, but if I ssh though the tunnel to 192.168.1.3, I can ping it. > > Investigating with tcpdump withoug guidelines is beyond my skills I'm afraid. > > 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? > > Le sam. 12 janv. 2019 à 05:17, Hamish Moffatt <hamish at moffatt.email> a écrit : >> >> On 12/1/19 2:29 pm, Lars Kruse wrote: >> > Hello >> > >> > >> > Am Thu, 10 Jan 2019 11:58:33 +0100 >> > schrieb Julien dupont <marcelvierzon at gmail.com>: >> > >> >> The two tunnels are working. From a client I can ping or ssh VPN_office on >> >> both tunnel and LAN IPs 172.16.0.2 and 192.168.1.3. I cannot however ping >> >> any other computer on the LAN, I get no pong back but it is not complaining >> >> he has no route to host. >> > wild guess: maybe the response fails to find its way back to the source? >> > In this case you could either masquerade (SNAT) traffic when it leaves the >> > tunnel at VPN_office or you could configure a suitable route on the default >> > gateway of your network (this should work for all local hosts via ICMP >> > redirects). >> >> >> In my experience the ICMP redirects don't really work. I had TINC >> running on a machine other than the default gateway at one node recently >> and it was a major pain - I had to configure static routes on every >> machine because the ICMP redirect just didn't work. >> >> I since replaced the router (default gateway) with an OpenWRT setup with >> TINC included and everything is much simpler. >> >> >> Hamish >> >> _______________________________________________ >> tinc mailing list >> tinc at tinc-vpn.org >> https://www.tinc-vpn.org/cgi-bin/mailman/listinfo/tinc > > _______________________________________________ > tinc mailing list > tinc at tinc-vpn.org > https://www.tinc-vpn.org/cgi-bin/mailman/listinfo/tinc
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