8

I've read the WireGuard specification, and it looks like WireGuard doesn't natively support any kind of user authentication (e.g. LDAP or something like that). Any client which has the server's public key, and whose IP address is whitelisted in the server configuration, can connect.

Does anyone know about any WireGuard extension or implementation which provides user authentication?

Matthias Braun
  • 205
  • 1
  • 8
Aleksandar Pesic
  • 251
  • 2
  • 4
  • 9
  • Just to clarify, both peers must whitelist each others public keys. In other words, the "server" must whitelist the "client's" public key for WG to work. – Jim Walker Jun 03 '21 at 12:49
  • There is no "user authentication" in WireGuard. Because there is no such concept as "users". Because **WireGuard is not a VPN**. It's a *tunnel*, which could be used to build a VPN. This is also why comparison of WireGuard with, say, OpenVPN is incorrect. It's like comparing the wheel and the bicycle. Answers below are basically ways to build something like VPN upon WireGuard as a core tunnel. And it is quite obvious those aren't "extensions" or "implementations" of WireGuard, but complex machines which include it as a part. – Nikita Kipriyanov Aug 31 '21 at 16:49
  • @NikitaKipriyanov: Your definition of VPN seems to differ from the one WireGuard has. On [wireguard.com](https://www.wireguard.com/) it says: "WireGuard® is an extremely simple yet fast and modern VPN" – Matthias Braun Sep 02 '21 at 17:57
  • If I read up on 2FA/user passwords, I get the impression that the current solutions outsource this to other application, which is reachable as soon as the VPN is established. An attempt was done in [Wireguard 2fa u2f](https://github.com/qzio/w2fau2f). I assume [Tailscale](https://tailscale.com/kb/1086/tailscale-vs-wireguard) or [LogonBox VPN](https://www.logonbox.com/content/logonbox-vpn) do something similar. – Stefan Nov 05 '21 at 10:45
  • This approach seems feasible with [OpenWrt](https://forum.openwrt.org/t/solved-wireguard-vpn-server-and-2fa/106972), same for [OPNsens](https://obengafrane-oa.medium.com/wireguard-peer-authentication-a-captive-portal-approach-c464e4be8675). Not sure yet if [r/WireGuard](https://www.reddit.com/r/WireGuard/comments/mq0k3l/2fa_and_password_for_wireguard) helps here. – Stefan Nov 05 '21 at 10:50

3 Answers3

4

Each side of the tunnel has its own generated key and derived public key (defined as "peer" on the other side of the connection). To act as you are writing, you would need to share the private key between the "clients", which is the worst you can do (technically you can, but I hope nobody would even think about that).

Let's think about "client vs. server" roles:

server

  • owns secret key
  • has list of all possible peers / users
  • each client is represented by own peer definition on the server side with the relevant public key of the client

client

  • owns secret key
  • one peer definition with the public key of the server

We can say that the client is authenticated using one factor authentication and the authentication is realized using the public key of the client.

  • Granting access to a new client means to add a peer definition to the server side (can be realized without restarting VPN / without breaking all current VPN sessions).
  • Revoking access for the current client means removing the peer definition on the server side (again, it can be done also without restarting VPN - closing all current sessions).

If I correctly understood your question this "feature" is present in WireGuard out of the box without any needs of extensions.

Matthias Braun
  • 205
  • 1
  • 8
Kamil J
  • 1,587
  • 1
  • 4
  • 10
  • 2
    Where does the OP suggest sharing private keys between the "clients"? MFA/centralized "user" authentication is a legitimate requirement that WG does not presently support. Trusting a single key stored locally on the peer is risky from a business' standpoint, since a compromise of the peer device would mean unauthorized access into the business network. Requiring additional authentication (LDAP/+MFA) where the user must enter something they know, helps mitigate that risk somewhat. – Jim Walker Jun 03 '21 at 12:43
  • Even it is in general legitimate requirement (security point of view) I am not sure if it is not a little bit over the scope of the project... With covering "compromising the system" you cannot utilize BYOD and other "trendy" approach. At some point you need to trust (and check) the user. Simply secure the system and encrypt the storage to prevent e.g. boot "custom" OS on it with access to the key. In this case don't think about it as solution but the powerful tool. This way there is several options but the comment length is limiting. The hammer is not bad because it "just" handle the nails. – Kamil J Jun 04 '21 at 07:43
  • Anyway as has been mentioned in the comment the adding and removing the peer definition can be handled dynamically without "killing the instances of tunnels". This is the way how it can be utilized in case you need MFA). As the traffic is mainly individually encrypted (IMAPs, SMTPs, HTTPs,...) there can be also utilized hotspot approach or PPP "layer".... Wireguard can be used as is if it is suitable or it can be incorporated to the other solution as protocol and not a directly the tool interacting with the user - that is already happening... In case of need of complexity IPsec is still here. – Kamil J Jun 04 '21 at 07:50
3

As @Kamil says, WireGuard's concept is a bit different than other VPN solutions. I also started using it not a long time ago, and if you want to implement something that uses existing authentication, you can get it the way that I've seen in some projects:

  • Authenticate your users with your preferred method, plus 2FA, whatever you want.
  • After the user is authenticated, the client generates a temporary key pair.
  • Through a secure connection, client sends the public key to the server, fetches their config (endpoint, server public key, etc...)
  • The client connects to the VPN
  • When the user logs out or the session expires, the server can remove the peer from the WireGuard endpoint.

All of this of course can be automated on the client and server side.

Matthias Braun
  • 205
  • 1
  • 8
Securez
  • 51
  • 5
  • 1
    Sorry, never, please never do that. Do not advice sending of the private keys trough a "secure" channel. Both parties should not know each others private keys. This is not the case when the client's key is generated on server. There should be another implementation that "unlocks" (decrypts) the client private key when needed. At the moment the private key is easily transferable and can be used directly in another (abuser's) client. Something more. Because of the "roaming feature" of WireGuard it is impossible for the server to distinguish between these two clients. – Nikolay Naydenov Jul 22 '20 at 18:44
  • I understand the OP's concern. The export function in the Windows client exports the tunnel with the client's private key. There is nothing preventing someone from importing this file to another computer and connecting as that client. I've done this. There needs to be a method of authentication. – whizzard Jul 25 '20 at 22:39
  • 2
    I agree with Nikolay. Don't ever send private keys. That being said, a client could generate a key, send their public key, let the server add that to its peers section, receive a template of their config from the server, and populate that template with the matching private key. Of course the server would be designed to only carry out this process for an authenticated user. – Kevin Tindall Jan 01 '21 at 14:37
  • I agree that is not good practice, to send private keys, I edited the steps, also it's not a definitive solution, olny a example that WG can be combined with other authentication systems to integrate VPN connections – Securez Jan 04 '21 at 15:49
3

To expand upon @Securez's suggestion, what about combining something like SSH with Wireguard? The idea here would be that SSH provides the desired "authentication" service, while Wireguard provides the secure tunnel once a peer successfully authenticates.

For example (on a linux box),

  • configure SSH to enable multiple authentication methods, e.g.

    AuthenticationMethods "publickey,keyboard-interactive"

  • next, implement a combination of public key + password + TOTP authentication for SSH using something like oathtool (this could also include LDAP based authentication or any combination of the several authentication methods supported by SSH, but for sure include key based authentication)

  • then configure /etc/ssh/sshrc to call a script that, based on the user logging into SSH, adds a peer to Wireguard (optionally also opens the WG port for the user's IP address on a firewall e.g. iptables)

User then connects as follows (can be automated using a simple script):

  1. SSH to the remote peer
  2. upon successful authentication, activate the Wireguard connection

A cron job can be scheduled to check the time elapsed since the latest handshake for each active peer, and if the time is greater than a specified interval, e.g. 180 seconds (meaning peer is no longer connected), kick the peer (and if applicable, close the firewall port).

If you don't need the connecting user to be able to SSH into the remote peer, you can set the user shell to /sbin/nologin. Also, in order for the script called in /etc/ssh/sshrc to be able to add a peer to Wireguard, the script will need sudo access. That risk can be limited with something like the following in /etc/sudoers:

%wireguard-users ALL=NOPASSWD: /path/to/add-wg-peer

where wireguard-users is a group that you would add all the Wireguard users to. Ideally, the add-wg-peer script should not accept any parameters, to limit misuse.

Benefits of such a setup:

  • Use of well tested, established, off the shelf components
  • A combination of public key + password + TOTP satisfies the requirements of a. something you know, and b. something you have which can mitigate the risk of a compromised peer gaining unauthorized access
  • If the firewall functionality is implemented, the attack surface is further reduced by limiting Wireguard access to authorized IP addresses (and also potentially address the "Roaming Mischief" issue identified as a Known Limitation in Wireguard)

Down side:

  • You just exposed SSH to the public Internet :o
  • Everything else not covered here

Thoughts, observations, criticisms? I'm really interested in hearing what potential pitfalls a setup like this could result in.

Jim Walker
  • 321
  • 1
  • 3
  • 10