Hi everyone,
so after fixing the mistake Hamish pointed out, this ruleset appears to work just fine:
# vpn internal subnet
ip -6 route add <remote vpn subnet>/64 via <remote vpn ip> dev $INTERFACE
ip -6 route add <remote vpn subnet>/64 via <remote vpn ip> dev $INTERFACE
# remote host's public subnet
ip -6 route add <remote public subnet>/64 via <remote vpn ip> dev $INTERFACE
ip -6 route add <remote public ip> via <local default gateway> dev <local default interface>
ip -6 route add <remote public subnet>/64 via <remote vpn ip> dev $INTERFACE
ip -6 route add <remote public ip> via <local default gateway> dev <local default interface>
I verified this by using traceroute on both internal and external ips of all of my nodes. The benefit of using route specificity instead of ip rule is a smaller overhead.
Kind regards
Christopher
Gesendet: Dienstag, 07. Mai 2019 um 01:17 Uhr
Von: "Lars Kruse" <[email protected]>
An: [email protected]
Betreff: Re: very high traffic without any load
Von: "Lars Kruse" <[email protected]>
An: [email protected]
Betreff: Re: very high traffic without any load
Hello Christopher,
Am Mon, 6 May 2019 21:57:09 +0200
schrieb "Christopher Klinge" <[email protected]>:
> 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
_______________________________________________
tinc mailing list
[email protected]
https://www.tinc-vpn.org/cgi-bin/mailman/listinfo/tinc
Am Mon, 6 May 2019 21:57:09 +0200
schrieb "Christopher Klinge" <[email protected]>:
> 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
_______________________________________________
tinc mailing list
[email protected]
https://www.tinc-vpn.org/cgi-bin/mailman/listinfo/tinc
_______________________________________________ tinc mailing list [email protected] https://www.tinc-vpn.org/cgi-bin/mailman/listinfo/tinc
