@Watcher7 fixed via: https://github.com/vyos/vyatta-cfg-system/pull/75/files, should be in the next rolling iso.

@Watcher7 /opt/vyatta/etc/netdevice.... found it, I try

I'm gonna have a look asap, currently a little stuck with private live and preshared keys.

I believe /usr/share/vyos/interface-types.json needs to be patched to handle wireguard interfaces so that they show up in show interfaces. Scratch that, it's there, but they don't seem to appear in show interfaces.

This produces

As stated on IRC I'm fine with the support removal as one can always upgrade through VyOS 1.1.x.

preshared-key implementation progress: https://github.com/hagbard-01/vyos-1x/tree/T793

pre-sharedkey is the last item to implement, before I can close this task. everything else has been implemented via https://github.com/vyos/vyos-1x/pull/46.

done via: https://github.com/vyos/vyos-1x/pull/46

@c-po yes, Sir not a problem at all, takes less than 30 secs. to implement. Once I know how to proceed with the sonarcloud issues...

Is there still time for a small CLI change?

mtu implementation has been added for review, currently there seem to be a few issues with integration, so if you need it you can rebuilt the package via dpkg-buildbackage -tc -us -uc and download the sources from here: https://github.com/hagbard-01/vyos-1x

Hey @zx2c4 !
Available out of the box in Rolling and in future LTS releases

Please let me know what I need to add to wireguard.com/install/ in relation to VyOS's support.

ICMP Type 3, Code 4 messages are generated by the kernel, pmtud is not a wg feature, but I hear you. I see that often that ICMP is filtered away in general and that can create you a lot of grief. It's been always on my list since I started the implementation.

Fantastic, thank you for your hard work.
It seems wireguard will handle MTU changes beyond the default 1420 on its interfaces cleanly. Can I suggest that the MTU be made modifiable under set interfaces wireguard wg0 mtu <size>? This would be nice for situations where fragmentation between wireguard peer connections is acceptable.

https://github.com/vyos/vyos-1x/pull/44
I cancelled #43 due to the sonar issues.

https://github.com/vyos/vyos-1x/pull/44

Staged for review:
https://github.com/vyos/vyos-1x/pull/43

In T427#18231, @runar wrote:

All nodes are equally alike, the only difference is that one of the parties needs to have a known UDP port number for other peers to connect to.

I think the best is to use the default from the protocoll.. (autogenerate port if none is specified) 51820 could be a completion help option on the listen-port command

maybe if the listen-port is not specified, it uses the default 51820
the option to chose client/server might be confusing, because it is both

@c-po, As far as i can see it does not distinguish between server and client mode.
From the manual:

If there is an official unofficial port, ad wg distinguishes if its running in server or client mode, why not use something like:

interface: wg01
public key: QIgKRXNMGm5IM3EwdK3W7oWYrBRh7eDwqi/pGe+sWF4=
private key: (hidden)
listening port: 44971

51820 is the official unofficial port

@runar I didn't find anything the documentation which mentions a default port. I've made it optional, wg is generating if not set, but I didn't find anything in their code yet, it appears to start at 51820.
Proto is always udp.
If the listen port is not defined, you basically run as client, if it is defined you run as server. The client connects to <endpoint> which is basically IP:port from the server, if the authentication fits, it uses the src port of that client package send sends the answer to taht src ip and src port. I think it have seen it in netlink.c in their src tree. Should be all good now. I'm also almost done with the syntax rewrite, still doing testing, but I expect it to have it ready for release maybe tomorrow.

@hagbard i actually haven't tried it in real life, only looked at the command syntax'es.

You bet. If you want to follow: https://github.com/hagbard-01/vyos-1x/tree/T791

@hagbard
Thats much better! :D
"peer" in "peer-pubkey" is also a bit redundant, just call it "pubkey"

@runar, it's gonna look like the below:

@c-po, @syncer I do appreciate your feedback too of course :).

@runar Thanks a lot for your feedback, yes I was heading into that direction already before I release anything but followed as a guide the implementation here: https://github.com/Lochnair/vyatta-wireguard.

Here it is:
https://github.com/vyos/vyos-accel-ppp

I agree with syncer and runar.

I have the same feelings on that

I think that using the key as a peer identifier makes the configuration unreadable its quite hard to identify each peer when you have more than one of them. I would like to se the peer identifier to be a name/description instead and that key is added as a leafNode instead...

will add you to github org
move repo there, and for it back to your account

@syncer how do you get https://github.com/hagbard-01/vyos-accel-ppp into your repo?
It builds the accel-ppp package, which I then later will need for the cli stuff.

All right, back here.

Going to leave this task open for a bit, to track bugs and updates which may come our the next couple of days.

I leave the code section in the wireguard.py script to load the kmod, which works well. However somebody should take care of the vyos-wireguard package, there is also an update available, not an urgent one though.
Once I have time I see that I can fork it from the original source (debian repo sid) and we just add what we need (recompile for our newer kernel). Can also come from the original wireguard source, using git-buildpackage.

@mrjones No prob at all, you are a great help. Thanks for your contribution.

@mrjones, @Lochnair yep, that's correct. I'm not really happy with how the packages and kmods made it to us, it's also not the latest version and i think no one is tracking it. I raised that question in https://phabricator.vyos.net/T779, but no one answered yet. So i may have to contact @dmbaturin via email directly.
Do you guys think I should implement a 'show wireguard version' or something similar?

@mrjones Seems like it's currently 0.0.20180708, based on this: https://github.com/vyos/vyos-wireguard/blob/current/debian/changelog

What version of Wireguard is it that we are using? Where can I see when it is updated?

There is a start, I will adjust it after I can test it out myself!
Things are happening fast.
regarding the syslog documentation, I will have more time to dive into it on thursday/friday. I didn't fiddle with it myself, and I will take it as a learning moment as well.

show interfaces wireguard <tab completion> [<enter>]

Yes, send a preview, and I can add it to the wiki right away

I added the persistent-keepalive.

I've added the status commands, once https://github.com/vyos/vyos-1x/pull/39 is merged you should have them in the latest iso. Let me know if you need a preview.

https://github.com/vyos/vyos-1x/pull/39

The following has been added:

Can please anyone answer my questions above? My main concern is that we build ourselves an ugly maintenance nightmare here.

You want to authenticate your host, not your interfaces. Theoretically, it's possible. If you travel, you carry usually one piece of ID with your passport, to identify yourself.
The listen port is mandatory, the peer endpoint on the server side however is optional. When the client initiates (client needs peer endpoint) the connection and passes the authentication part, the server side finds the way back on the data the client has sent (basically src IP and src port, src port is the clients listen-port by the way, that's why it's mandatory).

yes, but if I use several interfaces, wg01, wg02, wg03, then should have the option to use a different keypair for each one of them?

Is it supposed to not accept "=" ?

Thanks a lot.
The keypair is unique per host, it is used to authenticate and to decrypt the incoming traffic. So for authentication it wouldn't make much sense to deal with multiple keys.
Encryption is done via the public key, which has to come from your peer. So the traffic to a peer is always encrypted with the public key, only the one who has the private key or at least the knowledge of the content of the private key, can decrypt the message/traffic. That's at least the basic idea.
On the server side you basically receive a message encrypted with your public key, which contains the public key for authentication (see the link above and look for DH_PUBKEY(private key) in the code example). So given that, theoretically you only need to store the private key since the public key is always computed during connection initiation. But that would mean in my case, that 'show wireguard pubkey' would have to compute it as well any time you need it to send it to your peers when you create a new tunnel. (wg pubkey < your_private_key will give you the same result).
I just have a native OS api to read a file but would have to call a subprocess to call wg, that's why I store the public key in a file as well, the content is the same.

sure thing!

It does for me, I probably just need to be white listed.
Would you like to do https://phabricator.vyos.net/T759 as well?
It's syslog configuration, which I rewrote a month or so ago.

I will edit it, I missed that it was already implemented,

In case you are interested: https://www.wireguard.com/protocol

I didn't know you are online...

Not completed yet, so I will not close the task.

wg pubkey (generates a public key using the private key, for example: wg pubkey < "private key here")
For extra security you can also use a pre-shared key that can be generate with this command:
wg genpsk (this is optional, and the same pre-shared key should be used on both hosts)

set interfaces wireguard wg0 listen-port (optional)