tinc - Apr 2018 - Help on a Nat To Nat soluction - tinc servers won't ping remote clients

Guus, Thank you for your help

(a)>>You said:- First, if you are already using "ip" to assign
an address.....
Why should I use "ip route" instead of "route add..."
Surely both write same to the Routing table?
(b) My problem was, that Tinc servers could not ping remote clients, whereas
clients could ping successfully across VPNWhen 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 )
Whereas pinging Server to Client, "tcpdump" shows me the source is the
VPN network, to dest network (eg 192.168.20.0/24 to  192.168.4.0/24)However, the
clients DID NOT have an explicit route back to the VPN network. Adding one
solves the Server to Client ping problem.

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
I would have thought just specifying each client to have a route back to Tinc
Server (using local lan address) was sufficient.

How I have found and described problem, can you explain why and offer any
alternative than such explicit routes.

Thanks
John
> I have a three tinc server setup, similar to "4.3 How Connections
> Work" using the configuration mostly like
> http://ostolc.org/site-to-site-vpn-with-tinc.html
> 
> The clients (Ubuntus, Debians and Windows 10s) can all ping (and SSH)
> to each other remotely. As far as that is concerned it's working great
> - thanks so much for some great software.
> 
> However, on each of the Tinc servers (A and C) neither of them can
> ping other remote clients. Of course, A and C can ping each other. If
> I use tcpdump -nni tun0 icmpI can see the echo packets leave the
> server, and on a remote client see the request received and the reply
> sent. However the server never gets the reply. It seems that on each
> server there is no internal routing between enp1s0 and tun0 for IPs
> that are not server IPs. I guess I can live with such a limitation,
> but would still like to know why!!
Tinc itself doesn't take of that routing outside of the VPN itself, so
it is up to you to configure it correctly.
> TINC-UP
> ip link set $INTERFACE up
> ip addr add 192.168.20.3/24 dev $INTERFACE
> route add -net 192.168.14.0/24 gw 192.168.20.3
> route add -net 192.168.6.0/24  gw 192.168.4.99
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:

    ip route add 192.168.14.0/24 via 192.168.20.3
    ip route add 192.168.6.0/24 via 192.168.4.99

Note that the first route command is equivalent to:

    ip route add 192.168.14.0/24 dev $INTERFACE
> ROUTE TABLE on A
> Kernel IP routing table
> Destination     Gateway         Genmask         Flags  Metric Ref Use Iface
> default         192.168.4.1     0.0.0.0         UG     100    0   0  enp1s0
> link-local      *               255.255.0.0     U     1000   0   0  enp1s0
> 192.168.4.0     *               255.255.255.0   U     100    0   0  enp1s0
> 192.168.6.0     192.168.4.99   255.255.255.0   UG     0      0   0  enp1s0
> 192.168.14.0    192.168.20.3    255.255.255.0   UG     0      0   0  tun0
> 192.168.20.0    *               255.255.255.0   U     0      0   0  tun0
[...]
> Net 192.168.4.0 is the A local network
> IP of A is 192.168.4.30, IP of C is 192.168.14.20
[...]
> Only thing wrong is, for example on A, ping 192.168.14.60 does not work
> On C, ping 192.168.4.26 does not work
The problem is most likely with the hosts 192.168.14.60 and
192.168.4.26. What does their routing table look like? If 192.168.4.26
just has:

    Destination     Gateway         Genmask         Flags  Metric Ref Use Iface
    default         192.168.4.1     0.0.0.0         UG     100    0   0  enp1s0
    link-local      *               255.255.0.0     U     1000   0   0  enp1s0
    192.168.4.0     *               255.255.255.0   U     100    0   0  enp1s0

Then packets for 192.168.20.* or 192.168.14.* will go the the default
gateway 192.168.4.1, and will not go to your host running tinc. A ping
packet from C might reach host 192.168.14.26, but that host will send
the return packet in the wrong direction.

To fix this, you must either add a route that looks like this to each
host on A:

    192.168.14.0    192.168.4.30    255.255.255.0   UG     0      0   0  enp1s0

Or you have to tell the router (192.168.4.1) that packets for
192.168.14.0/24 should be forwarded to 192.168.4.30. And you have to do
something similar on the other sites.
> But on clients 192.168.14.60 and 192.168.4.26 can ping each other.
Ok, that is weird... if those can ping each other, they should both be
able to ping A and C as well.

-- 
Met vriendelijke groet / with kind regards,
    Guus Sliepen <guus at tinc-vpn.org>
  
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://www.tinc-vpn.org/pipermail/tinc/attachments/20180403/0ad82114/attachment.html>

On Tue, Apr 3, 2018 at 2:55 AM, John Radley (yahoo) <jradxl at yahoo.com>
wrote:
> 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
> I would have thought just specifying each client to have a route back to
> Tinc Server (using local lan address) was sufficient.
> How I have found and described problem, can you explain why and offer any
> alternative than such explicit routes.
The "why" is that each system needs to know how to route each outbound
packet before it can send that packet.

As for an alternative:

I believe you could eliminate the separate subnet for the Servers.

Just give each Server an IP address on the same subnet as the clients
it serves.  In fact, the Servers probably already have such an IP
address (although I could be wrong about this as I have not reviewed
your configuration / network graph in detail).

Best,

Parke