4 ms·

The article is obviously a promotional piece for ipfire and so exists to promote a certain angle on the topic. Even understanding this, though, it's strikes me

The article is obviously a promotional piece for ipfire and so exists to promote a certain angle on the topic. Even understanding this, though, it's strikes me as pretty questionable. The section discussing dynamic IP addresses seems to be based on a misunderstanding of Wireguard. The IP addresses that must be statically established in Wireguard are the addresses used inside of the tunnel, and are independent of the public (internet) IPs of the machines involved. The wg-dynamic daemon mentioned is a system for dynamically allocating IP addresses in the tunnel, and has so far not been completed, at least in part because it's not very obvious why you would want to do this (although in general the development of an in-band configuration standard for Wireguard has useful implications). Wireguard allows you to identify the endpoint using a DNS name, which means you can handle a 'server' with a dynamic IP address by dynamically updating the DNS record - a common approach that is no doubt exactly what ipfire supports doing for ipsec. In the end, though, the article just suffers from being an apples-to-oranges comparison. Wireguard is a VPN tunnel protocol implementation, ipfire is some sort of GUI frontend for managing a bunch of network tools. Of course ipfire has quite a few more features than wireguard.

tssva 7y ago
Although the article is confused regarding dynamic IP addresses your solution of identifying the endpoint using a DNS name is also not a complete solution when using Wireguard. The Wireguard tool, wg, resolves the DNS name and then sets the ip address for the endpoint which the wireguard protocol implementation then uses. Since the wireguard protocol implementation doesn't do any DNS resolution if the endpoint address changes even if the DNS record is updated wireguard will never know. Instead another tool needs to check the DNS record of the endpoint periodically either at some fixed interval and/or based upon the TTL of the DNS record. If the record changes it then needs to update the configuration of the wireguard protocol implementation.
- cyphar 7y ago
  This is not always required. WireGuard peers can roam freely very similarly to Mosh (if one peer receives an authenticated message from one of its peers from a different IP address, it will update the gateway of that peer and will send all subsequent packets to that IP address). But to be fair, this doesn't work perfectly (especially if you have certain firewall rules that block UDP packets if they're not part of the what the firewall thinks is the same "connection", if both peers change their IP at the same time, or if the peer whose IP changed was rebooted or reconfigured before the other peer received a packet from its new IP addreds) but it really does work surprisingly well. For those (important) corner-cases, I would imagine that higher-level tooling such as NetworkManager would do the DNS checks you're talking about.
  - jcrawfordor 7y ago
    Right, the free roaming tends to be on "the other side" though. This is a bit confusing to talk about because Wireguard does not have a concept of "client" and "server" and either side can nominally initiate the tunnel. However, in roaming configurations, typically only one side will have the information to initiate the connection (endpoint) and so there's a tendency to call this the "client." The non-roaming end (end with a known endpoint) will update the IP of the roaming end every time a handshake occurs. The issue the OP is getting at though is when both ends are roaming. In this case the, er, "more roaming" peer needs some way to find the other peer. There are a lot of technically interesting ways that we could solve this problem, but in practice it's pretty much always solved by dynamically updating a DNS record. I would say Wireguard handles this scenario about as well as anything else (maybe a little worse, see sibling comment). Another approach would be using a "meet-me" relay with a fixed IP, such as TURN. This also has the advantage of handling NAT on both sides (which would be a common issue with a roaming-to-roaming situation). I can't think of any reason it's impossible to run Wireguard through TURN but I can't find any examples of anyone doing so, likely in part because the TURN client is usually embedded in the application and is a bit complicated. Still, might be a hobby project to implement it for Wireguard.
- jcrawfordor 7y ago
  This is an issue, but in typical dynamic IP situations the IP tends to only change when there's some sort of disruption that prevents renewal and not very frequently (e.g. I've held a Comcast consumer IP for over a year before), which tends to mitigate this effect since the IP changing "out from underneath" the tunnel won't occur. Most dynamic DNS schemes, with DNS caching added on top, also tend to result in pretty long (hour +) delays on IP updates to DNS which further make this a bit of a non-issue. That said, I do believe both IPv6 and OpenVPN will have this exact same problem - IP change will not be reflected until something forces setup to repeat. The difference would be that these, at least I do believe, will re-resolve on retries. Wireguard doesn't really have a sense of "retrying the connection" which makes it sort of philosophically difficult for it to do so.
  - izacus 7y ago
    One very common scenario where WireGuard fails - you have a WG persistent VPN enabled and you actually move into the network that has the VPN endpoint. The IP of WG endpoint changes from a public one to a local one.
    - kotharia 7y ago
      I don't have this problem. If the endpoint is accessible through the public address even in the internal network then everything just works.
    - vetinari 7y ago
      This keeps happening to me all the time, and it is no problem. Once I move into the network that has the respective VPN endpoint, the subnets that are routable via wg become routable via ethernet/wifi which have higher priority, so the traffic will go directly.
- loeg 7y ago
  https://github.com/WireGuard/wireguard-tools/tree/master/contrib/reresolve-dns https://github.com/WireGuard/wireguard-tools/tree/master/con...
upofadown 7y ago
The article only directly compares WireGuard with IPsec and OpenVPN. IPFire was only mentioned twice in passing.
- Slavius 7y ago
  Yet still it spreads lies. There's not only 4 pieces of information needed to establish IPsec (they even cannot count as they mention 5 pieces). In addition to named remote and local IP addresses, subnets and a pre-shared key you also need: * mode of operation (transport or tunnel) * exchange mode (base, main, aggressive or ikev2) * policy mode of operation (encrypt and/or protect - yes encryption is optional with IPsec) * Phase 1 parameters (hashing algorithm(s) + encryption algorithm(s)), key lifetime in bytes or seconds * Whether you/remote uses a PFS (if so, then also DH Group) * Phase 2 parameters (hashing algorithm(s) + encryption algorithm(s)), key lifetime in bytes or seconds * Whether or not to use NAT traversal (changes the protocols and ports needed to be opened on the firewall(s)) If you don't know some of these parameters chances are you won't be able to establish the tunnel no matter how hard you try. Plus you need to know all the vendor quirks as establishing IPsec from Cisco to Fortigate or Sophos is not straightforward. Then you may end up playing with NAT-exclusions, SNAT/DNAT if both sides of the tunnel have the same or overlapping IP ranges. Setting up IPsec is definitely not an exchange of 4 parameters...
  - Spivak 7y ago
    I think the point is that if you “WireGuard-ify” IPSec and just fix all those parameters (e.g. take the vendor defaults) then you’re left with 5 pieces of information. If the value of WG is just that it forces all these parameters to be static then the best thing we could do is come up with the “WireGuard” IPSec profile call it a day.
    - Slavius 7y ago
      Are you saying that fixed parameters chosen for no apparent reason by the WireGuard developers are better than modularity and interoperability of IPsec? What if in a few months ChaCha20 gets proven insecure due to collisions found or easy factorisation? What can WireGuard offer to mitigate that? Shouldn't then also browsers implement only TLS1.3 and ed25519 ciphers because they are currently the most secure?
ngold 7y ago
Sounds like wireguard is just positioning into corporate clients.
Legogris 7y ago
It's funny that the author mentions IPv6 as an argument when IPFire itself does not support it.

tssva 7y ago

Although the article is confused regarding dynamic IP addresses your solution of identifying the endpoint using a DNS name is also not a complete solution when using Wireguard. The Wireguard tool, wg, resolves the DNS name and then sets the ip address for the endpoint which the wireguard protocol implementation then uses. Since the wireguard protocol implementation doesn't do any DNS resolution if the endpoint address changes even if the DNS record is updated wireguard will never know. Instead another tool needs to check the DNS record of the endpoint periodically either at some fixed interval and/or based upon the TTL of the DNS record. If the record changes it then needs to update the configuration of the wireguard protocol implementation.

cyphar 7y ago
This is not always required. WireGuard peers can roam freely very similarly to Mosh (if one peer receives an authenticated message from one of its peers from a different IP address, it will update the gateway of that peer and will send all subsequent packets to that IP address). But to be fair, this doesn't work perfectly (especially if you have certain firewall rules that block UDP packets if they're not part of the what the firewall thinks is the same "connection", if both peers change their IP at the same time, or if the peer whose IP changed was rebooted or reconfigured before the other peer received a packet from its new IP addreds) but it really does work surprisingly well. For those (important) corner-cases, I would imagine that higher-level tooling such as NetworkManager would do the DNS checks you're talking about.
- jcrawfordor 7y ago
  Right, the free roaming tends to be on "the other side" though. This is a bit confusing to talk about because Wireguard does not have a concept of "client" and "server" and either side can nominally initiate the tunnel. However, in roaming configurations, typically only one side will have the information to initiate the connection (endpoint) and so there's a tendency to call this the "client." The non-roaming end (end with a known endpoint) will update the IP of the roaming end every time a handshake occurs. The issue the OP is getting at though is when both ends are roaming. In this case the, er, "more roaming" peer needs some way to find the other peer. There are a lot of technically interesting ways that we could solve this problem, but in practice it's pretty much always solved by dynamically updating a DNS record. I would say Wireguard handles this scenario about as well as anything else (maybe a little worse, see sibling comment). Another approach would be using a "meet-me" relay with a fixed IP, such as TURN. This also has the advantage of handling NAT on both sides (which would be a common issue with a roaming-to-roaming situation). I can't think of any reason it's impossible to run Wireguard through TURN but I can't find any examples of anyone doing so, likely in part because the TURN client is usually embedded in the application and is a bit complicated. Still, might be a hobby project to implement it for Wireguard.
jcrawfordor 7y ago
This is an issue, but in typical dynamic IP situations the IP tends to only change when there's some sort of disruption that prevents renewal and not very frequently (e.g. I've held a Comcast consumer IP for over a year before), which tends to mitigate this effect since the IP changing "out from underneath" the tunnel won't occur. Most dynamic DNS schemes, with DNS caching added on top, also tend to result in pretty long (hour +) delays on IP updates to DNS which further make this a bit of a non-issue. That said, I do believe both IPv6 and OpenVPN will have this exact same problem - IP change will not be reflected until something forces setup to repeat. The difference would be that these, at least I do believe, will re-resolve on retries. Wireguard doesn't really have a sense of "retrying the connection" which makes it sort of philosophically difficult for it to do so.
- izacus 7y ago
  One very common scenario where WireGuard fails - you have a WG persistent VPN enabled and you actually move into the network that has the VPN endpoint. The IP of WG endpoint changes from a public one to a local one.
  - kotharia 7y ago
    I don't have this problem. If the endpoint is accessible through the public address even in the internal network then everything just works.
  - vetinari 7y ago
    This keeps happening to me all the time, and it is no problem. Once I move into the network that has the respective VPN endpoint, the subnets that are routable via wg become routable via ethernet/wifi which have higher priority, so the traffic will go directly.
loeg 7y ago
https://github.com/WireGuard/wireguard-tools/tree/master/contrib/reresolve-dns https://github.com/WireGuard/wireguard-tools/tree/master/con...

upofadown 7y ago

The article only directly compares WireGuard with IPsec and OpenVPN. IPFire was only mentioned twice in passing.

Slavius 7y ago
Yet still it spreads lies. There's not only 4 pieces of information needed to establish IPsec (they even cannot count as they mention 5 pieces). In addition to named remote and local IP addresses, subnets and a pre-shared key you also need: * mode of operation (transport or tunnel) * exchange mode (base, main, aggressive or ikev2) * policy mode of operation (encrypt and/or protect - yes encryption is optional with IPsec) * Phase 1 parameters (hashing algorithm(s) + encryption algorithm(s)), key lifetime in bytes or seconds * Whether you/remote uses a PFS (if so, then also DH Group) * Phase 2 parameters (hashing algorithm(s) + encryption algorithm(s)), key lifetime in bytes or seconds * Whether or not to use NAT traversal (changes the protocols and ports needed to be opened on the firewall(s)) If you don't know some of these parameters chances are you won't be able to establish the tunnel no matter how hard you try. Plus you need to know all the vendor quirks as establishing IPsec from Cisco to Fortigate or Sophos is not straightforward. Then you may end up playing with NAT-exclusions, SNAT/DNAT if both sides of the tunnel have the same or overlapping IP ranges. Setting up IPsec is definitely not an exchange of 4 parameters...
- Spivak 7y ago
  I think the point is that if you “WireGuard-ify” IPSec and just fix all those parameters (e.g. take the vendor defaults) then you’re left with 5 pieces of information. If the value of WG is just that it forces all these parameters to be static then the best thing we could do is come up with the “WireGuard” IPSec profile call it a day.
  - Slavius 7y ago
    Are you saying that fixed parameters chosen for no apparent reason by the WireGuard developers are better than modularity and interoperability of IPsec? What if in a few months ChaCha20 gets proven insecure due to collisions found or easy factorisation? What can WireGuard offer to mitigate that? Shouldn't then also browsers implement only TLS1.3 and ed25519 ciphers because they are currently the most secure?

ngold 7y ago

Sounds like wireguard is just positioning into corporate clients.

Legogris 7y ago

It's funny that the author mentions IPv6 as an argument when IPFire itself does not support it.