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.

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.

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

@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.

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

@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

@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?

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

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).

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.

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.

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

I didn't know you are online...

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)

gotcha, now I see the fnords.

@mrjones Thanks, it looks very good. I'm about to add a few status commands, like sh wireguard wbN status and peer status and the such, so please leave this task still open. I stopped after 2 lines of writing wiki, the annoying google captchas wasted my time, so I stopped :).

I'm not sure if I did understand the issue correctly, however I don't think it's a good idea. Tag nodes can be nested and you need to figure out if a change happened anyway, so the script runs only once anyway.
Since you mention wireguard, let take me that as an example.

Tested it today again with 1.2.0-rolling+201808181101, no issues anymore.

Found a possible bug when you remove keppalive, the wg device show still as configured with keepalive, I have to check if that is actually true and if so I need to ping upstream and let them know.

T783 and making endpoint optional is currently reviewed by the maintainers.

@vast-ast
Already fixed in my branch, since it's a minor change. I have the keepalive option on my plate as well as the show command. I was just on vacation for a week and didn't have much time to contribute. How urgent do you need persistent-keepalive?

Let me know if you need any help with it or have any questions.
I'm going to change the endpoint parameter to an optional parameter.
https://www.wireguard.com/#conceptual-overview may help you as well.

https://github.com/vyos/vyos-wireguard is just copied, not forked. Anything else inside is/was unmodified. I can had 3 lines to have the module loaded at boot time, but in general I don't feel very happy with the package and it's maintenance.
How do you usually backport packages in general and track patches and the such?
Should it be re-debianized and produce the vyos-wireguard-tools etc. instead of wireguard-tools?
Who is maintaining it, like adding the patches, testing etc.?

Thx @vas-ast, it's not only when you run via NAT, it's in general if you act as the server. I'm going to fix that, that was the first implementation I was happy to have that release to the public. Your input is always valuable, so if you find more, please don't hesitate to report here.
Thanks again.

@binaryanomaly
Hi, is that still an issue? I tried to reproduce it today and used all of the August rolling images, but can't reproduce it anymore.

All right pull request opened. I'm going to enhance a few parts, like the endpoint format check, show status etc., but as mentioned above I won't have much time next week and it seemed everyone needed it quickly.
I've rebuilt the iso, rebuilt vyos-1x and used the follwing config:

@syncer he is following me anyway. I'm almost done, just need to implement the suggested changes from Daniil and Christian.