Me and my son are running Tinc over 5 nodes, 3 of them got public address and we using them as server. Each node has its own Lan subnet 192.168.0.0/24. Originally we ran network on Openwrt routers with Tinc many years without any problem, but due to limited RAM on routes and change of one router to not Openwrt supported model, we decided to transfer Tinc installation on Raspberry Pi-s in LAN. In this configuration we experienced following problem: Some LAN hosts became unreachable. Example: Setup is following: Router *Type: *static *Address: *192.168.2.250 *Netmask: *255.255.255.0 *Gateway: *192.168.88. 1 has static route set for LAN : Kernel IP routing table Destination Gateway Genmask Flags Metric Ref Use Iface 0.0.0.0 192.168.88.1 0.0.0.0 UG 0 0 0 eth1 192.168.0.0 192.168.2.5 255.255.0.0 UG 0 0 0 br-lan 192.168.2.0 0.0.0.0 255.255.255.0 U 0 0 0 br-lan 192.168.88.0 0.0.0.0 255.255.255.0 U 0 0 0 eth1 where 192.168.2.5 is raspi with tinc . Tinc routing table follows:Kernel IP routing table Destination Gateway Genmask Flags Metric Ref Use Iface 0.0.0.0 192.168.2.250 0.0.0.0 UG 202 0 0 eth0 192.168.0.0 0.0.0.0 255.255.0.0 U 0 0 0 mojtinc 192.168.2.0 0.0.0.0 255.255.255.0 U 202 0 0 eth0 Some (or all other LAN) hosts are unreachable until policy based routing added: sudo ip rule add from 192.168.0.0/16 dev mojtinc table 1 sudo ip route add 192.168.2.0/24 <http://192.168.7.0/24> via 192.168.2.5 dev eth0 table 1 which sometimes caused that hosts previously reachable are out. Additionally we put policy based routing in in tinc-up: #!/bin/sh ifconfig $INTERFACE 192.168.2.5 netmask 255.255.0.0 ip rule add from 192.168.0.0/16 dev $INTERFACE table 1 ip route add 192.168.2.0/24 via 192.168.2.250 proto static dev eth0 table 1 but it si lost after some time (not after reboot)and is working just some hours after Tinc restart. We are suspicious that the problem is connected to following behavior: Connect to the host in other Tinc is routed by router 192.168.2.250 to raspi 192.168.2.5 interface tinc (mojtinc) and go further to other raspi in remote LAN. Input is coming directly to Tinc interface in my Raspi 192.168.2.5 and then directly to host in LAN. It means it is triangle and it fails on some clients. That was the reason to introduce this policy based routing as work around. I am afraid we are on the wrong path. Any ideas? Many thanks in advance. Regards Kveto <http://www.avg.com/email-signature?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=webmail> Bez virů. www.avg.com <http://www.avg.com/email-signature?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=webmail> <#DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2> -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://www.tinc-vpn.org/pipermail/tinc/attachments/20180425/2510ce27/attachment.html>
This may help... I see you're using a mix of the old and new tools. You could try use 'route' with ipconfig rather than 'ip route'. Or you could use 'ip link' instead of ipconfig. Mike Sent from my iPhone On 26 Apr 2018, at 4:59 am, Kvetoslav Jansík <kjansik at gmail.com<mailto:kjansik at gmail.com>> wrote: Me and my son are running Tinc over 5 nodes, 3 of them got public address and we using them as server. Each node has its own Lan subnet 192.168.0.0/24<http://192.168.0.0/24>. Originally we ran network on Openwrt routers with Tinc many years without any problem, but due to limited RAM on routes and change of one router to not Openwrt supported model, we decided to transfer Tinc installation on Raspberry Pi-s in LAN. In this configuration we experienced following problem: Some LAN hosts became unreachable. Example: Setup is following: Router Type: static Address: 192.168.2.250 Netmask: 255.255.255.0 Gateway: 192.168.88. 1 has static route set for LAN : Kernel IP routing table Destination Gateway Genmask Flags Metric Ref Use Iface 0.0.0.0 192.168.88.1 0.0.0.0 UG 0 0 0 eth1 192.168.0.0 192.168.2.5 255.255.0.0 UG 0 0 0 br-lan 192.168.2.0 0.0.0.0 255.255.255.0 U 0 0 0 br-lan 192.168.88.0 0.0.0.0 255.255.255.0 U 0 0 0 eth1 where 192.168.2.5 is raspi with tinc . Tinc routing table follows:Kernel IP routing table Destination Gateway Genmask Flags Metric Ref Use Iface 0.0.0.0 192.168.2.250 0.0.0.0 UG 202 0 0 eth0 192.168.0.0 0.0.0.0 255.255.0.0 U 0 0 0 mojtinc 192.168.2.0 0.0.0.0 255.255.255.0 U 202 0 0 eth0 Some (or all other LAN) hosts are unreachable until policy based routing added: sudo ip rule add from 192.168.0.0/16<http://192.168.0.0/16> dev mojtinc table 1 sudo ip route add 192.168.2.0/24<http://192.168.7.0/24> via 192.168.2.5 dev eth0 table 1 which sometimes caused that hosts previously reachable are out. Additionally we put policy based routing in in tinc-up: #!/bin/sh ifconfig $INTERFACE 192.168.2.5 netmask 255.255.0.0 ip rule add from 192.168.0.0/16<http://192.168.0.0/16> dev $INTERFACE table 1 ip route add 192.168.2.0/24<http://192.168.2.0/24> via 192.168.2.250 proto static dev eth0 table 1 but it si lost after some time (not after reboot)and is working just some hours after Tinc restart. We are suspicious that the problem is connected to following behavior: Connect to the host in other Tinc is routed by router 192.168.2.250 to raspi 192.168.2.5 interface tinc (mojtinc) and go further to other raspi in remote LAN. Input is coming directly to Tinc interface in my Raspi 192.168.2.5 and then directly to host in LAN. It means it is triangle and it fails on some clients. That was the reason to introduce this policy based routing as work around. I am afraid we are on the wrong path. Any ideas? Many thanks in advance. Regards Kveto [https://ipmcdn.avast.com/images/icons/icon-envelope-tick-green-avg-v1.png]<http://www.avg.com/email-signature?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=webmail> Bez virů. www.avg.com<http://www.avg.com/email-signature?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=webmail> _______________________________________________ tinc mailing list tinc at tinc-vpn.org<mailto: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/20180425/f06f6eb6/attachment-0001.html>
Mike, many thanks for advice.We were not aware about problem with mix route and iproute2. Anyway, it didn't solve the problem, we added the routing policy commands after the problem occurs to remedy it. It seems that the problem is connected with the fact the incoming connection is direct to tinc node and outcoming is routed via router to tinc interface. Kind regards Kveto 2018-04-25 22:21 GMT+02:00 Mike Bentzen <mike at bentzen.com.au>:> This may help... I see you're using a mix of the old and new tools. > > You could try use 'route' with ipconfig rather than 'ip route'. Or you > could use 'ip link' instead of ipconfig. > > Mike > > Sent from my iPhone > > On 26 Apr 2018, at 4:59 am, Kvetoslav Jansík <kjansik at gmail.com> wrote: > > Me and my son are running Tinc over 5 nodes, 3 of them got public address > and we using them as server. Each node has its own Lan subnet > 192.168.0.0/24. Originally we ran network on Openwrt routers with Tinc > many years without any problem, but due to limited RAM on routes and change > of one router to not Openwrt supported model, we decided to transfer Tinc > installation on Raspberry Pi-s in LAN. > In this configuration we experienced following problem: > Some LAN hosts became unreachable. Example: > Setup is following: Router > *Type: *static > *Address: *192.168.2.250 > *Netmask: *255.255.255.0 > *Gateway: *192.168.88. 1 has static route set for LAN : > Kernel IP routing table > Destination Gateway Genmask Flags Metric Ref Use > Iface > 0.0.0.0 192.168.88.1 0.0.0.0 UG 0 0 0 > eth1 > 192.168.0.0 192.168.2.5 255.255.0.0 UG 0 0 0 > br-lan > 192.168.2.0 0.0.0.0 255.255.255.0 U 0 0 0 > br-lan > 192.168.88.0 0.0.0.0 255.255.255.0 U 0 0 0 > eth1 > where 192.168.2.5 is raspi with tinc . > > Tinc routing table follows:Kernel IP routing table > Destination Gateway Genmask Flags Metric Ref Use > Iface > 0.0.0.0 192.168.2.250 0.0.0.0 UG 202 0 0 > eth0 > 192.168.0.0 0.0.0.0 255.255.0.0 U 0 0 0 > mojtinc > 192.168.2.0 0.0.0.0 255.255.255.0 U 202 0 0 > eth0 > > Some (or all other LAN) hosts are unreachable until policy based routing > added: > sudo ip rule add from 192.168.0.0/16 dev mojtinc table 1 > sudo ip route add 192.168.2.0/24 <http://192.168.7.0/24> via 192.168.2.5 > dev eth0 table 1 > > which sometimes caused that hosts previously reachable are out. > Additionally we put policy based routing in in tinc-up: > #!/bin/sh > ifconfig $INTERFACE 192.168.2.5 netmask 255.255.0.0 > ip rule add from 192.168.0.0/16 dev $INTERFACE table 1 > ip route add 192.168.2.0/24 via 192.168.2.250 proto static dev eth0 table > 1 > > but it si lost after some time (not after reboot)and is working just some > hours after Tinc restart. > > We are suspicious that the problem is connected to following behavior: > Connect to the host in other Tinc is routed by router 192.168.2.250 to > raspi 192.168.2.5 interface tinc (mojtinc) and go further to other raspi in > remote LAN. Input is coming directly to Tinc interface in my Raspi > 192.168.2.5 and then directly to host in LAN. It means it is triangle and > it fails on some clients. > That was the reason to introduce this policy based routing as work around. > I am afraid we are on the wrong path. > Any ideas? > > Many thanks in advance. > Regards > Kveto > > > > > > > > > <http://www.avg.com/email-signature?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=webmail> Bez > virů. www.avg.com > <http://www.avg.com/email-signature?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=webmail> > <#m_5706915869621995840_DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2> > > _______________________________________________ > tinc mailing list > tinc at tinc-vpn.org > https://www.tinc-vpn.org/cgi-bin/mailman/listinfo/tinc > > > _______________________________________________ > 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/20180430/8b9b193a/attachment.html>