4 ms·

> This section of the article is confusing at first because it talks about “road warrior” users (who generally have dynamic IP addresses) not being supported by

> This section of the article is confusing at first because it talks about “road warrior” users (who generally have dynamic IP addresses) not being supported by WireGuard. But this is not true; standard WireGuard happily works as long as as least one end (usually the central VPN concentrator) has a static IP address. Maybe I don't understand the issue to be solved (I was unfamiliar with the 'road warrior' term so I looked it up [1]), but I think both Avery Pennarun and Michael Tremer misunderstood what WireGuard is capable of. WireGuard works just fine when the physical network interfaces have dynamic IPs (on both ends even). You can use the basic wg or wg-quick tools to create a VPN server on a server with a dynamic IP and have clients connect from dynamic IPs. However, all the tunnel IPs must be static unlike e.g. OpenVPN where the server gives the client a tunnel IP during authentication. > (for example, so you can get to an office network whose home connection uses dynamic DNS). It’s true that plain WireGuard does not support this configuration out of the box. I have done literally that for over a year now. I cannot think of a way to interpret this that would make Avery's claims true. > Someday, WireGuard will need to be upgraded to support a second cipher suite. When this happens, users will be able to configure it peer-by-peer to allow one cipher suite or the other, or both, exactly as they would with any other VPN. That is not how I interpret what Donenfeld has said [2] about the future of WireGuard. I believe the software will get a v2 without backwards compatibility. However, even that is a non-issue because sysadmins can run both protocols in parallel during the transition. [1] https://en.wikipedia.org/wiki/Road_warrior_%28computing%29 https://en.wikipedia.org/wiki/Road_warrior_%28computing%29 [2] Page 3 of https://www.wireguard.com/papers/wireguard.pdf https://www.wireguard.com/papers/wireguard.pdf

CalChris 6y ago
Yes, it seemed to me that Donenfeld was pretty opinionated about 'updating breaks compatibility'. Donenfeld is the anti-Torvalds: we will break user space. This is the closest quote I could find. If holes are found in the underlying primitives, all endpoints will be required to update. Unlike IP packets, struct message_header doesn't even have a version number. I suppose type could be used for that since it's 32b. An interesting question is how will this play out with Wireguard going into the Linux kernel itself.
- XelNika 6y ago
  Breaking user space might not be popular with users, but it makes sense for security. Besides, anyone could build protocol negotiation on top of WireGuard v1/v2 if they wanted to. I'm not a kernel dev, but WireGuard v2 will probably be implemented as a separate kernel module so they can coexist. It makes sense to do it that way since they're practically entirely separate protocols.
  - CalChris 6y ago
    I’m not sure that coexistence works without a version number going over the wire.
    - XelNika 6y ago
      Sure it does. They are two separate packages, run on two separate network ports and completely incompatible. Just pretend that WireGuard v2 is unrelated to WireGuard. "OpenVPN and WireGuard coexistence doesn't work without a version number going over the wire" would be an absurd statement and the same applies to WireGuard and WireGuard's descendants.
      - CalChris 6y ago
        I suppose you’re right. It is left to the user to not try to connect v1 to v2. Not sure what happens if on Tuesday morning I connect my v1 client to what was on Monday night a v1 server. That said, I admire opinionated design.
        XelNika 6y ago
        The two versions can run in parallel so you will never be in a situation where the sysadmin is forced to take down the v1 server to set up a v2 server. It's the sysadmins responsibility not to put users in that situation. Users might try to use the wrong version at first, but there's no reason for an admin to break the working VPN before the transition is complete.
    - 6y ago

CalChris 6y ago

Yes, it seemed to me that Donenfeld was pretty opinionated about 'updating breaks compatibility'. Donenfeld is the anti-Torvalds: we will break user space. This is the closest quote I could find. If holes are found in the underlying primitives, all endpoints will be required to update. Unlike IP packets, struct message_header doesn't even have a version number. I suppose type could be used for that since it's 32b. An interesting question is how will this play out with Wireguard going into the Linux kernel itself.

XelNika 6y ago
Breaking user space might not be popular with users, but it makes sense for security. Besides, anyone could build protocol negotiation on top of WireGuard v1/v2 if they wanted to. I'm not a kernel dev, but WireGuard v2 will probably be implemented as a separate kernel module so they can coexist. It makes sense to do it that way since they're practically entirely separate protocols.
- CalChris 6y ago
  I’m not sure that coexistence works without a version number going over the wire.
  - XelNika 6y ago
    Sure it does. They are two separate packages, run on two separate network ports and completely incompatible. Just pretend that WireGuard v2 is unrelated to WireGuard. "OpenVPN and WireGuard coexistence doesn't work without a version number going over the wire" would be an absurd statement and the same applies to WireGuard and WireGuard's descendants.
    - CalChris 6y ago
      I suppose you’re right. It is left to the user to not try to connect v1 to v2. Not sure what happens if on Tuesday morning I connect my v1 client to what was on Monday night a v1 server. That said, I admire opinionated design.
      - XelNika 6y ago
        The two versions can run in parallel so you will never be in a situation where the sysadmin is forced to take down the v1 server to set up a v2 server. It's the sysadmins responsibility not to put users in that situation. Users might try to use the wrong version at first, but there's no reason for an admin to break the working VPN before the transition is complete.
  - 6y ago