<html><head></head><body><div style="font-family:Helvetica Neue, Helvetica, Arial, sans-serif;font-size:16px;"><div style=""><div style="font-family: "Helvetica Neue", Helvetica, Arial, sans-serif; font-size: 16px;"></div>
            <div style="font-family: "Helvetica Neue", Helvetica, Arial, sans-serif; font-size: 16px;"><span style="color: rgb(38, 40, 42);"><span><span style="font-family: "Helvetica Neue", Helvetica, Arial, sans-serif;"><br></span></span></span></div><div style=""><font color="#26282a">Thank you, Parke and Guus.</font><br><br><font color="#26282a">I have now understood and got it working.</font><br><font color="#26282a">Because of my beginner belief, I assumed that the tinc vpn end points needed to be on the same network.</font><br><font color="#26282a">I have now discovered that the tinc vpn IP </font><span style="color: rgb(38, 40, 42); font-family: "Helvetica Neue", Helvetica, Arial, sans-serif; font-size: 16px;"><span style="font-family: "Helvetica Neue", Helvetica, Arial, sans-serif; font-size: 16px;">end points </span></span><font color="#26282a">addresses can be arbitrary, and different!<br></font>So I have set the end points to be local to the LAN they connect, and added on each tinc server a dev route to ensure communication leaves on the correct interface.<br>Now all my clients only need one additional route to the tinc vpn ip address.<br>If I was supposed to conclude this from the documentation, I didn't as I was fixated on the same network idea.<br><br>Thanks</div><div style="">John<br><br></div><div style="font-family: "Helvetica Neue", Helvetica, Arial, sans-serif; font-size: 16px;"><span style="color: rgb(38, 40, 42);"><span><span style="font-family: "Helvetica Neue", Helvetica, Arial, sans-serif;"><br></span></span></span></div><div style="font-family: "Helvetica Neue", Helvetica, Arial, sans-serif; font-size: 16px;"><span style="color: rgb(38, 40, 42);"><span><span style="font-family: "Helvetica Neue", Helvetica, Arial, sans-serif;">On Tue, Apr 3, 2018 at 2:55 AM, John Radley (yahoo) <</span><a href="mailto:jradxl@yahoo.com" style="color: rgb(25, 106, 212); text-decoration-line: underline; font-family: "Helvetica Neue", Helvetica, Arial, sans-serif;" rel="nofollow" target="_blank">jradxl@yahoo.com</a><span style="font-family: "Helvetica Neue", Helvetica, Arial, sans-serif;">> wrote:</span><br style="font-family: "Helvetica Neue", Helvetica, Arial, sans-serif;"><span style="font-family: "Helvetica Neue", Helvetica, Arial, sans-serif;">> This is annoying however. Now I have to give very client a route back to the</span><br style="font-family: "Helvetica Neue", Helvetica, Arial, sans-serif;"><span style="font-family: "Helvetica Neue", Helvetica, Arial, sans-serif;">> VPN network, just to support Server to Client connectivity</span><br style="font-family: "Helvetica Neue", Helvetica, Arial, sans-serif;"><span style="font-family: "Helvetica Neue", Helvetica, Arial, sans-serif;">> I would have thought just specifying each client to have a route back to</span><br style="font-family: "Helvetica Neue", Helvetica, Arial, sans-serif;"><span style="font-family: "Helvetica Neue", Helvetica, Arial, sans-serif;">> Tinc Server (using local lan address) was sufficient.</span><br style="font-family: "Helvetica Neue", Helvetica, Arial, sans-serif;"><br style="font-family: "Helvetica Neue", Helvetica, Arial, sans-serif;"><span style="font-family: "Helvetica Neue", Helvetica, Arial, sans-serif;">> How I have found and described problem, can you explain why and offer any</span><br style="font-family: "Helvetica Neue", Helvetica, Arial, sans-serif;"><span style="font-family: "Helvetica Neue", Helvetica, Arial, sans-serif;">> alternative than such explicit routes.</span><br style="font-family: "Helvetica Neue", Helvetica, Arial, sans-serif;"><br style="font-family: "Helvetica Neue", Helvetica, Arial, sans-serif;"><span style="font-family: "Helvetica Neue", Helvetica, Arial, sans-serif;">The "why" is that each system needs to know how to route each outbound</span><br style="font-family: "Helvetica Neue", Helvetica, Arial, sans-serif;"><span style="font-family: "Helvetica Neue", Helvetica, Arial, sans-serif;">packet before it can send that packet.</span><br style="font-family: "Helvetica Neue", Helvetica, Arial, sans-serif;"><br style="font-family: "Helvetica Neue", Helvetica, Arial, sans-serif;"><span style="font-family: "Helvetica Neue", Helvetica, Arial, sans-serif;">As for an alternative:</span><br style="font-family: "Helvetica Neue", Helvetica, Arial, sans-serif;"><br style="font-family: "Helvetica Neue", Helvetica, Arial, sans-serif;"><span style="font-family: "Helvetica Neue", Helvetica, Arial, sans-serif;">I believe you could eliminate the separate subnet for the Servers.</span><br style="font-family: "Helvetica Neue", Helvetica, Arial, sans-serif;"><br style="font-family: "Helvetica Neue", Helvetica, Arial, sans-serif;"><span style="font-family: "Helvetica Neue", Helvetica, Arial, sans-serif;">Just give each Server an IP address on the same subnet as the clients</span><br style="font-family: "Helvetica Neue", Helvetica, Arial, sans-serif;"><span style="font-family: "Helvetica Neue", Helvetica, Arial, sans-serif;">it serves.  In fact, the Servers probably already have such an IP</span><br style="font-family: "Helvetica Neue", Helvetica, Arial, sans-serif;"><span style="font-family: "Helvetica Neue", Helvetica, Arial, sans-serif;">address (although I could be wrong about this as I have not reviewed</span><br style="font-family: "Helvetica Neue", Helvetica, Arial, sans-serif;"><span style="font-family: "Helvetica Neue", Helvetica, Arial, sans-serif;">your configuration / network graph in detail).</span><br style="font-family: "Helvetica Neue", Helvetica, Arial, sans-serif;"><br style="font-family: "Helvetica Neue", Helvetica, Arial, sans-serif;"><span style="font-family: "Helvetica Neue", Helvetica, Arial, sans-serif;">Best,</span><br style="font-family: "Helvetica Neue", Helvetica, Arial, sans-serif;"><br style="font-family: "Helvetica Neue", Helvetica, Arial, sans-serif;"><span style="font-family: "Helvetica Neue", Helvetica, Arial, sans-serif;">Parke</span></span></span></div><div style="font-family: "Helvetica Neue", Helvetica, Arial, sans-serif; font-size: 16px;"><span style="color: rgb(38, 40, 42);"><br></span></div><div style="font-family: "Helvetica Neue", Helvetica, Arial, sans-serif; font-size: 16px;"><span style="color: rgb(38, 40, 42);">Guus, </span><span style="color: rgb(38, 40, 42);"><span><br style="font-family: "Helvetica Neue", Helvetica, Arial, sans-serif;"></span></span></div></div><div id="ydpdac8208yahoo_quoted_3075757824" class="ydpdac8208yahoo_quoted"><div style="font-family:'Helvetica Neue', Helvetica, Arial, sans-serif;font-size:13px;color:#26282a;"><div><div id="ydpdac8208ymsg48244" class="ydpdac8208ymsg9026537600"><div id="ydpdac8208yiv6789526450"><div style="font-family:Helvetica Neue, Helvetica, Arial, sans-serif;font-size:16px;"><div>Thank you for your help<br><br>(a)>>You said:- <span><span style="font-family:Helvetica, Arial, sans-serif;">First, if you are already using "ip" to assign an address.....<br></span></span>Why should I use "ip route" instead of "route add..."<br>Surely both write same to the Routing table?</div><div><br></div><div>(b) My problem was, that Tinc servers could not ping remote clients, whereas clients could ping successfully across VPN</div><div>When pinging Client to Client "tcpdump" shows me it is src network to dest network (eg 192.168.14.0/24 to 192.168.4.0/24 )<br>Whereas pinging Server to Client, <span><span style="color:rgb(0, 0, 0);font-family:Helvetica, Arial, sans-serif;font-size:16px;">"tcpdump" shows me the source is the VPN network, to dest network (eg 192.168.20.0/24 to <span><span style="color:rgb(0, 0, 0);font-family:Helvetica, Arial, sans-serif;font-size:16px;"> 192.168.4.0/24)</span></span></span></span></div><div><span>However, the clients DID NOT have an explicit route back to the <span style="color:rgb(0, 0, 0);font-family:Helvetica, Arial, sans-serif;font-size:16px;"><span style="color:rgb(0, 0, 0);font-family:Helvetica, Arial, sans-serif;font-size:16px;">VPN network. Adding one solves the Server to Client ping problem.<br></span></span></span><div><span><span style="color:rgb(0, 0, 0);font-family:Helvetica, Arial, sans-serif;font-size:16px;"><span><span style="color:rgb(0, 0, 0);font-family:Helvetica, Arial, sans-serif;font-size:16px;"><span><span style="color:rgb(0, 0, 0);font-family:Helvetica, Arial, sans-serif;font-size:16px;"><br></span></span></span></span></span></span></div></div><div><span>This is annoying however. Now I have to give very client a route back to the VPN network, just to support Server to Client connectivity<br>I would have thought just specifying each client to have a route back to Tinc Server (using local lan address) was sufficient.<br><br></span></div><div>How I have found and described problem, can you explain why and offer any alternative than such explicit routes.<br><br>Thanks<br>John</div><div><br></div><div id="ydpdac8208yiv6789526450ydpcd754340yahoo_quoted_3168118765" class="ydpdac8208yiv6789526450ydpcd754340yahoo_quoted"><div style="font-family:'Helvetica Neue', Helvetica, Arial, sans-serif;font-size:13px;color:#26282a;"><div><div id="ydpdac8208yiv6789526450ydpcd754340ymsg97115" class="ydpdac8208yiv6789526450ydpcd754340ymsg2964973107"><br>> I have a three tinc server setup, similar to "4.3 How Connections<br>> Work" using the configuration mostly like<br>> <a href="http://ostolc.org/site-to-site-vpn-with-tinc.html" rel="nofollow" target="_blank">http://ostolc.org/site-to-site-vpn-with-tinc.html</a><br>> <br>> The clients (Ubuntus, Debians and Windows 10s) can all ping (and SSH)<br>> to each other remotely. As far as that is concerned it's working great<br>> - thanks so much for some great software.<br>> <br>> However, on each of the Tinc servers (A and C) neither of them can<br>> ping other remote clients. Of course, A and C can ping each other. If<br>> I use tcpdump -nni tun0 icmpI can see the echo packets leave the<br>> server, and on a remote client see the request received and the reply<br>> sent. However the server never gets the reply. It seems that on each<br>> server there is no internal routing between enp1s0 and tun0 for IPs<br>> that are not server IPs. I guess I can live with such a limitation,<br>> but would still like to know why!!<br><br>Tinc itself doesn't take of that routing outside of the VPN itself, so<br>it is up to you to configure it correctly.<br><br>> TINC-UP<br>> ip link set $INTERFACE up<br>> ip addr add 192.168.20.3/24 dev $INTERFACE<br>> route add -net 192.168.14.0/24 gw 192.168.20.3<br>> route add -net 192.168.6.0/24  gw 192.168.4.99<br><br>First, if you are already using "ip" to assign an address, then instead of the "route" command, use the "ip route" command to configure extra routes, like so:<br><br>    ip route add 192.168.14.0/24 via 192.168.20.3<br>    ip route add 192.168.6.0/24 via 192.168.4.99<br><br>Note that the first route command is equivalent to:<br><br>    ip route add 192.168.14.0/24 dev $INTERFACE<br><br>> ROUTE TABLE on A<br>> Kernel IP routing table<br>> Destination     Gateway         Genmask         Flags  Metric Ref Use Iface<br>> default         192.168.4.1     0.0.0.0         UG     100    0   0   enp1s0<br>> link-local      *               255.255.0.0     U      1000   0   0   enp1s0<br>> 192.168.4.0     *               255.255.255.0   U      100    0   0   enp1s0<br>> 192.168.6.0     192.168.4.99    255.255.255.0   UG     0      0   0   enp1s0<br>> 192.168.14.0    192.168.20.3    255.255.255.0   UG     0      0   0   tun0<br>> 192.168.20.0    *               255.255.255.0   U      0      0   0   tun0<br>[...]<br>> Net 192.168.4.0 is the A local network<br>> IP of A is 192.168.4.30, IP of C is 192.168.14.20<br>[...]<br>> Only thing wrong is, for example on A, ping 192.168.14.60 does not work<br>> On C, ping 192.168.4.26 does not work<br><br>The problem is most likely with the hosts 192.168.14.60 and<br>192.168.4.26. What does their routing table look like? If 192.168.4.26<br>just has:<br><br>    Destination     Gateway         Genmask         Flags  Metric Ref Use Iface<br>    default         192.168.4.1     0.0.0.0         UG     100    0   0   enp1s0<br>    link-local      *               255.255.0.0     U      1000   0   0   enp1s0<br>    192.168.4.0     *               255.255.255.0   U      100    0   0   enp1s0<br><br>Then packets for 192.168.20.* or 192.168.14.* will go the the default<br>gateway 192.168.4.1, and will not go to your host running tinc. A ping<br>packet from C might reach host 192.168.14.26, but that host will send<br>the return packet in the wrong direction.<br><br>To fix this, you must either add a route that looks like this to each<br>host on A:<br><br>    192.168.14.0    192.168.4.30    255.255.255.0   UG     0      0   0   enp1s0<br><br>Or you have to tell the router (192.168.4.1) that packets for<br>192.168.14.0/24 should be forwarded to 192.168.4.30. And you have to do<br>something similar on the other sites.<br><br>> But on clients 192.168.14.60 and 192.168.4.26 can ping each other.<br><br>Ok, that is weird... if those can ping each other, they should both be<br>able to ping A and C as well.<br><br>-- <br>Met vriendelijke groet / with kind regards,<br>     Guus Sliepen <<a href="mailto:guus@tinc-vpn.org" rel="nofollow" target="_blank">guus@tinc-vpn.org</a>></div></div></div></div></div></div></div><div id="ydpdac8208ymsg12567" class="ydpdac8208ymsg9026537600"><br></div></div>
                </div>
            </div></div></body></html>