jradxl at yahoo.com
2019-Feb-08 21:55 UTC
Problem with connecting another subnet (Peter Thurner)
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 not172.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 Unknownroot 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 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 not172.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 Unknownroot 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 _______________________________________________ tinc mailing list tinc at tinc-vpn.org https://www.tinc-vpn.org/cgi-bin/mailman/listinfo/tinc -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://www.tinc-vpn.org/pipermail/tinc/attachments/20190208/7f367876/attachment-0001.html> -------------- next part -------------- A non-text attachment was scrubbed... Name: John-Network-Diagram-v0.1.pdf Type: application/pdf Size: 59520 bytes Desc: not available URL: <http://www.tinc-vpn.org/pipermail/tinc/attachments/20190208/7f367876/attachment-0001.pdf>
Apparently Analagous Threads
Wisdom of the Ancients
