Hi, I am trying to setup a VPN between roaming users and the office. Main usage will be VNC sessions to some Linux computers sitting on the office LAN. One machine on the office LAN, VPN_office, is dedicated to run tinc. The office router is behind another router for which we have no control, so I contracted an external computer VPN_out with a public IP to act as an in between connection. All the configuration details are given in https://we.tl/t-Yms0qqB4b1 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. As a work around I can first vnc to 192.168.1.3 and then ssh to another computer but that’s not very convenient. What should I do to be able to access computers on the office LAN other than VPN_office from a roaming client? Thanks, Marcel -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://www.tinc-vpn.org/pipermail/tinc/attachments/20190110/d87293c3/attachment-0001.html>
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). Maybe you want to analyze the place where the traffic gets lost via tcpdump. Cheers, Lars
Just because you cant ping something doesnt mean you cant connect to it ... if ICMP is blocked by the computers FW or the kernal is set to not respond, you might very well have a valid connection that just wont return a ping. As lars suggested `tcpdump` is one method of testing this. Another method might be to run `sudo kill -USR2 $(pidof tincd); sudo tail syslog` on any of the working nodes ... this should give you a decent map of what has connected and what has not. From there I would check the config files of the nodes not connected. If you miss a `ConnectTo` or forgot to xfer all of the files in hosts, then those computers are going to have problems. On Fri, Jan 11, 2019 at 9:41 PM Lars Kruse <lists at sumpfralle.de> 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). > > Maybe you want to analyze the place where the traffic gets lost via > tcpdump. > > 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/20190111/a051d754/attachment-0001.html>
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