Tip

This is the documentation for the 23.02 version. Looking for the documentation of the latest version? Have a look here.

Design Considerations

One of the main considerations when choosing a WireGuard implementation layout is whether to use one tunnel with many peers, or one tunnel per peer.

Routing to WireGuard Peers

WireGuard uses what it calls “Cryptokey Routing” to map traffic inside WireGuard to a specific peer which is then encrypted using the public key for that peer. In practice, this means that when multiple peers are defined on a WireGuard instance each peer instance must define the set of networks reachable through that peer. This can make managing networks and routes cumbersome when using a single instance with many peers for site-to-site connectivity.

When there is only one peer on a wireguard interface, it can instead assume that the one peer is the correct destination for all traffic which crosses the interface (e.g. Allowed Prefixes set to 0.0.0.0/0 or ::/0). And in that case, a routing protocol such as BGP or OSPF can manage the operating system routing to the neighbor instead of static routes.

Due to the way WireGuard uses peer-to-peer non-broadcast interfaces in VPP, WireGuard requires a special entry for each peer to locate neighbors on the VPN. This can be either a special /32 prefix route or a tunnel next hop configuration containing the peer address(es) to the appropriate WireGuard interfaces and peer external addresses to find their adjacency. See WireGuard Next Hops for details.

Design Style

Every WireGuard tunnel is a peer to peer connection, but there are different ways WireGuard can behave depending on whether or not a peer endpoint is known or defined on both sides:

Site-to-Site:

  • Peer endpoint IP address and port filled in on both sides

  • Both peers can initiate traffic first

Remote Access “Server”:

  • Remote peer knows the endpoint configuration

  • Local side does not contain endpoint configuration for the peer

  • Only remote peer can initiate traffic

Remote Access “Client”:

  • Endpoint address and port filled in locally

  • Remote side does not contain endpoint configuration

  • Can initiate traffic to the peer

In each case, at least one peer must have a known endpoint address and port. Peers with unknown/dynamic addresses can roam to new addresses and/or ports. WireGuard will track and update their new location using the peer’s key data on the incoming packets.