Help on a Nat To Nat soluction - tinc servers won't ping remote clients
John Radley (yahoo)
jradxl at yahoo.com
Wed Apr 4 13:38:55 CEST 2018
Thank you, Parke and Guus.
I have now understood and got it working.
Because of my beginner belief, I assumed that the tinc vpn end points needed to be on the same network.
I have now discovered that the tinc vpn IP end points addresses can be arbitrary, and different!
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.
Now all my clients only need one additional route to the tinc vpn ip address.
If I was supposed to conclude this from the documentation, I didn't as I was fixated on the same network idea.
ThanksJohn
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
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/20180404/f694d201/attachment.html>
More information about the tinc
mailing list