Adding 2FA to WireGuard

Nico Schottelius nico.schottelius at
Fri Sep 13 14:49:28 CEST 2019

Hey Rémi,

that is very welcome news. We might actually also be interested in
this. Are you by any change using pyotp for your server?

We have written ungleich-otp [0] that extends the otp approach with
realms similar to kerberos.

In regard to faking the address: given that there are no other routes /
servers in your network that can send traffic *from* that particular IP
range, your assumption should hold.




Rémi Lapeyre <remi.lapeyre at> writes:

> Hi everybody! We are using WireeGuard on Mac and Linux which works great
> but for
> compliance purpose, we would like to be able to add an OTP challenge on
> connection.
> I've been looking at the archive of the mailing list and at the various
> projects
> built around WireGuard and started writing an implementation based on the
> idea
> from
>> Alternatively, you could do OTP in-band, in order to authorize that
>> public key for a certain window of time before inactivity. In this
>> scheme, you'd disallow access to the network segment based on firewall
>> rules until a certain in-band challenge is made -- perhaps by
>> contacting a certain sandboxed server and answering an OTP challenge
>> there
> My current implementation (I plan to publish it under MIT license once it's
> ready) has a Python server on the WireGuard server bound to the wg interface
> that add an IPTable rule to allow the traffic for a given amount of time
> when
> a TOTP is received over TCP. Here are some details
>   - The TOTP is bound to the internal tunnel IP address so the IP address
> that
>   opens the TCP connection is used to identify the user, as thee packet
> must
>   have been decrypted, it seems to me that there is no way to spoof this.
>   - A small text protocol let the user log-in, log-out and read the status
> of the
>   connection.
> The client needs to send the TOTP just after connecting to the server, for
> which
> I had hoped to use the "PostUp" field of wg-quick.
> {Post,Pre}-{Up,Down} seems to be only available on wg-quick for now but we
> are
> using the wireguard-apple client so I have a few questions:
>   1. Is the absence of support {Post,Pre}-{Up,Down} in wireguard-apple on
>   purpose or would a patch to add this welcomed?
>   2. Is this way to do the OTP authentication sound?
>   3. I've seen that TunSafe has added an extension to the WireGuard
> protocol so
>   the TOTP auth would not be shared by an attacker that succeded to connect
> when
>   the user is already connected. This seems like a good idea to do, what
> are your
>   thougts about this? Would you recommend against my "easier"
> implementation?
>   4. I know that TunSafe was strongly advised against when it was
> closed-source.
>   Now that it is AGPL code, is it still the case?
> One more thing, to simplify the deployment of WireGuard, I would like to
> propose
> a change in the way the MacOS client import WireGuard configurations from a
> file.
> Our current flow is "Please open the WireGuard app, click on create Tunnel,
> give
> it a name, paste this configuration underneath what's already written, hit
> save
> and send us your public key". It gives a lot of oportunity to the user to
> mistype something and make changing the configuration cumbersome ("Edit the
> tunnel, don't touch the `[Interface]` part but replace what's underneath by
> this") so I would like to be able to send to the user a configuration file
> with
> the PrivateKey missing and have the WireGuard client generate one on the
> fly but
> this currently gives an error "Interface’s private key is required". Would
> sending a patch for this be welcomed too?
> Thanks for taking the time to help me, I look forward to contribute to
> WireGuard :)
> Rémi
> _______________________________________________
> WireGuard mailing list
> WireGuard at

Your Swiss, Open Source and IPv6 Virtual Machine. Now on

More information about the WireGuard mailing list