Problem with connecting another subnet (Peter Thurner)

Fri Feb 8 22:55:45 CET 2019

 Peter,
I think I agree with your answers to my comments.
But it is so difficult to track the questions and answers when written!
I've created a network diagram of my setup, and it may help!I'll attached the PDF to this email, but it might get stripped.
If so, do email me directly.
John
  1. Problem with connecting another subnet (jradxl at yahoo.com)
  2. Re: Problem with connecting another subnet (Peter Thurner)
 Hello Peter,
Your question is similar to my recent question, and I have a similar Ping problem.But yours, with two Tinc networks, is more complex than mine.

All I can say, and I hope it helps, is that in my case I have found my Ubuntu Tinc Server nodes do not like being specified as a address on the same network as the local LANsSo I have a specific network for the Tinc Server nodes, and in this case a static route must be provided to the other local LAN networks.
I have also found that for the non-tinc machines each must have a static route, so that the ICMP response knows where to go.
John
  2. problem with connecting another subnet (destination net
      unknown) (Peter Thurner)Hello tinc mailing list! Nice to be accepted here :)
So I've been using tinc for a while just for itself and now I would like
to use it to route to another network. To be exact I have two tinc
networks with a "central node" that is connected to both tincs:

tiutl: 172.16.0.0/24
tiosp: 172.16.1.0/24

I'm doing that because I can then do fancy firewalling on that central node.

The setup looks like this:

web <- tinc "tiosp" -> gateway <- tinc "tiutl" -> backup

Server web: tiosp with 172.16.1.10
Server gateway: tiutil with 172.16.0.5 as well as tiosp with 172.16.1.5
Server backup: tiutl with 172.16.0.11

Now from web I can ping gateway on both 172.16.0.5 as well as
172.16.1.5. In tcpdump I can see that I could also ping 172.16.0.11
(backup), but backup does not know how to route the packets back :/

>From backup I can ping 172.16.0.5 of course ("normal" tinc), but not
172.16.1.5 (gateways tinc IP in the other tinc). In tcpdump I can see
that no icmp packets are reaching gateway.

## The backup server (tinc IP 172.16.0.11) in the tinc "tiutl" has a
route to 172.16.0.0/24 and 172.16.1.0/24 via tinc "tiutl"

root at backup-1:~# netstat -rn
Kernel IP routing table
Destination     Gateway         Genmask         Flags   MSS Window  irtt
Iface
0.0.0.0         85.184.249.1    0.0.0.0         UG        0 0          0
eth0
10.0.0.0        0.0.0.0         255.255.255.0   U         0 0          0
eth1
85.184.249.1    0.0.0.0         255.255.255.255 UH        0 0          0
eth0
172.16.0.0      0.0.0.0         255.255.255.0   U         0 0          0
tiutl
172.16.1.0      0.0.0.0         255.255.255.0   U         0 0          0
tiutl

## The backup servers tinc.conf

root at backup-1:~# cat /etc/tinc/tiutl/tinc.conf
Name = backup_1
Interface = tiutl
Device = /dev/net/tun
AddressFamily = ipv4
Port = 655
ConnectTo = gateway_1
ConnectTo = gateway_2
ConnectTo = git_1

## The backup servers tinc-up script

root at backup-1:~# cat /etc/tinc/tiutl/tinc-up
ip link set tiutl up
ip address add 172.16.0.11/24 dev tiutl                     <- works
ip route add 172.16.1.0/24 via 172.16.0.5 dev tiutl    <- doesn't work

## The backup servers tinc.conf

root at backup-1:~# cat /etc/tinc/tiutl/hosts/gateway_1
Address = 40.10.70.200  # the pubilc connect_to IP
Port = 655
Subnet = 172.16.0.5/32
Subnet = 172.16.1.0/24

-----BEGIN RSA PUBLIC KEY-----
-----END RSA PUBLIC KEY-----

## From backup, when I try to ping the "gateway" server in the "tiutl"
tinc network, this works:

root at backup-1:~# ping -c 1 172.16.0.5
PING 172.16.0.5 (172.16.0.5) 56(84) bytes of data.
64 bytes from 172.16.0.5: icmp_seq=1 ttl=64 time=7.85 ms

--- 172.16.0.5 ping statistics ---
1 packets transmitted, 1 received, 0% packet loss, time 0ms
rtt min/avg/max/mdev = 7.853/7.853/7.853/0.000 ms

## However pinging the IP the gateway server has in the other network
gives me dest net unknown:

root at backup-1:~# ping -c 1 172.16.1.5
PING 172.16.1.5 (172.16.1.5) 56(84) bytes of data.
>From 172.16.1.5 icmp_seq=1 Destination Net Unknown

--- 172.16.1.5 ping statistics ---
1 packets transmitted, 0 received, +1 errors, 100% packet loss, time 0ms

Also here, on gateway, no icmp packets show up in tcpdump.. Using
tcpdump on backup does make it look like gateway is answering, but it
isnt.. :/ Here is the tcpdump from backup and gateway while backup pings
gateway's "other" tinc IP:

root at backup-1:~# ping 172.16.1.5
PING 172.16.1.5 (172.16.1.5) 56(84) bytes of data.
>From 172.16.1.5 icmp_seq=1 Destination Net Unknown

root at backup-1:/etc/tinc/tiutl# tcpdump -i any icmp -n
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on any, link-type LINUX_SLL (Linux cooked), capture size
262144 bytes
20:26:22.990261 IP 172.16.0.11 > 172.16.1.5: ICMP echo request, id 3012,
seq 5, length 64
20:26:22.990322 IP 172.16.1.5 > 172.16.0.11: ICMP net 172.16.1.5
unreachable - unknown, length 92

root at gateway-1:/etc/tinc/tiutl# tcpdump -i any icmp -n
(nothing shows up here)

## Now the interesting part is that for some reasons the same thing is
working for the web (172.16.1.10) server (and I can just not find the
difference)

root at web-1:~# ping 172.16.0.5
PING 172.16.0.5 (172.16.0.5) 56(84) bytes of data.
64 bytes from 172.16.0.5: icmp_seq=1 ttl=64 time=7.22 ms

root at web-1:~# ping 172.16.1.5
PING 172.16.1.5 (172.16.1.5) 56(84) bytes of data.
64 bytes from 172.16.1.5: icmp_seq=1 ttl=64 time=7.47 ms

## From web (172.16.1.10), I can send icmp's to backup (172.16.0.11)
(backup just doesn't know where to send the answer)

root at web-1:~# ping -c 1 172.16.0.11
PING 172.16.0.11 (172.16.0.11) 56(84) bytes of data.

--- 172.16.0.11 ping statistics ---
1 packets transmitted, 0 received, 100% packet loss, time 0ms

## The packets arrive at backup (172.16.0.11)... (so yes I did `echo 1 >
/proc/sys/net/ipv4/ip_forward` on gateway)

root at backup-1:~# tcpdump -i any icmp -n
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on any, link-type LINUX_SLL (Linux cooked), capture size
262144 bytes
20:20:11.098991 IP 172.16.1.10 > 172.16.0.11: ICMP echo request, id
33274, seq 4, length 64
20:20:11.099024 IP 172.16.0.11 > 172.16.1.10: ICMP echo reply, id 33274,
seq 4, length 64
20:20:11.099046 IP 172.16.1.10 > 172.16.0.11: ICMP net 172.16.1.10
unreachable - unknown, length 92

## Web servers config files (for the web server, everything works as
expected)

root at web-1:~# cat /etc/tinc/tiosp/tinc.conf
Name = web_1
Interface = tiosp
Device = /dev/net/tun
AddressFamily = ipv4
Port = 656
ConnectTo = gateway_1
ConnectTo = gateway_2
ConnectTo = web_1

root at web-1:~# cat /etc/tinc/tiosp/tinc-up
#!/bin/bash
ip link set tiosp up
ip address add 172.16.1.10/24 dev tiosp
ip route add 172.16.0.0/24 via 172.16.1.5 dev tiosp

root at web-1:~# cat /etc/tinc/tiosp/hosts/gateway_1
Address = 40.10.70.240
Port = 656
Subnet = 172.16.1.5/24
Subnet = 172.16.0.0/24

-----BEGIN RSA PUBLIC KEY-----
-----END RSA PUBLIC KEY-----

Maybe I've been looking at this for to long :/ I just can't find the
problem. Sure its something obvious.. ;) Thank you guys in advance!

    On 8.2.19. 17:01, jradxl at yahoo.com wrote:

  Hello Peter, 

Hi John,

 Your question is similar to my recent question, and I have a similar Ping problem.But yours, with two Tinc networks, is more complex than mine.

All I can say, and I hope it helps, is that in my case I have found my Ubuntu Tinc Server nodes 

Ah, forgot to mention that I use Debian 9 here.

  do not like being specified as a address on the same network as the local LANs. So I have a specific network for the Tinc Server nodes 

Not sure if I perfectly get what you mean. Some servers have a local LAN (provided by the cloud provider itself) which is always something in 10.0.0.0/8. So that won't collide with the tincs, which are always in something in 172.16.0.0/12.

>From how I understood tinc, it will "magically find" routes to other tinc nodes. The connect_to's are always specified with their static public IPs. After that, I found that tinc uses the private networks provided by the cloud provider as well as routes over the public internet (as in magically finds its shortest route).

By server nodes you mean connect_to's? Or generally all tinc nodes (including non connect_to's)? Your specific network for the nodes is a private subnet by the physical / cloud provider?

 , and in this case a static route must be provided to the other local LAN networks. 

You mean there is a subnet= statement in the tinc host configs as well as a `ip route add` statement in the tinc-up script?

 I have also found that for the non-tinc machines each must have a static route, so that the ICMP response knows where to go. 

>From what I understand I _have_ that route defined in my tinc-up scripts - do I have what you mean stated below / in my first email?

 John
  2. problem with connecting another subnet (destination net
      unknown) (Peter Thurner)Hello tinc mailing list! Nice to be accepted here :)
So I've been using tinc for a while just for itself and now I would like
to use it to route to another network. To be exact I have two tinc
networks with a "central node" that is connected to both tincs:

tiutl: 172.16.0.0/24
tiosp: 172.16.1.0/24