Problem with connecting another subnet

Peter Thurner p.thurner at blunix.org
Fri Feb 8 18:05:27 CET 2019 

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
>
> 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!
>
>   
>
> _______________________________________________
> tinc mailing list
> tinc at tinc-vpn.org
> https://www.tinc-vpn.org/cgi-bin/mailman/listinfo/tinc

Mit freundlichen Grüßen,


Peter Thurner

--

Blunix GmbH - Consulting for Linux Hosting 24/7

Glogauer Straße 21
10999 Berlin, Germany

P: +49 30 / 120 839 90
W: https://www.blunix.org

AG Charlottenburg, HRB 174906 B
CEO: Peter Thurner

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.tinc-vpn.org/pipermail/tinc/attachments/20190208/c272a032/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: OpenPGP digital signature
URL: <http://www.tinc-vpn.org/pipermail/tinc/attachments/20190208/c272a032/attachment-0001.sig>

More information about the tinc mailing list