<html><head></head><body><div class="ydp102bafeyahoo-style-wrap" style="font-family:Helvetica Neue, Helvetica, Arial, sans-serif;font-size:16px;"><div></div>
        <div>Peter,<br>I think I agree with your answers to my comments.<br>But it is so difficult to track the questions and answers when written!<br>I've created a network diagram of my setup, and it may help!</div><div>I'll attached the PDF to this email, but it might get stripped.<br>If so, do email me directly.<br>John</div></div><div id="ydpc1df829yahoo_quoted_0356246337" class="ydpc1df829yahoo_quoted"><div style="font-family:'Helvetica Neue', Helvetica, Arial, sans-serif;font-size:13px;color:#26282a;"><div><br>   1. Problem with connecting another subnet (<a href="mailto:jradxl@yahoo.com" rel="nofollow" target="_blank">jradxl@yahoo.com</a>)<br>   2. Re: Problem with connecting another subnet (Peter Thurner)<br><div id="ydpc1df829ymsg39645" class="ydpc1df829ymsg9025068073"><div id="ydpc1df829yiv0793103117"><div><div class="ydpc1df829yiv0793103117ydp17a17deyahoo-style-wrap" style="font-family:Helvetica Neue, Helvetica, Arial, sans-serif;font-size:16px;"><div></div>
        <div>Hello Peter,<br>Your question is similar to my recent question, and I have a similar Ping problem.</div><div>But yours, with two Tinc networks, is more complex than mine.<br></div><div><br></div><div>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 LANs</div><div>So I have a specific network for the <span><span style="color:rgb(0, 0, 0);font-family:Helvetica Neue, Helvetica, Arial, sans-serif;font-size:16px;">Tinc Server nodes, and in this case a static route must be provided to the other local LAN networks.<br>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.<br>John</span></span></div><div><br></div></div><div id="ydpc1df829yiv0793103117ydpc88fbc1dyahoo_quoted_9799530024" class="ydpc1df829yiv0793103117ydpc88fbc1dyahoo_quoted"><div style="font-family:'Helvetica Neue', Helvetica, Arial, sans-serif;font-size:13px;color:#26282a;"><div>   2. problem with connecting another subnet (destination net<br>      unknown) (Peter Thurner)</div><div>Hello tinc mailing list! Nice to be accepted here :)<div id="ydpc1df829yiv0793103117ydpc88fbc1dymsg20395" class="ydpc1df829yiv0793103117ydpc88fbc1dymsg0804972489"><br>So I've been using tinc for a while just for itself and now I would like<br>to use it to route to another network. To be exact I have two tinc<br>networks with a "central node" that is connected to both tincs:<br><br>tiutl: 172.16.0.0/24<br>tiosp: 172.16.1.0/24<br><br>I'm doing that because I can then do fancy firewalling on that central node.<br><br>The setup looks like this:<br><br>web <- tinc "tiosp" -> gateway <- tinc "tiutl" -> backup<br><br>Server web: tiosp with 172.16.1.10<br>Server gateway: tiutil with 172.16.0.5 as well as tiosp with 172.16.1.5<br>Server backup: tiutl with 172.16.0.11<br><br>Now from web I can ping gateway on both 172.16.0.5 as well as<br>172.16.1.5. In tcpdump I can see that I could also ping 172.16.0.11<br>(backup), but backup does not know how to route the packets back :/<br><br>From backup I can ping 172.16.0.5 of course ("normal" tinc), but not<br>172.16.1.5 (gateways tinc IP in the other tinc). In tcpdump I can see<br>that no icmp packets are reaching gateway.<br><br>## The backup server (tinc IP 172.16.0.11) in the tinc "tiutl" has a<br>route to 172.16.0.0/24 and 172.16.1.0/24 via tinc "tiutl"<br><br><a href="mailto:root@backup-1" rel="nofollow" target="_blank">root@backup-1</a>:~# netstat -rn<br>Kernel IP routing table<br>Destination     Gateway         Genmask         Flags   MSS Window  irtt<br>Iface<br>0.0.0.0         85.184.249.1    0.0.0.0         UG        0 0          0<br>eth0<br>10.0.0.0        0.0.0.0         255.255.255.0   U         0 0          0<br>eth1<br>85.184.249.1    0.0.0.0         255.255.255.255 UH        0 0          0<br>eth0<br>172.16.0.0      0.0.0.0         255.255.255.0   U         0 0          0<br>tiutl<br>172.16.1.0      0.0.0.0         255.255.255.0   U         0 0          0<br>tiutl<br><br>## The backup servers tinc.conf<br><br><a href="mailto:root@backup-1" rel="nofollow" target="_blank">root@backup-1</a>:~# cat /etc/tinc/tiutl/tinc.conf<br>Name = backup_1<br>Interface = tiutl<br>Device = /dev/net/tun<br>AddressFamily = ipv4<br>Port = 655<br>ConnectTo = gateway_1<br>ConnectTo = gateway_2<br>ConnectTo = git_1<br><br><br>## The backup servers tinc-up script<br><br><a href="mailto:root@backup-1" rel="nofollow" target="_blank">root@backup-1</a>:~# cat /etc/tinc/tiutl/tinc-up<br>ip link set tiutl up<br>ip address add 172.16.0.11/24 dev tiutl                     <- works<br>ip route add 172.16.1.0/24 via 172.16.0.5 dev tiutl    <- doesn't work<br><br><br>## The backup servers tinc.conf<br><br><a href="mailto:root@backup-1" rel="nofollow" target="_blank">root@backup-1</a>:~# cat /etc/tinc/tiutl/hosts/gateway_1<br>Address = 40.10.70.200  # the pubilc connect_to IP<br>Port = 655<br>Subnet = 172.16.0.5/32<br>Subnet = 172.16.1.0/24<br><br>-----BEGIN RSA PUBLIC KEY-----<br>-----END RSA PUBLIC KEY-----<br><br><br>## From backup, when I try to ping the "gateway" server in the "tiutl"<br>tinc network, this works:<br><br><br><a href="mailto:root@backup-1" rel="nofollow" target="_blank">root@backup-1</a>:~# ping -c 1 172.16.0.5<br>PING 172.16.0.5 (172.16.0.5) 56(84) bytes of data.<br>64 bytes from 172.16.0.5: icmp_seq=1 ttl=64 time=7.85 ms<br><br>--- 172.16.0.5 ping statistics ---<br>1 packets transmitted, 1 received, 0% packet loss, time 0ms<br>rtt min/avg/max/mdev = 7.853/7.853/7.853/0.000 ms<br><br><br>## However pinging the IP the gateway server has in the other network<br>gives me dest net unknown:<br><br><a href="mailto:root@backup-1" rel="nofollow" target="_blank">root@backup-1</a>:~# ping -c 1 172.16.1.5<br>PING 172.16.1.5 (172.16.1.5) 56(84) bytes of data.<br>From 172.16.1.5 icmp_seq=1 Destination Net Unknown<br><br>--- 172.16.1.5 ping statistics ---<br>1 packets transmitted, 0 received, +1 errors, 100% packet loss, time 0ms<br><br>Also here, on gateway, no icmp packets show up in tcpdump.. Using<br>tcpdump on backup does make it look like gateway is answering, but it<br>isnt.. :/ Here is the tcpdump from backup and gateway while backup pings<br>gateway's "other" tinc IP:<br><br><a href="mailto:root@backup-1" rel="nofollow" target="_blank">root@backup-1</a>:~# ping 172.16.1.5<br>PING 172.16.1.5 (172.16.1.5) 56(84) bytes of data.<br>From 172.16.1.5 icmp_seq=1 Destination Net Unknown<br><br><a href="mailto:root@backup-1" rel="nofollow" target="_blank">root@backup-1</a>:/etc/tinc/tiutl# tcpdump -i any icmp -n<br>tcpdump: verbose output suppressed, use -v or -vv for full protocol decode<br>listening on any, link-type LINUX_SLL (Linux cooked), capture size<br>262144 bytes<br>20:26:22.990261 IP 172.16.0.11 > 172.16.1.5: ICMP echo request, id 3012,<br>seq 5, length 64<br>20:26:22.990322 IP 172.16.1.5 > 172.16.0.11: ICMP net 172.16.1.5<br>unreachable - unknown, length 92<br><br><a href="mailto:root@gateway-1" rel="nofollow" target="_blank">root@gateway-1</a>:/etc/tinc/tiutl# tcpdump -i any icmp -n<br>(nothing shows up here)<br><br>## Now the interesting part is that for some reasons the same thing is<br>working for the web (172.16.1.10) server (and I can just not find the<br>difference)<br><br><a href="mailto:root@web-1" rel="nofollow" target="_blank">root@web-1</a>:~# ping 172.16.0.5<br>PING 172.16.0.5 (172.16.0.5) 56(84) bytes of data.<br>64 bytes from 172.16.0.5: icmp_seq=1 ttl=64 time=7.22 ms<br><br><a href="mailto:root@web-1" rel="nofollow" target="_blank">root@web-1</a>:~# ping 172.16.1.5<br>PING 172.16.1.5 (172.16.1.5) 56(84) bytes of data.<br>64 bytes from 172.16.1.5: icmp_seq=1 ttl=64 time=7.47 ms<br><br>## From web (172.16.1.10), I can send icmp's to backup (172.16.0.11)<br>(backup just doesn't know where to send the answer)<br><br><a href="mailto:root@web-1" rel="nofollow" target="_blank">root@web-1</a>:~# ping -c 1 172.16.0.11<br>PING 172.16.0.11 (172.16.0.11) 56(84) bytes of data.<br><br>--- 172.16.0.11 ping statistics ---<br>1 packets transmitted, 0 received, 100% packet loss, time 0ms<br><br>## The packets arrive at backup (172.16.0.11)... (so yes I did `echo 1 ><br>/proc/sys/net/ipv4/ip_forward` on gateway)<br><br><a href="mailto:root@backup-1" rel="nofollow" target="_blank">root@backup-1</a>:~# tcpdump -i any icmp -n<br>tcpdump: verbose output suppressed, use -v or -vv for full protocol decode<br>listening on any, link-type LINUX_SLL (Linux cooked), capture size<br>262144 bytes<br>20:20:11.098991 IP 172.16.1.10 > 172.16.0.11: ICMP echo request, id<br>33274, seq 4, length 64<br>20:20:11.099024 IP 172.16.0.11 > 172.16.1.10: ICMP echo reply, id 33274,<br>seq 4, length 64<br>20:20:11.099046 IP 172.16.1.10 > 172.16.0.11: ICMP net 172.16.1.10<br>unreachable - unknown, length 92<br><br>## Web servers config files (for the web server, everything works as<br>expected)<br><br><a href="mailto:root@web-1" rel="nofollow" target="_blank">root@web-1</a>:~# cat /etc/tinc/tiosp/tinc.conf<br>Name = web_1<br>Interface = tiosp<br>Device = /dev/net/tun<br>AddressFamily = ipv4<br>Port = 656<br>ConnectTo = gateway_1<br>ConnectTo = gateway_2<br>ConnectTo = web_1<br><br><a href="mailto:root@web-1" rel="nofollow" target="_blank">root@web-1</a>:~# cat /etc/tinc/tiosp/tinc-up<br>#!/bin/bash<br>ip link set tiosp up<br>ip address add 172.16.1.10/24 dev tiosp<br>ip route add 172.16.0.0/24 via 172.16.1.5 dev tiosp<br><br><a href="mailto:root@web-1" rel="nofollow" target="_blank">root@web-1</a>:~# cat /etc/tinc/tiosp/hosts/gateway_1<br>Address = 40.10.70.240<br>Port = 656<br>Subnet = 172.16.1.5/24<br>Subnet = 172.16.0.0/24<br><br>-----BEGIN RSA PUBLIC KEY-----<br>-----END RSA PUBLIC KEY-----<br><br>Maybe I've been looking at this for to long :/ I just can't find the<br>problem. Sure its something obvious.. ;) Thank you guys in advance!<br><br></div></div>
            </div>
        </div></div></div></div><div id="ydpc1df829ymsg78805" class="ydpc1df829ymsg9025068073"><div id="ydpc1df829yiv0793103117">
  
    
  
  <div>
    <div class="ydpc1df829yiv0793103117moz-cite-prefix">On 8.2.19. 17:01, <a class="ydpc1df829yiv0793103117moz-txt-link-abbreviated" href="mailto:jradxl@yahoo.com" rel="nofollow" target="_blank">jradxl@yahoo.com</a>
      wrote:<br>
    </div>
    <blockquote type="cite">
      <pre class="ydpc1df829yiv0793103117moz-quote-pre"> Hello Peter,</pre>
    </blockquote>
    <p>Hi John,</p>
    <p><br>
    </p>
    <blockquote type="cite">
      <pre class="ydpc1df829yiv0793103117moz-quote-pre">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</pre>
    </blockquote>
    <p>Ah, forgot to mention that I use Debian 9 here.</p>
    <p><br>
    </p>
    <blockquote type="cite">
      <pre class="ydpc1df829yiv0793103117moz-quote-pre"> 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</pre>
    </blockquote>
    <p>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.<br>
    </p>
    <p>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).</p>
    <p>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?<br>
    </p>
    <p><br>
    </p>
    <blockquote type="cite">
      <pre class="ydpc1df829yiv0793103117moz-quote-pre">, and in this case a static route must be provided to the other local LAN networks.</pre>
    </blockquote>
    <p>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?</p>
    <p><br>
    </p>
    <blockquote type="cite">
      <pre class="ydpc1df829yiv0793103117moz-quote-pre">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.</pre>
    </blockquote>
    <p>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?<br>
    </p>
    <p><br>
    </p>
    <blockquote type="cite">
      <pre class="ydpc1df829yiv0793103117moz-quote-pre">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@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@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@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@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@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@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@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@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@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@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@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@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@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@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@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@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!

  
</pre>
      <br>
      <fieldset class="ydpc1df829yiv0793103117mimeAttachmentHeader"></fieldset>
      <pre class="ydpc1df829yiv0793103117moz-quote-pre">_______________________________________________
tinc mailing list
<a class="ydpc1df829yiv0793103117moz-txt-link-abbreviated" href="mailto:tinc@tinc-vpn.org" rel="nofollow" target="_blank">tinc@tinc-vpn.org</a>
<a class="ydpc1df829yiv0793103117moz-txt-link-freetext" href="https://www.tinc-vpn.org/cgi-bin/mailman/listinfo/tinc" rel="nofollow" target="_blank">https://www.tinc-vpn.org/cgi-bin/mailman/listinfo/tinc</a>
</pre>
    </blockquote>
    <pre class="ydpc1df829yiv0793103117moz-signature">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: <a class="ydpc1df829yiv0793103117moz-txt-link-freetext" href="https://www.blunix.org" rel="nofollow" target="_blank">https://www.blunix.org</a>

AG Charlottenburg, HRB 174906 B
CEO: Peter Thurner</pre>
  </div>
</div></div>_______________________________________________<br>tinc mailing list<br><a href="mailto:tinc@tinc-vpn.org" rel="nofollow" target="_blank">tinc@tinc-vpn.org</a><br><a href="https://www.tinc-vpn.org/cgi-bin/mailman/listinfo/tinc" rel="nofollow" target="_blank">https://www.tinc-vpn.org/cgi-bin/mailman/listinfo/tinc</a><br></div>
            </div>
        </div></body></html>