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.

@c-po thanks a lot, I was thinking first I have to add it to the rules and do it via configure, the control file is way easier of course. I'm off next week and try to enjoy summer before the rain comes, but try to get the first stages going.

@dmbaturin When I rebuild the iso, I'm currently using the ./configure switch you recently introduced to get the wireguard packages added. How am I supposed to to it for the pull request then? Where would I have to define the modules to load?

Thx guys, learned something new. will implement it that way.

Should I place the key-pair generation under 'system wireguard' or 'system options wireguard'?

@dmbaturin thx for the input, I have added the route setup to the wireguard.py script, because if the interface gets delete from the config, the wg device gets deleted from the OS and all its routes. The config would still have then the routes in the effective config and when you reboot it tries to setup routes on a non existing interface.
The examples on the wireguard website, do it similar, after the tunnel is up, they add the routes. I also couldn't find anything in their code which adds automatically the routes for allowed-ips.

pre-build pkgs:
https://github.com/hagbard-01/wireguard-pkgs

Hi Guys,

@Asteroza I can understand why. I never knew about it till I got the task here, digging into the documentation for a few days, I was quite impressed and thought, well let's test it first. It's an awesome way of implementing tunnels.

@syncer I think by the end of this week I should have it fully working. Didn't have much time during the weekend to do anything since I was on-call. I read their paper they published, the technology is actually pretty cool.

In case anyone wants to follow the progress: https://github.com/hagbard-01/vyos-1x/tree/wireguard

Arghh, I had the rolling build from July 30th. Sorry for the noise, all working now.
Oh and you guys are really awesome.

2312 open("/sys/module/wireguard/initstate", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
2312 stat("/sys/module/wireguard", 0x7ffeb8212c70) = -1 ENOENT (No such file or directory) <-----
2312 open("/lib/modules/4.14.26-amd64-vyos/extra/wireguard.ko", O_RDONLY|O_CLOEXEC) = 3
2312 fstat(3, {st_mode=S_IFREG|0644, st_size=342768, ...}) = 0
2312 mmap(NULL, 342768, PROT_READ, MAP_PRIVATE, 3, 0) = 0x7f0f94c3a000
2312 finit_module(3, "", 0) = -1 EINVAL (Invalid argument)
2312 write(2, "modprobe: ERROR: could not inser"..., 64) = 64

@UnicronNL module can't be loaded via modpprobe I get.

@syncer It doesn't really matter to me, I was just concerned that if you have pppoe-server running, you can't use gre tunnels (the kernel module can't be loaded anymore).

@dmbaturin No worries, I'm well aware of the new scheme. (will be a fresh and new implementation of the syntax).

@UnicronNL thx a lot for the packages, speeds my task up quite a bit.

@syncer I discovered a possible issue, accel-ppp is incompatible with the ip_gre driver, so using accel-ppp means you can't have gre tunnels anymore and vice versa. I'm not sure if accel-ppp is a good idea to integrate into vyos. Shall I continue with the packages or should we check if we can find anything compatible which doesn't interfere with router stuff. Not having gre is in my opinion a very significant issue.

It will come in 2 parts, the ppp server as a package first and then the rewrite for its config, hard to estimate the time it will need, let me first package accel-ppp.

Can please someone assign it to me, I was/am working on that one and opened a subtask since I can't assign this one here tom myself.

pending merge

pending merge

Problem happens in ln 27 in /opt/vyatta/share/vyatta-cfg/templates/interfaces/wireless/node.def, $VAR seems to be empty.

merged by Daniil. Please assign bugs to me, if any come up. I tested everything multiple times carefully, but you never know, so I take full responsibility :0.

Wouldn't it be easier by just excluding 127.0.0.0/8 and ::/1?
I haven't checked, but how is it handled with IPv6 anyway? Like the link local adresses.
I see if I can find out, why it takes a reboot for the host_name.py script to function properly, I found in my tests yesterday it is always executed. hostnamectl sets /etc/hostname to "hostname.domain", shouldn't be done that way anyway.
It seems to be the culprit, but more testing is required, I won't have much time today.

cat /etc/hosts
127.0.0.1 localhost debian <----
::1 localhost ip6-localhost ip6-loopback
fe00::0 ip6-localnet
ff00::0 ip6-mcastprefix
ff02::1 ip6-allnodes
ff02::2 ip6-allrouters

... and that is why you don't like systemd. hostnamectl is bailing out, why? No idea yet.
libnss-myhostname may fix that already, it modifies nsswitch.conf and myhostname is always being resolved regardless if its in /etc/hosts or not.
I'm still looking why it is not setting the hostname, but does when you reboot. The config is executed, I checked that.

additionally in /etc/hosts each change adds the localhost line instead of replacing it.

@syncer , @c-po
I can also check from the python script if /etc/rsyslog.d/vyatta-log.conf exists and if it does I remove it, since it's generated anyway.
That file is basically the last item (well and the user implementation) I have to work on.