Built-in Roaming is limited due to a design fault adding STUN and TURN support would be good and make wire-guard connections more durable.
oiaohm at gmail.com
Wed Jan 18 06:55:25 CET 2017
On Sun, Jan 15, 2017 at 6:39 PM, Dan Lüdtke <mail at danrl.com> wrote:
> Hi Peter,
> I followed this thread and like to express some concerns. Although I see the problem and ran into it myself, I would like to see a solution outside the wireguard code. Like the one Jason proposed or even a new approach. I am afraid that network layers problems (legacy IP and especially NAT) are about to uglify yet another beautiful protocol. None of the problems stated in this thread have I ever observed in an dual stack or in a IP (read IPv6) environment. This is all inconvenience that legacy IP (read IPv4) brings and that is caused by ten+ years of overprovisioning and not taking care of the network layer of the infrastructure. It is 2017, run IPv6. There should not be a single line of code in wireguard that deals with broken infrastructure. There is plenty of room for all kinds of workarounds in the userspace. Like the scripts in the Wireguard repository. I see the problem, agree on it, but It is out of the scope for wireguard to solve. The infrastructure must be able to somehow connect to peers via UDP. That is I think the least one can expect from a network layer. Whatever _outside_ magic it may need due to historical protocol usage.
> My concerns expressed and all that said, I would love to see some code or PoC. Code and pcaps are king :)
> I solved the problem using ipv6 only when I ran into it. May require to finally invest in state of the art layer 3 protocol usage in some cases. However, it's overdue anyway. Wireguards roaming feature tool care of the sites where even the ipv6 prefix changes from time to time. HTH.
I am sorry to say double nat happens even in IPv6 not common in most
countries. You find it when you have country firewalls. Nat
issues are not fixed by going IPv6 only reduced how often people will
hit them. Only delayed until the point that was giving you NAT issues
under IPv4 decides to update their hardware to IPv6 and leaves the
same Nat settings in place.
IPv6 has all the same nat configurations as IPv4. The larger address
range of ipv6 means you should not need to do it. But if country or
company wants to create a internet access limitation point forcing
all traffic to be NAT converted before internet access is one of those
Calling NAT legacy in IPv6 has something very wrong. If you are
behind a nat that is IPv6 aware even attempting to tunnel out by ipv4
does not work. Even if everyone was using IPv6 right now there
would still be users due to country and carrier ideals behind all the
types of NAT STUN rfc documents.
If NAT was not part of IPv6 systems in the same forms as what was in
IPv4 you would have an arguement. You have made a big error in
thinking that the problem of punching though NAT disappears when IPv6
is deployed. The need to punch though NAT with IPv6 reduces are
places switch to IPv6 but you have the stubborn hold outs(government
regulations stating nats be used) or the incompetent operators who
duplicate configuration from IPv4 to IPv6 so leaving carrier NAT in
place or Carriers intentionally putting NAT to have two tier pricing
for business and home. Yes that dual stack stunt you are currently
using to get around NAT if you carrier upgrades to a smarter IPv6/IPv4
NAT is going to fail over night as your direct connection by IPv6
Why would a carrier intentionally deploy a NAT that STUN and other NAT
punching solutions cannot cope with even when you have IPv6 simple so
they can charge 2 different plans 1 for home and 1 for business of
course those on home who are not meant to be running servers get stuck
behind the NAT. NAT is not just about over-provisioning it also
about being a jerk. If NAT was only used for over-provisioning then
IPv6 increased addresses would make it disappear problem is it also
used to limited what users can do with their ISP account.
Dan your IPv6 work around only working because you are not seeing
ip/v6 aware NATs. In a world of pure IPV6 like it or not NAT
punching and working around is part of it. Wireguard current
roaming feature will fail when it hitting different IPv6 nats as the
change address packet will be blocked for the same reason as being
from a IP address that the NAT has not communicated with. Dan you
are not alone thinking that IPv6 fixes more than what it does because
their carriers have not updated their hardware or their carriers have
decided for IPv6 to reduce the NAT count..
More information about the WireGuard