No announcement yet.

We Could See WireGuard Upstreamed In The Linux Kernel In 2018

  • Filter
  • Time
  • Show
Clear All
new posts

  • #11
    In addition to being simpler, it is wat faster than openVPN. Check out the benchmarks page.


    • #12
      Originally posted by s.ivanov View Post

      While OpenVPN CAN work over TCP it is not the default nor recommended setup
      Personally, I would recommend use TCP/IP with OpenVPN. Whether you like NAT or not, it is very common - and it can be a real pain for UDP. With TCP/IP, you have no problem with clients inside NAT networks or other complications - and on the server side, if your server is behind a NAT router all you need is a simple TCP port forward. I have run OpenVPN TCP connections over nested ssh tunnels and other OpenVPN links - it all works flawlessly.

      Yes, UDP is more efficient - and when it works, it works well. But when you move off a simple local network, UDP might work - but it might quickly become a PITA.

      So for me, a new VPN technology that is UDP only is a waste of time. It is maybe a replacement for horrors like IPSec, but not for the flexibility of OpenVPN. Make it support UDP and TCP - then you've got something really useful. For simple setups you can then use UDP for efficiency, and for complex setups you can use TCP for better routability.


      • #13
        Okay, too many replies. I reckon I was misinformed, I'm sorry. It seems more interesting now. Thanks a lot of the feedback. I would read more, but I need to stop procrastinating and back to study.

        About bloat: Why? That protocol might not be one protocol, but a family of protocols. Currently there are excesive "de facto" standards (many of them not reverse engineered of it's authors quite reactionary against third party implementations, like WhatsApp), many of them they have inherent aging signs and/or design issues. Why need a VPN for certain situations only? What about using VPNs per default whatever possible?

        TCP/IP? IPv6 solves many things (but not everything! It's still a centralized protocol), but it has a very slow deployment in many countries (like mine). I agree NATs are the problem, but it's a problem that isn't going to disapprear anytime soon, so clever and robust "workarounds" should be made meanwhile. And the current Internet infraestructure is far from perfect even in "first world" countries (the others might be extremely censored, be extremely expensive for the average user and/or become an absolute crap... even using these old analog modems many of us used in the early 80-90s), it has too many holes and ISPs can do extremely horrible things in their networks. It's easy to say that's not the problem of the protocol implementations, but I think in order to become a success it must be robust in this horrible non-Star-Trek-like reality (that's one of the reasons Git got popular, because it seems to work reliably even in the shittiest Internet connection of the universe).

        If WireGuard can become the lower layer of better replacements to specific-purpose "protocols" (they are more than protocols, but I mention it that way to simplify it) than the current used ones: That would be amazing! I want to see that!