The wireguard plugin allows your 128T router to peer with other endpoints using wireguard. With this plugin you can securely connect endpoints to your 128T fabric, extending services and network tenancy.
See instructions for installing and managing plugins.
Wireguard operates using cryptokey routing, which provides device-to-edge security with a 128T service centric fabric. For any wireguard peer to securely communicate with another, a Curve25519 public/private keypair is generated. Each endpoint wishing to form a peering relationship must be configured minimally with the public key of the peer, and the prefixes that are allowed to be sent to the peer.
When a 128T router is configured for wireguard, it will generate a public key which can be configured in remote endpoints that are to peer with it. Additionally service prefixes that should be sent to the 128T router by a wireguard peer, can be configured as allowed IPs. More information on wireguard configuration can be found here.
To configure your 128T router for wireguard peering, you first create a wireguard profile on the router. For example, the following defines a profile called
wg-profile-1. Each wireguard endpoint will use a unique address from the prefix
10.10.10.0/24 as defined in the profile and the router wireguard instance will use the first address of
With a profile configured, the next step is to reference the wireguard profile on a network-interface address that you want to use for wireguard peering. For example, this sets
192.168.128.1 to function as a wireguard peering endpoint:
With the profile configured and set on an interface, the router will install the required components for wireguard peering.
Services and Tenants with Wireguard
Configuration of a wireguard profile on a 128T router interface does not provide access to network services. It simply allows the endpoint to connect to the router using wireguard for secure transport, and all sessions will still be subject to the rules of tenants and services. To facilitate network tenancy being given to traffic coming from wireguard peers, a profile is configured with a neighborhood. The neighborhood in the wireguard profile will function as a named Layer 3 network, and used in defining neighborhood based tenancy to provide access to services.
If you do not have a pre-defined tenant to use for wireguard endpoints, you can optionally configure a
tenant in the profile, and one will be automatically generated for you.
Connecting Remote Endpoints
You have devices that are remote from your 128T fabric, but you want to give them network tenancy and access to services. In this example use case, assume you have two datacenter routers
dc2, hosting services for
172.16.2.0/24 respectively. You want your remote devices to connect directly to each datacenter for these services, and be given a tenant called
dc1 has a network-interface address of
dc2 has a network-interface address of
18.104.22.168 that will be used to allow wireguard peers to connect.
Each peer is assigned an address out of a
10.10.10.0/24 private network, which they can use when sending sessions on to the fabric. Also every peer will end up having a public/private wirguard keypair. For this use case example, each peers have the following info assigned to them:
|peer||private address||public key|
The following config sets up profiles on each of the
dc2 routers, and provisions each peer.
With this config committed, wireguard will be installed and set up on
dc2, and it will generate a wireguard keypair automatically. Once the interface is fully installed, you can view the public wireguard key of the profile by using the CLI command
show device-interface router <router_name> name <profile_name>. Example:
Remote Endpoint Configuration
Now the remote peer endpoints can be configured to peer with the
dc2 routers at their respective interface addresses, and route the corresponding service prefixes of
172.16.2.0/24 to each. For example, a wireguard config for peer
p1 might look like the following:
See wireguard documentation for more on configuring wireguard on other endpoints.
Network Tenant For Endpoints
In the remote endpoint example, traffic coming from endpoints will be transported to the appropriate 128T
dc2 routers using wireguard, and then be sent into the fabric sourced from each endpoint's assigned private address in the
10.10.10.0/24 network. To assign these endpoints a tenant, thus giving them access to services, the profile is configured with a
remote. Based on this, you can define tenant membership for each endpoint in the private network.
For example, the following could be used to give endpoints in the network a tenant of
p2), but give just
Remote Service Agent
You have a remote device that needs to be accessed as an agent of a service in your 128T network. In this example use case you have a remote IoT device that hosts a
thing service with address
22.214.171.124/32, which must be accessed by a tenant
A remote IoT device has a wireguard peer with a public key of
Jihom426SSceUCPpS1147NSNzZcY1wl40Sf+OQ1rjGU=. It will be given an address of
10.10.10.2 from the private network, and it will peer with the 128T router
r1 on the
126.96.36.199 network-interface address.
The following configuration sets up the wireguard profile, along with the IoT device wireguard peer:
Remote Endpoint Configuration
The wireguard configuration on the IoT device might look like the following:
PersistentKeepalive in this wireguard configuration causes the peer to keep the connection to the peer alive by sending periodic traffic. This has the effect of allowing the 128T to originate sessions to the peer at any time. See wireguard documentation for more on configuring wireguard on other endpoints.
With the profile and peer configured on the 128T router
r1, and wireguard configured on the remote IoT device, you can verify the device is keeping the connection alive by reviewing the
latest handshake output of
show device-interface router <router_name> name <profile_name>:
thing service must be routed to the remote wireguard peer.
gateway-ip in this configuration are automatically generated as part of the profile configuration on the router, and can be seen with
With this configuration, sessions sent from the
technician tenant to
188.8.131.52 will be given access as part of the
thing service, and routed with a destination NAT to the wireguard interface of
10.10.10.2 on the IoT device peer.
authority > router > wireguard-profile
A profile describing an instance of wireguard on the router.
|string||A string identifier for wireguard profile. This identifier is used as a device interface name in the host, therefore it can only use alphanumerics, underscores, or dashes, and cannot exceed 12 characters.|
|string||A description about the wireguard profile.|
|ipv4-prefix||An internal address prefix for KNI connectivity between wireguard and the data plane.|
|l4-port||The UDP port for the wireguard instance to recieve connections on.|
|milliseconds||Inactivity timeout for wireguard sessions. By default this uses 180000 ms UDP timeout value. If customized to a non-default value, a new session-type will be automatically generated.|
|string||The service-class to associate with the generated session-type for this wireguard profile. Wireguard sessions arriving at the router will be given this service-class.|
|access-policy||List of access policies for the wireguard service. Packets allowed by this access policy will additionally be subject to wireguard security validation. See service access policy.|
authority > router > wireguard-profile > private-network
A network to be associated with router the wireguard network-interface. This network handles packets after they have been decrypted from a wireguard peer connection, or prior to being encrypted and sent to a wireguard peer connection. The router wireguard instance will use the address given, and other peers can send or receive sessions using the remaining addresses in the network.
|neighborhood-id||Neighborhood to be associated with the wireguard network. Addresses assigned to peers can be made members of an appropriate existing tenant based on this neighborhood.|
|string||A tenant to be associated with addresses in the network. If configured, a tenant will be automatically generated with the addresses in the neighborhood set as members. If not configured, no tenant will be generated, and peer addresses in the network will need to be defined as members of existing tenants.|
|ip prefix||The address and prefix associated with the wireguard profile. The wireguard interface created on the router will use the address defined, and other peers can send or receive sessions using the remaining addresses in the network.|
authority > router > wireguard-profile > peer
Set of allowed wireguard peers.
|string||Name identifier for the peer.|
|string||The peer's base64 encoded 32 byte Curve25519 public wireguard key.|
|string||The peer's optional base64 encoded 32 byte Curve25519 pre-shared wireguard key.|
|seconds||Interval in seconds at which to send keepalive messages to the peer. Keepalives are optional. No configuration or a setting of '0' disables keepalives.|
|ip prefix||The prefixes that are allowed to be sent to the peer. When the peer is an endpoint, typically the allowed-ip is the /32 of the peer's wireguard interface. If the peer is a gateway device, the allowed-ip list would include any prefixes reachable as services via the peer, or prefixes from which traffic may be sourced.|
Disabled keepalives on the router does not mean keepalives cannot be generated by the remote peer. If keepalives are desired, a typical configuration is to have keepalives disabled on the router, but enabled on the remote peer.
authority > router > wireguard-profile > peer > endpoint
IP and port of the endpoint. If not set, the endpoint of the peer will establish dynamically based on the source address discovered during the wireguard handshake.
|ip address||Static IP address where the peer can be reached to connect.|
|port number||Port at which the peer can be reached to connect.|
If an endpoint is configured, wireguard on the 128T may attempt to send outbound sessions to the IP and port defined. The sessions will originate from the profile loopback-address. A tenant and service must be created to route the outbound wireguard session to the defined peer endpoint.
To view the status of a wireguard interface, and its peers, use the following PCLI command:
Interface and profile configuration logging
Logging of new configuration sent to the router can be viewed in the Linux shell using the system journal.
Peer configuration logging
Looging of peer configuration handling can be viewed in the Linux shell using the system journal.