Lars, interesting - do you have an example of what that might look like in the config file? Thanks! On Sun, May 5, 2019 at 6:00 PM Lars Kruse <lists at sumpfralle.de> wrote:> Hello Christoph, > > I am glad, that you discovered the source of the problem! > > > Am Sat, 4 May 2019 08:30:28 +0200 > schrieb "Christopher Klinge" <Christ.Klinge at web.de>: > > > The goal was that all connections between my nodes, regardless of whether > > they are destined for internal or external ipv6 addresses, end up using > the > > VPN. > > This is indeed a bit tricky. > I use a setup with a similar goal based on IPv4. I solved it there by > using DNAT > rules for the traffic to be routed through the VPN (based on destination > ports). > But DNAT is probably not appropriate in a modern IPv6 world :) > > In an IPv6 world you may want to use policy routing. > Simply add specific rules based on the incoming interface ("iif"), the > source > address ("from") or ports ("sport" / "dport"). The routes in the target > routing table can be filled by your "node-up" scripts. > > Cheers, > Lars > _______________________________________________ > 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/20190506/32b25810/attachment.html>
<html><head></head><body><div style="font-family: Verdana;font-size: 12.0px;"><div> <div>Hi,</div> <div> </div> <div>shouldn't these two rules work as well?</div> <div> </div> <div>ip route add <remote public ipv6>/64 via 1111:1::1</div> <div>ip route add <remote public ipv6>/0 dev<own internet interface></div> <div> </div> <div>According to my knowledge thus far, linux should pick routes based on specificity. Since /0 is more specific than /64, it should pick that rule whenever the remote public ipv6 is targeted directly. For all other ips in the remote host's subnet, it should pick the route through the vpn. I tried this and it resulted in the same infinite looping behaviour I experienced previously.</div> <div> </div> <div>Kind regards</div> <div>Christopher</div> <div> </div> <div> <div name="quote" style="margin:10px 5px 5px 10px; padding: 10px 0 10px 10px; border-left:2px solid #C3D9E5; word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;"> <div style="margin:0 0 10px 0;"><b>Gesendet:</b> Montag, 06. Mai 2019 um 14:28 Uhr<br/> <b>Von:</b> "Rafael Wolf" <rfwolf@gmail.com><br/> <b>An:</b> tinc@tinc-vpn.org<br/> <b>Betreff:</b> Re: very high traffic without any load</div> <div name="quoted-content"> <div> <div> <div>Lars, interesting - do you have an example of what that might look like in the config file?</div> <div> </div> <div>Thanks!</div> <div> </div> </div> <div class="gmail_quote"> <div class="gmail_attr">On Sun, May 5, 2019 at 6:00 PM Lars Kruse <<a href="mailto:lists@sumpfralle.de" onclick="parent.window.location.href='mailto:lists@sumpfralle.de'; return false;" target="_blank">lists@sumpfralle.de</a>> wrote:</div> <blockquote class="gmail_quote" style="margin: 0.0px 0.0px 0.0px 0.8ex;border-left: 1.0px solid rgb(204,204,204);padding-left: 1.0ex;">Hello Christoph,<br/> <br/> I am glad, that you discovered the source of the problem!<br/> <br/> <br/> Am Sat, 4 May 2019 08:30:28 +0200<br/> schrieb "Christopher Klinge" <<a href="mailto:Christ.Klinge@web.de" onclick="parent.window.location.href='mailto:Christ.Klinge@web.de'; return false;" target="_blank">Christ.Klinge@web.de</a>>:<br/> <br/>> The goal was that all connections between my nodes, regardless of whether<br/> > they are destined for internal or external ipv6 addresses, end up using the<br/> > VPN.<br/><br/> This is indeed a bit tricky.<br/> I use a setup with a similar goal based on IPv4. I solved it there by using DNAT<br/> rules for the traffic to be routed through the VPN (based on destination ports).<br/> But DNAT is probably not appropriate in a modern IPv6 world :)<br/> <br/> In an IPv6 world you may want to use policy routing.<br/> Simply add specific rules based on the incoming interface ("iif"), the source<br/> address ("from") or ports ("sport" / "dport"). The routes in the target<br/> routing table can be filled by your "node-up" scripts.<br/> <br/> Cheers,<br/> Lars<br/> _______________________________________________<br/> tinc mailing list<br/> <a href="mailto:tinc@tinc-vpn.org" onclick="parent.window.location.href='mailto:tinc@tinc-vpn.org'; return false;" target="_blank">tinc@tinc-vpn.org</a><br/> <a href="https://www.tinc-vpn.org/cgi-bin/mailman/listinfo/tinc" target="_blank">https://www.tinc-vpn.org/cgi-bin/mailman/listinfo/tinc</a></blockquote> </div> <br clear="all"/> <br/> --</div> _______________________________________________ tinc mailing list tinc@tinc-vpn.org <a href="https://www.tinc-vpn.org/cgi-bin/mailman/listinfo/tinc" target="_blank">https://www.tinc-vpn.org/cgi-bin/mailman/listinfo/tinc</a></div> </div> </div> </div></div></body></html>
On 7/5/19 5:57 am, Christopher Klinge wrote:> Hi, > shouldn't these two rules work as well? > ip route add <remote public ipv6>/64 via 1111:1::1 > ip route add <remote public ipv6>/0 dev<own internet interface> > According to my knowledge thus far, linux should pick routes based on > specificity. Since /0 is more specific than /64, it should pick that > rule whenever the remote public ipv6 is targeted directly. For all > other ips in the remote host's subnet, it should pick the route > through the vpn. I tried this and it resulted in the same infinite > looping behaviour I experienced previously.Did you mean /128 instead of /0? /0 is the entire internet. Hamish -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://www.tinc-vpn.org/pipermail/tinc/attachments/20190507/ef444d51/attachment-0001.html>
Hello Christopher, Am Mon, 6 May 2019 21:57:09 +0200 schrieb "Christopher Klinge" <Christ.Klinge at web.de>:> shouldn't these two rules work as well? > > ip route add <remote public ipv6>/64 via 1111:1::1 > ip route add <remote public ipv6>/0 dev<own internet interface> > > According to my knowledge thus far, linux should pick routes based on > specificity. Since /0 is more specific than /64, it should pick that rule > whenever the remote public ipv6 is targeted directly.Yes, that is my understanding, too. I think, the culprit is here: ip route add <remote public ipv6>/0 dev<own internet interface> I think, it should be the following instead: ip route add <remote public ipv6>/0 via <your_local_default_gateway> (I think, your "dev" route will lead to ARP requests on the local interface for public IP addresses - they obviously cannot resolve) Please note that my comments above are only based on my understanding of IPv4. Thus I may have missed some nuances of IPv6 ... Cheers, Lars
Hello Rafael, Am Mon, 6 May 2019 08:28:24 -0400 schrieb Rafael Wolf <rfwolf at gmail.com>:> Lars, interesting - do you have an example of what that might look like in > the config file?just guessing here, but the following should work: = preparations # add a new routing table: # (use "/etc/iproute2/rt_tables" if the directory does not exist) echo "42 foo" >>/etc/iproute2/rt_tables.d/custom.conf # Create an empty routing table. Peers will add routes to their public IP # address there, as soon as they connect. ip rule add lookup foo hosts/peer-up: #!/bin/sh # tinc meta traffic must use "main" instead of "foo" ip rule add to PEER_PUBLIC_IP/32 dport 655 lookup main # other traffic to the peer's public IP is now directed into the VPN ip route add PEER_PUBLIC_IP/32 dev "$INTERFACE" table foo Caveat: I am writing this down without testing. I hope, that helps. Cheers, Lars