Wireguard Site-to-Site, missing peer configuration


I’m having issues configuring endpoints of peers in Wireguard. The documentation says that you should be able to set the endpoint of peers, which is the same as Wireguard documentation says, and how you properly set up a site-to-site VPN. But when I try to set the endpoint I get errors that the configuration path is not valid. From what I can tell this means that VyOS can only act as a server.

vyos@vyos# set interfaces wireguard wg0 peer foobar address foobar.zoo:51820

  Invalid value
  Value validation failed
  Set failed

There’s also a path called “address” you can add to peer which from what I can tell isn’t something you can set on peers. The description suggests it might be what Wireguard calls “endpoint”, but when you try to set it it fails validation because it does not accept the :ip:port" format that endpoint actually requires.

vyos@vyos# set interfaces wireguard wg0 peer foobar
Possible completions:
   address      IP address of tunnel remote end
+  allowed-ips  IP addresses allowed to traverse the peer
   disable      disables peer
   persistent-keepalive  Interval to send keepalive messages
   port         Port number used to establish connection
   preshared-key  base64 encoded preshared key
   pubkey       base64 encoded public key 

But suddenly the documentation differs and it seems to be confusing endpoint with address on the interface it self.

vyos@vyos# set interfaces wireguard wg0 peer foobar address
Possible completions:
   <x.x.x.x>    IPv4 address to listen for incoming connections
   <h:h:h:h:h:h:h:h>  IPv6 address to listen for incoming connections

And just to test, since it might still work but I’ve tried to set the endpoint using address, but it fails input validation then.

vyos@vyos# set interfaces wireguard wg0 peer foobar address foobar.zoo:51820

  Invalid value
  Value validation failed
  Set failed

This means that I can’t set up a “proper site-to-site VPN”, since VyOS can only act as a server. I don’t have VyOS running on the other end, so I’m able to set up that peer with an endpoint. Since VyOS is running at home and the IP might change I’d prefer that it was the other way around at least, or better yet, let both sides try to initiate the tunnel.

vyos@vyos:~$ show host os
Linux vyos 4.19.157-amd64-vyos #1 SMP Sat Nov 14 07:09:34 UTC 2020 x86_64 GNU/Linux

Ok, so I just discovered that it was decided to change endpoint (which is what wireguard calls it, and correct term, if you ask me) and split it into “address” and “port”. This is not reflected in documentation and the documentation provided in the CLI is also wrong. Saying that endpoint is “IPv4 address to listen for incoming connections” is misleading at best. I would call it outright wrong.

Relevant issues where the change was introduced: https://phabricator.vyos.net/T1807

We’re not listening for anything, we’re connecting out to something. You don’t split up a URL into protocol, hostname, port and URI, so I don’t understand why you would split the endpoint into address and port like this change introduced. And when changes like that are introduced they shouldn’t be approved and merged before also documentation is updated.

Hello @vegardx, I see in the documentation port described
You need to use the port on both sides. I can’t understand your worries.

1 Like

Documentation is correct as is the help shown in the auto-completion, that you provided, and has been for quite some time. You’re just plain wrong on that one.

Specify a port as required by WG (not Vyos) and if you aren’t listening then don’t open the port at the firewall. However that is how WG works, not a Vyos introduced behaviour. If you don’t like that then head on over to the WG forums and see whether they want to update their design for you.

If you don’t specify a port one will randomly be assigned anyways.

Here is one of my outbound only wg connections

    wireguard wg0 {
        address xxxxxxxx
        description mullvad-us
        mtu 1420
        peer mullvad-us60 {
            persistent-keepalive 15
            port 51820
            pubkey xxxxxxxx
        private-key wg0

Splitting out the port or including it in the single line is more subjective than a technical constraint from an implementation perspective.

This topic was automatically closed 2 days after the last reply. New replies are no longer allowed.