WireGuard Tunnel

WireGuard protocol

WireGuard is a secure network tunnel operating at layer 3. It is implemented as a kernel virtual network interface for Linux and is designed to replace IPsec for most use cases as well as popular user-space and TLS‐based solutions like OpenVPN by being more secure, more performant, and easier to use. The virtual tunnel interface is based on a fundamental principle of secure tunnels: an association between a peer’s public key and its tunnel source IP address. It uses a single round-trip key exchange based on NoiseIK and manages session creation transparently using an innovative timer state machine mechanism. Short pre-shared static keys — Curve25519 points — are used for mutual authentication in a manner similar to OpenSSH. The protocol provides strong perfect forward secrecy along with a high degree of identity hiding. Transport speed is achieved using ChaCha20Poly1305 authenticated encryption for UDP packet encapsulation. An improved IP-binding cookie mechanism mitigates denial-of-service attacks by enhancing the cookie mechanisms found in IKEv2 and DTLS with additional encryption and authentication. Overall, the design ensures that no resources are allocated in response to received packets and leverages several innovative Linux techniques for handling queues and parallelism.

How does WireGuard work?

WireGuard works by adding one or more network interfaces—such as eth0 or wlan0—named wg0, wg1, wg2, etc. Routes can be installed on these interfaces, and the WireGuard-specific parameters are configured using the wg(8) tool. This interface functions as a tunnel interface.

WireGuard associates tunnel IP addresses with public keys and remote endpoints. When the interface sends a packet to a peer, it performs the following steps:

The packet is destined for 192.168.30.8. Which peer should handle it? The system determines that it is for peer ABCDEFGH (or, if no configured peer matches, the packet is dropped).
The entire IP packet is encrypted using peer ABCDEFGH’s public key.
The system identifies the remote endpoint of peer ABCDEFGH—UDP port 53133 on host 216.58.211.110.
The encrypted packet is sent over the Internet to 216.58.211.110:53133 via UDP.

When the interface receives a packet, the process is as follows:

A packet is received from UDP port 7361 on host 98.139.183.24 and is decrypted.
The decryption and authentication succeed for peer LMNOPQRS. The system records that peer LMNOPQRS’s most recent Internet endpoint is 98.139.183.24:7361 via UDP.
After decryption, the plaintext packet originates from 192.168.43.89. The system checks whether peer LMNOPQRS is permitted to send packets from this IP.
If permitted, the packet is accepted on the interface; otherwise, it is dropped.

At the heart of WireGuard is the concept of Cryptokey Routing, which associates public keys with lists of tunnel IP addresses permitted within the tunnel. Each network interface has its own private key and list of peers, and each peer has a public key. These concise public keys are used to authenticate peers and can be shared via any out‑of‑band method—similar to sending an SSH public key to a friend for shell access.

For example, a server computer might have this configuration:

[Interface]
PrivateKey = yAnz5TF+lXXJte14tji3zlMNq+hd2rYUIgJBgB3fBmk=
ListenPort = 51820

[Peer]
PublicKey = xTIBA5rboUvnH4htodjb6e697QjLERt1NAB4mZqp8Dg=
AllowedIPs = 10.192.122.3/32, 10.192.124.1/24

And a client computer might have this simpler configuration:

[Interface]
PrivateKey = gI6EdUSYvn8ugXOt8QQD6Yc+JyiZxIhp3GInSWRfWGE=
ListenPort = 21841

[Peer]
PublicKey = HIgo9xNzJMWLKASShiTqIybxZ0U3wGLiUeJ1PKf8ykw=
Endpoint = 192.95.5.69:51820
AllowedIPs = 0.0.0.0/0

In the server configuration, each client can send packets to the network interface if its source IP matches the corresponding allowed IP list. For example, when a packet is received from peer gN65BkIK..., if it decrypts and authenticates correctly and its source IP is 10.10.10.230, it is accepted; otherwise, it is dropped.

Likewise, when the server’s interface sends a packet to a client, it examines the packet’s destination IP and compares it with each client’s allowed IP list to determine the correct recipient. For instance, if a packet destined for 10.10.10.230 is sent, it is encrypted using the public key of peer gN65BkIK... and forwarded to that peer’s most recent Internet endpoint.

In the client configuration, the single peer (the server) can send packets to the network interface regardless of source IP (since 0.0.0.0/0 serves as a wildcard). Thus, if a packet from peer HIgo9xNz... decrypts and authenticates correctly, it is accepted; if not, it is dropped.

Similarly, when the client sends a packet to its single peer (the server), it encrypts the packet regardless of its destination IP (again, because 0.0.0.0/0 is a wildcard) and forwards it to the server’s most recent Internet endpoint.

In summary, when sending packets, the allowed IP list functions as a routing table, and when receiving packets, it serves as an access control list. This straightforward association of public keys and allowed IPs is known as a Cryptokey Routing Table.

Any combination of IPv4 and IPv6 can be used in any field, and WireGuard is fully capable of encapsulating one protocol within the other if necessary.

Because all packets on the WireGuard interface are encrypted and authenticated—and because there is a tight coupling between a peer’s identity and its allowed IP address—system administrators do not need complex firewall extensions (as with IPsec). They can simply verify that a packet is from the correct IP on the designated interface, ensuring secure and authentic communication. This greatly simplifies network management and access control while providing confidence that iptables rules function as intended.

Configuration of WireGuard tunnel

Tips

WireGuard is not supported on v1 and v2 router platforms.
Routers allow the creation of only four WireGuard tunnels simultaneously.
Routers cannot be used as a multiclient server.

The WireGuard tunnel enables the secure connection of up to four LAN networks to a single network. To open the WireGuard tunnel configuration page, click WireGuard in the Configuration section of the main menu. The menu item expands to reveal four separate configuration pages: 1st Tunnel, 2nd Tunnel, 3rd Tunnel, and 4th Tunnel. A description of all items is provided in the table below.

Item	Description
Create 1st\|2nd\|3rd\|4th WireGuard tunnel	If enabled, the tunnel is activated.
Description	Description (or name) of tunnel.
Host IP Mode	Select the IP mode: • IPv4 • IPv6
Remote IP Address	IP address of the opposite tunnel side (a domain name can be used).
Remote Port	Port of the opposite tunnel side.
Local Port	Port where WireGuard listens/accepts connections. The default port is 51820.
MTU	The Maximum Transmission Unit (MTU) for the WireGuard tunnel interface, specified in bytes. The default value is 1400 bytes.
NAT/Firewall Traversal	When enabled, a keepalive packet is sent to the server endpoint every 25 seconds. If not needed, leave it disabled. However, if you are behind NAT or a firewall and wish to receive incoming connections long after network traffic has subsided, this option keeps the "connection" open in the eyes of NAT.
Interface IPv4/IPv6 Address	Defines an IP address to assign to the wgX interface. WireGuard provides 4 interfaces (wg1 to wg4) based on tunnel order; each interface must have an IPv4 or IPv6 address, or both.
Interface IPv4/IPv6 Prefix	Defines the IPv4/IPv6 prefix of the local WireGuard tunnel interface.
Install Routes	• No — Disables automatic route installation. Use this option when a dynamic routing protocol (e.g., FRR/BGP) is used to manage routes. • Yes — Enables automatic installation of routes based on the configured subnets.
Traffic Selector	• All traffic — All traffic is routed through the WireGuard tunnel (static routes 0.0.0.0/0 for IPv4 and ::/0 for IPv6 are created). • Subnets — Traffic is routed through the WireGuard tunnel based on the specific subnets defined in the Remote Subnets field.
Remote Subnets	When Traffic Selector is set to subnets, defines specific destination subnets routed through the tunnel. Up to 32 subnets in CIDR notation.
Pre-shared Key	Optional key for enhancing security.
Local Private Key	Local private key.
Local Public Key	Local public key.
Remote Public Key	Public key of the opposite side.

Click Apply to apply the changes.

Configuration example

Advantech router on both sides of the WireGuard tunnel

Configuration of the first router:

Item	Value
Listen Port	51820
NAT/Firewall Traversal	no
Interface IPv4 Address	10.0.0.1
Interface IPv4 Prefix	30
Install Routes	Yes
Traffic Selector	Subnets
Remote Subnets	172.16.24.0/24
Local Public Key	uSa2f1uyYq6z1uOd4Y9jeSHq5PiYpUneWDcBJdtqyis=
Remote Public Key	D2OYEa0MSQR0ONI8CBaqUJJQvXo4CSqmXdE+/3x+Zxc=

Configuration of the second router:

Item	Value
Remote IP Address	10.80.0.27
Remote Port	51820
Listen Port	51820
NAT/Firewall Traversal	yes
Interface IPv4 Address	10.0.0.2
Interface IPv4 Prefix	30
Install Routes	yes
Traffic Selector	Subnets
Remote Subnets	172.16.24.0/24
Local Public Key	D2OYEa0MSQR0ONI8CBaqUJJQvXo4CSqmXdE+/3x+Zxc=
Remote Public Key	uSa2f1uyYq6z1uOd4Y9jeSHq5PiYpUneWDcBJdtqyis=

Configuration of the first router – SERVER

Configuration of the second router – CLIENT

After establishing a WireGuard tunnel, an interface (e.g., wg1) and a corresponding route in the router’s routing table appear on the Network Status page.

You can also verify the successful establishment of a WireGuard tunnel in the system log (found under System Log in the menu). The log entries should end with the word started.

In the Status menu, the WireGuard Tunnel Status page confirms that the tunnel is functioning correctly on both sides.

WireGuard Tunnel Status for first router

WireGuard Tunnel Status for second router

WireGuard tunnel with FRR/BGP

This example demonstrates how to run a WireGuard tunnel with FRR/BGP.

Tips

FRR is a Router App from Advantech and can be downloaded from the Engineering Portal at icr.advantech.com.

WireGuard Tunnel Configuration with use of FRR/BGP

WireGuard with FRR/staticd

Some customers may require more than four static routes. In this case, you can use staticd.

Tips

FRR is a Router App from Advantech and can be downloaded from the Engineering Portal at icr.advantech.com.