Glossary

WireGuard

What is WireGuard

WireGuard is a modern VPN protocol designed to deliver an efficient, secure, and simple way to protect traffic crossing untrusted networks. It uses strong, up-to-date cryptography to keep data confidential and authenticated while moving it quickly, and its protocol design is deliberately lightweight, which keeps both the software and its configuration compact and easy to manage.

Compared with traditional VPN protocols, WireGuard's appeal comes down to four things: efficient encryption and authentication, a streamlined protocol design, straightforward configuration and management, and high-speed data transfer. In practice, that means a VPN that is easier to set up and reason about, performs well, and offers a better experience for administrators and users alike. Typical uses include securing the link between a branch office and headquarters over the public Internet, connecting remote sites, and protecting traffic between gateways.

How WireGuard Works

WireGuard's model is built around key pairs rather than certificates or complex negotiation. Each end of a tunnel has its own private key, which never leaves the device, and a matching public key, which is shared with the other side. A tunnel is defined by telling each device who its peer is — identified by that peer's public key — and the two devices then authenticate each other and establish encrypted communication using these keys. WireGuard runs over UDP and is built on modern cryptographic primitives, including Curve25519 for key exchange and ChaCha20-Poly1305 for encryption and authentication.

A WireGuard tunnel is presented to the system as a virtual interface with its own tunnel IP address, a listening port on which it accepts handshakes, and a configured MTU. Several settings shape how a peer relationship behaves:

  • Endpoint: the remote peer's public IP address and port. If an endpoint is configured, the device can initiate the connection. If no endpoint is configured, the device simply waits and learns the peer's address and port from the requests it receives — which makes one side of a tunnel able to operate passively.

  • Persistent keepalive: a setting that periodically sends traffic to keep the tunnel alive, which is especially useful when a device sits behind NAT and its mapping would otherwise expire.

  • Allowed IPs: the list of addresses or subnets associated with a peer. Traffic arriving from that peer is only accepted if its source falls inside this list, and traffic destined for those subnets is sent through that peer's tunnel — which ties authentication and routing together in a single setting.

Getting traffic into the tunnel also requires routing. A static route pointing the remote subnet at the tunnel interface (through the peer's tunnel address) tells the device to send that traffic through WireGuard, where it is encrypted and forwarded to the peer.

WireGuard also fits scenarios where one side lacks a fixed address. For example, when a branch gateway obtains its address as a PPPoE client and sits behind NAT, the headquarters gateway cannot know in advance where to reach it. In that case the branch initiates the handshake to the headquarters' known endpoint, and the headquarters simply responds — with NAT translation configured so the tunnel's traffic is translated appropriately on the way out.

Why WireGuard is Beneficial

  • Simple to configure and maintain: A tunnel is defined by a handful of parameters — a key pair, a listening port, a tunnel address, and each peer's public key and allowed subnets — rather than a long list of negotiated proposals and policies.

  • Fast: A lightweight protocol and efficient cryptography deliver high-speed data transfer, which matters for site-to-site links carrying significant traffic.

  • Strong security with modern cryptography: Authentication and encryption are built into the protocol's design, and trust is anchored in public keys that administrators explicitly configure.

  • Handles dynamic and NAT'd endpoints gracefully: Passive peers, endpoint learning, and persistent keepalive make it practical to connect sites where one side has a changing or non-routable address.

  • Routing and access control in one place: Allowed IPs both restrict what a peer may send and steer what gets sent to it, keeping the tunnel's behavior easy to understand.

  • Reliable user experience: The small, focused design reduces the number of moving parts that can fail or be misconfigured, compared with heavier VPN stacks.

At Asteraix

What We Can Do at Asteraix

AsterNOS provides WireGuard as a CLI-configurable VPN feature, with documented configurations for both a standard site-to-site tunnel and a PPPoE and NAT scenario.

  • Quick tunnel creation and key generation: wireguard <name> creates a tunnel and enters its configuration view, and genkey generates the key pair directly on the device, so no external tooling is needed to get started.

  • IPv4 and IPv6 tunnel parameters: ip4 listen_port <port> private_key <key> intf_addr <A.B.C.D/M> sets the listening port, local private key, and tunnel address, and ip6 provides the equivalent for IPv6 (intf_addr <A::B/M>). An optional mtu <value> configures the tunnel MTU.

  • Flexible peer definitions: peer {ip4|ip6} public_key <key> defines a peer, with optional endpoint_ip, endpoint_port, and persistent_keepalive settings. When no endpoint is configured, the device passively receives requests and learns the peer's address and port — as in the documented example where the headquarters gateway waits and the branch gateway initiates.

  • Allowed IPs per peer: peer public_key <key> allowed_ip <subnets> defines which addresses are associated with the peer, including multiple comma-separated subnets.

  • Routing traffic into the tunnel: ip route <prefix> <next-hop> wg <id> sends traffic for a remote subnet through the WireGuard interface.

  • NAT traversal support: nat-zone <id> (IDs 1–3) enables NAT translation for the tunnel. The documentation notes that when this is combined with port NAT to translate both inner and outer IP layers, static NAT or ACLs must be configured on the port.

  • A documented PPPoE-client scenario: AsterNOS's guide includes a complete branch-to-headquarters example in which the branch gateway obtains its address as a PPPoE client (pppoe-client, interface dialer), uses NAT, and brings up a WireGuard tunnel to the headquarters gateway — a ready reference for sites behind dynamic or translated addresses.

  • Verification commands: show wireguard status <id> displays tunnel status, and show wireguard config <id> displays its configuration.