Skip to main content

WireGuard® tunnels

WireGuard® is an extremely simple yet fast and modern VPN that utilizes state-of-the-art cryptography. It aims to be faster, simpler, leaner, and more useful than IPsec while avoiding the massive headache.

Why we have chosen WireGuard®?

We had quite a few very important reasons:

  • Cross-platform (Windows, macOS, BSD, iOS, Android) and widely deployable
  • It's widely used in existing use cases - our partners and clients
  • It intends to be considerably more performant than OpenVPN
  • WireGuard® is designed as a general-purpose VPN for running on embedded interfaces and supercomputers alike, fit for many different circumstances.

What makes WireGuard® different?

WireGuard® is a secure network tunnel, operating at layer 3 (the network layer), implemented as a kernel virtual network interface for Linux, which aims to replace both IPsec as well as SSL-based VPN protocols like OpenVPN.

The WireGuard® protocol provides a secure OSI Layer 3 network tunnel between two endpoints. It uses a cryptographic handshake protocol based on the Noise Protocol Framework to provide mutual authentication, key agreement, and forward secrecy. There is no single client or server role in the protocol.

WireGuard® avoids storing any state (data that relates to sessions or network information) prior to authentication and does not send any responses to unauthenticated packets. With no state stored for unauthenticated packets, and with no response generated, WireGuard® is invisible to illegitimate peers and network scanners. Several classes of attacks are avoided by not allowing unauthenticated packets to influence any state.

A generic sequence of events in the protocol is as follows:

  1. The endpoint that starts the handshake is referred to as an initiator while the peer that it tries to communicate with is called the responder.
  2. During the course of the handshake, pairs of public cryptographic schemes called “ephemeral Curve25519 key pairs” are generated, which are to be used to encrypt/decrypt sent and received data.
  3. After completing the handshake, both peers can send data. The data is encrypted at one end and decrypted at the other end using the aforementioned key-pairs.
  4. After the initiator receives the data from the responder, if it has no data packets immediately queued up to send, it sends an empty packet to confirm the end of data packets being sent.
  5. All aforementioned private keys and symmetric session keys are erased after a certain time. Endpoints that approach the session expiration time or message limit must create new keys if they wish to continue communication and this can be accomplished by starting a new handshake.

There is periodic key rotation which ensures limited impact in the event of key compromise. Peers may change roles over time. For example, after some inactivity from both sides, a responder might become an initiator of a new session and its peer will subsequently assume the role of a responder. A single UDP source port is used for both the handshake protocol and while sending data, which simplifies Network Address Translation traversal.
Peers are able to send encrypted WireGuard® packets to each other at particular Internet endpoints. To ensure that IP traffic is routed to exactly one of those endpoints, WireGuard® uses “Cryptokey routing”.
In Cryptokey routing, an endpoint is associated with a set of allowed IP addresses, possibly covering all IPv4 or IPv6 addresses. Data sent to the WireGuard® network interface will be sent to an endpoint only if the destination IP address is part of the set of allowed IP addresses. Inbound data is only accepted if the source IP address of the decrypted packet is within the set of allowed IP addresses from the authenticated peer.

Encryption in WireGuard®

WireGuard’s cryptographic suite is derived from the Noise cryptographic framework. We have already mentioned the pair of cryptographic key-pairs called ephemeral Curve25519 key pairs, which help encrypt and decrypt data. WireGuard® supports a mode in which any pair of peers might additionally pre-share a single 256-bit symmetric encryption key between themselves in order to add an additional layer of symmetric encryption.

WireGuard® uses the following constructions and algorithms in its encryption/decryption capabilities:

  • Noise protocol framework: A collection of cryptographic handshake patterns which provide building blocks to construct new secure protocols with authenticated key agreement.
  • ChaCha20-Poly1305: The ChaCha20 stream cipher and Poly1305 authenticator, used in an Authenticated Encryption with Additional Data (AEAD) construction. It provides authenticity and confidentiality of transported data.
  • X25519: An elliptic-curve-Diffie-Hellman (ECDH) function. It is used in the key agreement protocol.
  • HKDF: The HMAC-based Key Derivation Function (HKDF) is a construction to derive one or more keys from an initial secret. It is used to link all pieces of the handshake state to each other, including keys and protocol messages. It also ensures that the original key material that is involved in calculations cannot be recovered.
  • BLAKE2: A fast cryptographic hash function used by the HKDF and as a message authentication code (MAC).
    The cryptographic capabilities in WireGuard® have the following features:
  • Avoids key-compromise impersonation: A key-compromise impersonation is a phenomenon in which an attacker installs a client certificate on your device, and then impersonates websites. The WireGuard® protocol is secure against such attacks because if the key is compromised, the key cannot be used to impersonate any other party.
  • Avoids replay attacks: A replay attack is an attack in which an attacker sniffs messages being sent on a channel to intercept them and resend them under the cloak of authentic messages. To protect against replay attacks, the responder may not send encrypted data messages until it has received an encrypted data message from the initiator that acknowledges receipt of the response handshake message.
  • Perfect forward secrecy: Temporary and static key pairs are used in a series of Diffie-Hellman computations to ensure forward secrecy.
  • Achieves “AKE security”: Authenticated Key Exchange (AKE) is the exchange of session keys in a key exchange protocol which also authenticates the identities of parties involved in key exchange. Authenticated Key Exchange is achieved through the “IK” pattern from Noise.
  • Identity hiding: Provides hiding of static public keys used in encryption.

Cross Platform Support in WireGuard®

The software implementation of WireGuard® was originally developed for Linux, but has support for other platforms, provided by a Go language implementation of WireGuard® including Microsoft Windows and macOS (and even Android and iOS).

‘wg’ is the configuration utility for getting and setting the configuration of WireGuard tunnel interfaces. Interfaces themselves can be added and removed and their IP addresses and routing tables can be. The ’wg‘ utility provides a series of sub-commands for changing WireGuard®-specific aspects of WireGuard® interfaces. This utility is common to all cross-platform implementations of WireGuard®

  • Linux: A separate implementation can be run in an existing Linux installation. There also exists a kernel module for WireGuard® which is faster and has better integrated features right into the OS.
  • Windows: There is a fully-featured WireGuard® client for Windows. It is the only official and recommended way of using WireGuard® on Windows. WireGuard® for Windows has been designed from the ground-up to make full use of standard Windows services, Access Control List and command line interface capabilities, making WireGuard deployable in enterprise scenarios or as part of Active Directory domains.
  • macOS: The Go language implementation for macOS uses the ‘utun’ driver. The implementation is an application for iOS and for macOS, as well as many components shared between the two of them.
    Also, WireGuard® supports containers: a standard unit of software that packages code and all its dependencies so the application runs quickly and reliably from one computing environment to another. One famous example of containers is Docker . It is possible to create a WireGuard® interface in a main network namespace which has access to the Internet, and then have it moved into a network namespace belonging to, say, a Docker container, as that container’s only interface.

Benefits and Limitations of WireGuard®

WireGuard® provides the following benefits:

  1. A test performed on WireGuard® shows that it performs better than other VPN protocols on multi-core machines, and can take full advantage of multithreading.
  2. WireGuard® has a lean and light code-base by design, implemented in just over 4000 lines of code, which will ease auditing and vulnerability finding. It also helps to make the attack surface smaller in comparison to the 60,000 lines of the OpenVPN implementation.
  3. WireGuard® focuses on simplicity and usability.
    4 WireGuard® can deliver a scalable system.
  4. WireGuard® can be deployed on the outer edges of networks, as a trustworthy and reliable access point, which does not readily reveal itself to attackers nor provide a viable attack target.
  5. The cryptokey routing table paradigm in WireGuard® is easy to learn and will promote safe network designs.
  6. WireGuard® was designed from a practical perspective, meant to solve real-world secure networking problems.

Despite these advantages, there are also drawbacks. Due to the lack of authenticity for the IP address, there is scope for an attack. WireGuard® performs no validation of the source IP address during connection migration. This weakness makes WireGuard® VPN providers complicit in denial-of-service attacks against other hosts. Thus IP address authentication has to be performed externally.

Also, if each peer starts an initiation at the same time and subsequently receives a handshake initiation from the other party, it would overwrite its own original handshake state with a new state based on the received message and reply with a handshake response message. However, since each peer has overwritten its original handshake initiation, it would no longer be able to complete the handshake. Effectively, the peers are unable to communicate with each other until a new handshake is attempted. An attacker could potentially use this detail to prevent sessions from being established.


All platforms and guides can be found on the official WireGuard® installation website.


[7, 8.1, 10, 11, 2008R2, 2012R2, 2016, 2019, 2022 – v0.5.3]

Download Windows Installer
Browse MSIs


[ app store – v1.0.15]
Download from App Store

macOS Homebrew and MacPorts

Basic CLI [homebrew userspace go – v0.0.20220316 & homebrew tools – v1.0.20210914] & [macports userspace go – v0.0.20220316 & macports tools – v1.0.20210914]

brew install wireguard-tools


port install wireguard-tools


[ module – v1.0.20210606 – out of date & tools – v1.0.20210914]

$ sudo apt install wireguard


[ play store – vunknown – out of date & f-droid – v1.0.20220516]
Download from Play Store
Download from F-Droid


[ app store – v1.0.15]
Download from App Store


[ module – v1.0.20210606 – out of date & tools – v1.0.20210914]

 apt install wireguard