Wireguard issues

[AWHarvard]

Hi together,
setting up wireguard i’ve discovered two issues.

1. Adding a (validated and known working) private-key to the interface using the private-key option seems to take no affect.

set interfaces wireguard wg01 address ‘192.168.2.2/24’
set interfaces wireguard wg01 port ‘51820’
set interfaces wireguard wg01 private-key ‘private-key-here’
commit
Wireguard private-key not found! Execute: "run generate wireguard [default-keypair|named-keypairs]"

2. Not able to set the peers endpoint (as described in the wiki https://wiki.vyos.net/wiki/Wireguard vyos should be the client):

set interfaces wireguard wg01 peer SERVER
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

There is no endpoint option at all, also trying to set it despite the possible completions returns:

Configuration path: interfaces wireguard wg01 peer SERVER [endpoint] is not valid.

Tested with 1.3-rolling-202011180217 and 1.3-rolling-202101040217

[phillipmcmahon]

Hey there.

1. I believe you can only have wg instances names wg0-wg9. I.e. use wg1 and not wg01. Ensure you have private.key and public.key in /config/auth/wireguard/wg1 if you want to avoid secret key material directly in your config.boot file.

2. Are you trying to define a peer you are making an outbound connection to, or a peer that is allowed to connect in?

For the former you would do something like this

set interfaces wireguard wg0 address xxxx
set interfaces wireguard wg0 description 'mullvad-us'
set interfaces wireguard wg0 mtu '1420'
set interfaces wireguard wg0 peer mullvad-us60 address '89.45.90.93'
set interfaces wireguard wg0 peer mullvad-us60 allowed-ips '0.0.0.0/0'
set interfaces wireguard wg0 peer mullvad-us60 persistent-keepalive '15'
set interfaces wireguard wg0 peer mullvad-us60 port '51820'
set interfaces wireguard wg0 peer mullvad-us60 pubkey xxxx'
set interfaces wireguard wg0 private-key 'wg0'

For the latter, something like this

set interfaces wireguard wg7 address '192.168.32.1/24'
set interfaces wireguard wg7 description 'vpn +lan +mullvad-us'
set interfaces wireguard wg7 mtu '1420'
set interfaces wireguard wg7 peer inuc allowed-ips '192.168.32.102/32'
set interfaces wireguard wg7 peer inuc pubkey xxxx
set interfaces wireguard wg7 peer iphone allowed-ips '192.168.32.103/32'
set interfaces wireguard wg7 peer iphone pubkey xxxx
set interfaces wireguard wg7 peer laptop allowed-ips '192.168.32.101/32'
set interfaces wireguard wg7 peer laptop pubkey xxxx
set interfaces wireguard wg7 peer pixel3a allowed-ips '192.168.32.100/32'
set interfaces wireguard wg7 peer pixel3a pubkey xxxx
set interfaces wireguard wg7 policy route 'vpn-routing'
set interfaces wireguard wg7 port '51820'
set interfaces wireguard wg7 private-key 'wg7'

[AWHarvard]

Hi,

1. Switched to your suggestion and stored the key in the /config/auth/wireguard/wg0 folder.

2. I’m trying to make an outbound connection.
   As i know it from the EdgeOS/wireguard-vyatta-ubnt implementation and also described in the vyos wiki i need to use the endpoint statement because of making a connection to a fqdn not a ip address.
   I know about the note

The endpoint must be an IP and not a fully qualified domain name (FQDN). Using a FQDN will result in unexpected behavior.

but this is at the moment the only way of getting it work because of dynamic IPs in germany. BTW. I’ve ran this setup for about 1 1/2 years on EdgeOS and never faced the mentioned ‘unexpected behavior’.

Example from the vyos wiki for current and rolling releases:

local side
set interfaces wireguard wg01 address ‘10.1.0.1/24’
set interfaces wireguard wg01 description ‘VPN-to-wg02’
set interfaces wireguard wg01 peer to-wg02 allowed-ips ‘10.2.0.0/24’
set interfaces wireguard wg01 peer to-wg02 endpoint ‘192.168.0.142:12345’
set interfaces wireguard wg01 peer to-wg02 pubkey ‘XMrlPykaxhdAAiSjhtPlvi30NVkvLQliQuKP7AI7CyI=’
set interfaces wireguard wg01 port ‘12345’
set protocols static interface-route 10.2.0.0/24 next-hop-interface wg01

This statement seems to miss in the current branches of vyos and been relaced by peer address xx.xxx.xxx.xx
If we’re right and ‘endpoint’ is no longer available than somebody should update the official vyos wiki’s

[phillipmcmahon]

It’s a wiki, feel free to update

Hope the advice was a help.

The implementation on Vyos is different to that of EdgeOS you can’t expect the same config to port over. Having used both for some time, my mileage on Vyos is much better overall. Ubiquiti seemed to “soft drop” their EdgeMax range 18 months ago. Wireguard only exists because of a third party package on their platform.

[AWHarvard]

I’ll do

Seems wireguard changed the strategy, their documentation now also only talks about an IP instead of a FQDNs.
Jason Donenfeld for wireguard itself wrote some time ago about this: “The endpoint can contain a domain, yes.”

Maybe vyos should change their implementation of wireguard by allowing sth. like reresolve-dns which is implemented in wireguard-tools.
They seem to make use of the removed endpoint option to update the peers address to the latest IP.
I think this would help out more people like me dealing with dynamic IPs.

[phillipmcmahon]

Make a feature request via the vyos phabricator site. you might want to check out the wireguard mailing lists. I would say that the handling of dynamic IPs is not something solved with wireguard today and most recommendations seem to point people in doing something specific to their setup. I think that will have to change if wg really wants to cover the most common VPN use cases out there.

You’re welcome btw…

[hagbard]

FQDN comes with a few issues:

1. If the name can’t be resolved during the tunnel creation, the tunnel can’t be created and will fail.
2. If the FQDN is set up in /ect/hosts, that’s gonna be the IP the tunnel will be connected during the tunnel creation
3. If you DNS flaps, or A, AAAA records are modified after the tunnel creation, the tunnel will stick to the old A record resolved during the tunnel creation. (unless you do the dynamic recreation)
4. dynamic re-creation, if you have DNS issues resolving A, AAAA records your tunnel will fail, flap or needs to resync (packet loss).

There are more negative issues than benefits for a FQDN implementation don’t you think?
I think it’s not a good idea to use FQDN, it has been the choice of the user in the past which I think shouldn’t be a big issue to allow again, but again a tunnel (regardless what tunnel type) in general shouldn’t rely on any external service such as DNS.

[phillipmcmahon]

Yep, all those things are issues. I don’t use FDQN.

[Viacheslav]

[quote=“AWHarvard, post:1, topic:6411”]
as described in the wiki[/quote]

Don’t use the wiki.
Use current official documentation https://docs.vyos.io/en/latest/configuration/interfaces/wireguard.html

[AWHarvard]

Totally agree that using fqdn’s can cause this kind of issues also because of wireguards design as it is now.

Personally i’ve used wireguard since begin 2020 with fqdn’s because of our ISPs dynamic IPs and never had any issues with it.

An option to allow fqdn’s and update the tunnels address (as done with wireguard-tools by cron) like described in my feature request would be awesome for users where the ISP didn’t offer statis IPs and need to stick with the DNS option.

[phillipmcmahon]

@AWHarvard I had totally forgotten that is the clear warning when using the wiki. For obvious reasons the old documentation isn’t up to date.

The link in the warning (and shared by @Viacheslav) is the right place to find all the latest documentation.

[hagbard]

You should create the feature request together with an explanation in https://phabricator.vyos.net/.
I think just allowing FQDN and IPs, as it was before should help you out on the short run, but doesn’t fix the issue with you described above with your ISP. I’m personally not a big fan for the cronjob idea, but will have a look into it since you will have to re-init the tunnel every time your IP changes anyway. That need some investigation.

[pirateghost]

@phillipmcmahon

I believe you can only have wg instances names wg0-wg9

nope. I have 13 peers set up in this fashion.

[phillipmcmahon]

Fair enough and appreciate the update.

The issue was incorrect syntax. Seems the OP is sorted now.