[1] https://github.com/subspacecommunity/subspace/blob/master/en...

I think it's also worth mentioning this works even better than openvpn as a client on windows and my phones!

At least for me, a major issue turned out to the abstractions (like wg-quick, ufw, network-manager, openwrt) which on one hand obscure the inner workings but at the same time are limited enough that at some point you will be forced to dig deeper. They also don't always play nicely together wrt routes, routing polices and *tables rules.

I wasted so much time (probably weeks, added together) in my younger days banging my head against the wall with Linux networking. Throwing out other high-level tools/frameworks and starting "from scratch" on CentOS/Rocky/Debian with only systemd-networkd and nftables has now made me mostly comfortable and I finally feel in control of the networking stack on my Linux boxes. I say "mostly" because, well, Docker and CNI...

Oh, and see my sibling comment.

* The semantics and behavior of AllowedIPs. In itself, it means what IPs are allowed to be routed through the tunnel (that is, IPs "on the other end"). wg-quick will, additionally, add routes to these, but that's not part of Wireguard itself.

* systemd-networkd has native support for Wireguard netdevs and networks. It's pretty easy to set up and makes it a lot more flexible; it won't add routes to AllowedIPs like wg-quick but you can define the routes (and routing policies and tables) you want in the same file. [0]

As much flak as systemd gets, systemd-networkd has by far been the most sane way for me to manage networking on Linux, and I tried most.

I'd also like to take the opportunity to recommend nftables instead of iptables. Unless you already have good reasons to prefer iptables, nftables is so much easier to learn and manage.

Oh, and ufw gets ugly real fast. Managing it through ansible or similar is a real mess. firewalld is a lot more predictable IMO. Its routing story is not perfect but it's the best I found so far and can be complemented with ip and manual nftables rules[2].

[0]: https://manpages.debian.org/buster/systemd/systemd.netdev.5....

[1]: https://wiki.archlinux.org/title/WireGuard#systemd-networkd

[2]: https://serverfault.com/a/1046246

Anyway, I was just looking how to add a WG VPN entry in kubuntu 18.04 but its version of KDE is a bit behind so CLI it is.

I'd settle for an independent KDE widget though.

https://github.com/subspacecommunity/subspace

So it is quite nice to see that it is living on as a fork.

I know it's not rocket science to watch for each one, or be more sophisticated with deep packet inspection. But, I've worked at some old stodgy companies, and I'm reasonably sure they aren't really watching for it in a lot of places.

If your network is reliant on a high firewall and nothing inside, you've already lost.

SSH is probably the best one, especially as you can usually get policy exceptions to access cloud resources.

Frustratingly there's no real "Enterprise" plan on their site, it's another one of those "get in touch" plans that I don't have the energy or time for. Guys at Tailscale, please just list an actual damn enterprise option so I can get an idea of how much it's going to cost if I push for this at work.

“It uses a single round trip key exchange, based on NoiseIK, and handles all session creation transparently to the user using a novel timer state machine mechanism. Short pre-shared static keys—Curve25519 points—are used for mutual authentication in the style of OpenSSH. The protocol provides strong perfect forward secrecy in addition to a high degree of identity hiding. Transport speed is accomplished using ChaCha20Poly1305 authenticated-encryption for encapsulation of packets in UDP. An improved take on IP-binding cookies is used for mitigating denial of service attacks, improving greatly on IKEv2 and DTLS’s cookie mechanisms to add encryption and authentication”[13]

Furthermore the email it's introduced with[2]:

`Second, WireGuard uses something based on the Noise Protocol Framework (in Noise_IK) for key agreement and handshake, rather than, say, relegating to a userspace daemon. The reason, again, is massive simplicity and security savings. The Noise_IK handshake is extremely simple, and tight integration between the handshake and the transport layer allows WireGuard itself to handle all session-state and connection-state and so-forth, making the whole process appear "stateless" to the administrator (you set it up with `wg`, and then it _just works_). There is no x509, no ASN.1, no huge complexity; the user configures the public keys, and then the rest is taken care of. Other configuration frameworks (based on x509 or SSL or LDAP or whatever you want) can then build on top of this in userspace, if that sort of thing is desired. But the basic handshake fundamentals are left to WireGuard. This is more or less similar to SSH, which cares about the authorized_keys file.`

It looks like some solutions for key management have sprouted up, check trustgrid[3] and locksmith [4]

[1] https://www.wireguard.com/papers/wireguard.pdf [2] https://lwn.net/Articles/693015/ [3] https://trustgrid.io/wireguard-for-the-enterprise/ [4] https://github.com/the-maldridge/locksmith

Although for my home lab, using X509 is more of a minus than a plus due to complexity involved.

https://github.com/juanfont/headscale

I need to read more then be brave.

Works like a charm so far, we provision them all via Ansible and use iptables to only allow access to metric endpoints via the wg0 interface.

So far, we haven't had a single issue in 6 months.

I find this one quite easy to follow, you can skip the dns part if you just want to check out if it works.

set up firewall; set up wireguard devices, keys and configs; set up dnsmasq.

I'd look up one specific to your particular distro, though. There are differences in how network devices are managed.

  --cap-add NET_ADMIN \
  --device /dev/net/tun:/dev/net/tun \

> --device /dev/net/tun:/dev/net/tun