Tip

This is the documentation for the 22.06 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 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 tunnel next hop configurations for each peer pointing the peer address(es) to the appropriate WireGuard interfaces and peer external addresses to find their adjacency. See WireGuard Tunnel Next Hop 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 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

  • Not supported on TNSR at this time

Remote Access “Client”

  • Endpoint address and port filled in locally

  • Remote side does not contain endpoint configuration

  • Can initiate traffic to the peer

Warning

TNSR is limited by the capabilities of WireGuard in the dataplane. Currently the dataplane requires static endpoint addresses and ports defined locally and for each peer. Due to this limitation, TNSR can only act in either a site-to-site or remote access client role.