Comment by majewsky | Hacker News Reader

Comment by majewsky | Hacker News Reader

Parent Full thread

Hi Jason, thanks for your work on Wireguard! I evaluated it just a few weeks ago for my own usecase, but couldn't get it to work yet. Maybe you can tell me what I'm missing.

My usecase is as follows: I have a number of systems without publicly-routable IPs (i.e. behind NAT in different private networks) and two servers with public IPs (let's call these "head1" and "head2"). I want to build an overlay network between all of these servers, so that they can all reach each other. Since any of the two head servers may be down for whatever reason and I may not always have time to immediately investigate the problem, I want to have a highly-available setup where, upon failure of one head node, traffic goes over to the other head node without long disruption. I tried to give the clients a configuration like this:

  [Interface]
  PrivateKey = ...
  ListenPort = 12345

  [Peer]
  PublicKey = ...
  Endpoint = head1:12345
  AllowedIPs = 0.0.0.0/0

  [Peer]
  PublicKey = ...
  Endpoint = head2:12345
  AllowedIPs = 0.0.0.0/0

But when I set up the wg0 interface with that configuration, it would discard the AllowedIPs setting for head1 upon finding the head2 peer with the same AllowedIPs value (at least according to `wg`). Am I doing something wrong, or is this an inherent limitation of Wireguard? (The fineprint: I did this two weeks or so ago and am recalling this from memory right now, so I may be wrong in the details.)

WireGuard enforces a very strict mapping between public keys and IP addresses, so you can't have two public keys with the same internal tunnelled IP address ("AllowedIPs"). This way you can have rules like "if it comes from the WireGuard interface and it's from 10.8.3.9, then it must be from public key ABCD," which make firewalling and ACLs and the general security posture a lot more straightforward.

In your case, it sounds like you want to change the AllowedIPs from one peer to the other based on some kind of metric you have for determining disruption. In this case, you can do that switch at runtime:

    $ wg set wg0 peer ABCD allowed-ips 0.0.0.0/0

or

    $ wg set wg0 peer EFG9 allowed-ips 0.0.0.0/0

Alternatively, if you wish to determine this disruption situation using traditional routing daemons, that set actual routes, as opposed to WireGuard AllowedIPs, then you could just have two separate WireGuard interfaces, and leave it to your routing daemon to decide which one to use.

The latter suggestion of using two wg interfaces sounds reasonable. I'll give it a shot, thanks!

You can't have overlapping AllowedIPs for peers on the same interface. Wireguard has to decide which encryption/decryption keys to use based on the AllowedIPs.

For your use case you need two wg Interfaces on each host (w/ different ListenPort and AllowedIPs=0.0.0.0/0) and a routing daemon (like bird).

So wireguard is focused on the use case of having a single central point where all the traffic has to go through? Reading throught the page it seemed it was more the tinc model of distributed P2P VPN overlay which to me seems much more powerful. Redundancy comes for free and performance is improved because you get direct links between nodes instead of having to proxy all the traffic.

Reply on news.ycombinator.com