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). 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.
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:
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
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.