How To Set Up WireGuard on Ubuntu

By Jamon Camisso and Manikandan Kurup WireGuard is a lightweight Virtual Private Network (VPN) that supports both IPv4 and IPv6 connections. A VPN allows you to traverse untrusted networks as if you were on a private network. It gives you the ability to access the internet more safely from devices such as laptops or mobile phones when connected to untrusted networks, including public WiFi. WireGuard’s encryption relies on public and private keys for peers to establish encrypted tunnels between themselves. Each WireGuard release uses a fixed set of modern cryptographic methods, which helps keep the protocol simple and predictable. This design avoids runtime negotiation and reduces the risk of configuration errors. In comparison, other VPN software such as OpenVPN and IPsec rely on Transport Layer Security and certificates to authenticate and establish encrypted tunnels. While this approach provides flexibility and supports a wide range of clients, it also increases configuration complexity and makes operational behavior harder to reason about. In this tutorial, you will set up WireGuard on an Ubuntu server and configure another machine to connect to it as a peer using both IPv4 and IPv6, commonly referred to as a dual-stack configuration. You will also learn how to route peer traffic through the WireGuard server in a gateway setup, as well as how to use the VPN for encrypted peer-to-peer communication. In addition to the core setup, this guide covers practical topics that are important for real-world deployments. These include understanding WireGuard’s peer-to-peer architecture, managing and rotating keys, handling IPv6 and dual-stack routing correctly, improving reliability for peers behind NAT, tuning performance, and understanding how WireGuard compares to OpenVPN in terms of transport protocols and firewall behavior. For the purposes of this tutorial, another Ubuntu system is used as the WireGuard Peer. Later tutorials in this series cover installing and using WireGuard on Windows, macOS, Android, and iOS. Deploy your frontend applications from GitHub using DigitalOcean App Platform. Let DigitalOcean focus on scaling your app. Note: If you plan to set up WireGuard on a DigitalOcean Droplet, be aware that we, like many hosting providers, charge for bandwidth overages. For this reason, please be mindful of how much traffic your server is handling. See our Bandwidth Billing page for more info. To follow this tutorial, you will need: One Ubuntu server with a sudo non-root user and a firewall enabled. To set this up, you can follow our Initial Server Setup with Ubuntu tutorial. We will refer to this as the WireGuard Server throughout this guide. You’ll need a client machine that you will use to connect to your WireGuard Server. In this tutorial we’ll refer to this machine as the WireGuard Peer. For the purposes of this tutorial, it’s recommended that you use your local machine as the WireGuard Peer, but you can use remote servers, or mobile phones as clients if you prefer. If you are using a remote system, be sure to follow all of the optional sections later in this tutorial or you may lock yourself out of the system. To use WireGuard with IPv6, you will also need to ensure that your server is configured to support that type of traffic. If you would like to enable IPv6 support with WireGuard and are using a DigitalOcean Droplet, please refer to this documentation page How to Enable IPv6 on Droplets. You can add IPv6 support when you create a Droplet, or afterwards using the instructions on that page. Before configuring WireGuard, it is helpful to understand how systems, peers, and network traffic interact. WireGuard uses a deliberately simple architecture that avoids control planes, certificate authorities, and runtime negotiation of configuration parameters. All encryption, authentication, and routing behavior is defined explicitly through configuration files. WireGuard is fundamentally a peer-to-peer protocol. The same WireGuard software and kernel module run on all participating systems, and there is no distinct server or client binary. In this tutorial, the term WireGuard Server refers to a central hub in a hub-and-spoke topology. This system is publicly reachable and acts as the coordination point for other peers. The term WireGuard Peer refers to devices that connect to this hub. These terms describe the network topology used in this guide, not different software roles or capabilities. Understanding this distinction is important because WireGuard does not have server-only configuration options. Any system can act as a hub, a spoke, or both, depending entirely on how keys, addresses, and routing rules are defined. A WireGuard deployment consists of a small number of clearly defined components, each with a specific responsibility. Central Peer (Hub): The central peer is a publicly reachable system that listens for encrypted UDP traffic on a single port. It hosts a virtual tunnel interface, commonly named wg0, and stores the public keys of other peers that are allowed to communicate with it. The hub does not dynamically discover peers or accept connections implicitly. Traffic is accepted only from peers whose public keys and permitted IP ranges are explicitly configured. Connecting Peers (Spokes): Connecting peers are devices that establish encrypted tunnels to the central peer. These devices can be laptops, servers, virtual machines, or mobile systems. Each peer has a unique cryptographic key pair and one or more private IP addresses assigned to its tunnel interface. A peer sends traffic into the tunnel only when its routing rules instruct it to do so. Tunnel Interface (wg0): The tunnel interface is a virtual network device created on each participating system. All encrypted traffic enters and exits through this interface. From the operating system’s perspective, wg0 behaves like a standard network interface, which allows normal routing tables, firewall rules, and forwarding behavior to apply. WireGuard uses public key cryptography to authenticate peers and encrypt traffic. Each peer generates a long-term private key that remains on the local system and is never transmitted. The corresponding public key is shared with other peers and added to their configurations. When communication begins, WireGuard performs a silent, automatic cryptographic handshake based on the Noise protocol framework. This handshake establishes ephemeral session keys and provides Perfect Forward Secrecy. These session keys are rotated periodically without user intervention. WireGuard does not negotiate cipher suites, authentication methods, or protocol versions. All cryptographic primitives are fixed by design. This removes an entire class of configuration errors while still providing modern security guarantees. WireGuard supports multiple traffic patterns depending on how routing and forwarding are configured. This tutorial focuses on the two most common use cases. In a peer-to-peer or internal access configuration, traffic is encrypted only between systems that are part of the VPN. The central peer acts as a secure endpoint or relay, but it does not forward traffic to external networks. This configuration is typically used to access private services, administer infrastructure, or connect isolated systems. Traffic is routed into the tunnel only when the destination address matches the private IP ranges defined in the peer’s configuration. In gateway mode, the central peer forwards traffic from other peers to external networks, including the public Internet. Peers send some or all of their traffic into the tunnel, and the central peer routes that traffic onward using IP forwarding and network address translation. This configuration requires additional system settings, including kernel forwarding and firewall rules. When gateway mode is enabled, outbound traffic from peers appears to originate from the central peer’s public IP address. The AllowedIPs directive serves two distinct purposes in WireGuard. First, it defines outbound routing behavior. When a packet’s destination address matches an entry in AllowedIPs, that packet is routed through the WireGuard tunnel. Second, AllowedIPs acts as a strict inbound access control list. When a packet is received from a peer, WireGuard checks the packet’s source IP address. If the source address is not listed in that peer’s AllowedIPs, the packet is dropped immediately. This dual role is intentional and is one of the most common sources of configuration errors. Correct routing alone is not sufficient. The source IP addresses that a peer is allowed to use must also be explicitly permitted. The WireGuard kernel module itself does not modify system routes, DNS settings, or firewall rules. It only encrypts and decrypts packets and associates them with peers. Routing automation is handled by helper tools such as wg-quick. This utility reads the WireGuard configuration file and applies the necessary routing table entries, DNS settings, and firewall rules when a tunnel is brought up or down. If WireGuard is configured using alternative tools such as raw wg commands, systemd-networkd, or custom scripts, these routing changes must be managed manually. This separation keeps the core protocol simple while allowing flexible integration with different system networking stacks. The first step in this tutorial is to install WireGuard on your server. To start off, update your WireGuard Server’s package index and install WireGuard using the following commands. You may be prompted to provide your sudo user’s password if this is the first time you’re using sudo in this session: Now that you have WireGuard installed, the next step is to generate a private and public keypair for the server. You’ll use the built-in wg genkey and wg pubkey commands to create the keys, and then add the private key to WireGuard’s configuration file. You will also need to change the permissions on the key that you just created using the chmod command, since by default the file is readable by any user on your server. Create the private key for WireGuard and change its permissions using the following commands: The sudo chmod go=... command removes any permissions on the file for users and groups other than the root user to ensure that only it can access the private key. You should receive a single line of base64 encoded output, which is the private key. A copy of the output is also stored in the /etc/wireguard/private.key file for future reference by the tee portion of the command. Carefully make a note of the private key that is output since you’ll need to add it to WireGuard’s configuration file later in this section. The next step is to create the corresponding public key, which is derived from the private key. Use the following command to create the public key file: This command consists of three individual commands that are chained together using the | (pipe) operator: When you run the command you will again receive a single line of base64 encoded output, which is the public key for your WireGuard Server. Copy it somewhere for reference, since you will need to distribute the public key to any peer that connects to the server. In the previous section you installed WireGuard and generated a key pair that will be used to encrypt traffic to and from the server. In this section, you will create a configuration file for the server, and set up WireGuard to start up automatically when you server reboots. You will also define private IPv4 and IPv6 addresses to use with your WireGuard Server and peers. If you plan to use both IPv4 and IPv6 addresses then follow both of these sections. Otherwise, follow the instructions in the appropriate section for your VPN’s network needs. If you are using your WireGuard server with IPv4 peers, the server needs a range of private IPv4 addresses to use for clients, and for its tunnel interface. You can choose any range of IP addresses from the following reserved blocks of addresses (if you would like to learn more about how these blocks are allocated visit the RFC 1918 specification): For the purposes of this tutorial we’ll use 10.8.0.0/24 as a block of IP addresses from the first range of reserved IPs. This range will allow up to 255 different peer connections, and generally should not have overlapping or conflicting addresses with other private IP ranges. Feel free to choose a range of addresses that works with your network configuration if this example range isn’t compatible with your networks. The WireGuard Server will use a single IP address from the range for its private tunnel IPv4 address. We’ll use 10.8.0.1/24 here, but any address in the range of 10.8.0.1 to 10.8.0.255 can be used. Make a note of the IP address that you choose if you use something different from 10.8.0.1/24. You will add this IPv4 address to the configuration file that you define in Creating a WireGuard Server Configuration. If you are using WireGuard with IPv6, then you will need to generate a unique local IPv6 unicast address prefix based on the algorithm in RFC 4193. The addresses that you use with WireGuard will be associated with a virtual tunnel interface. You will need to complete a few steps to generate a random, unique IPv6 prefix within the reserved fd00::/8 block of private IPv6 addresses. According to the RFC, the recommended way to obtain a unique IPv6 prefix is to combine the time of day with a unique identifying value from a system like a serial number or device ID. Those values are then hashed and truncated resulting in a set of bits that can be used as a unique address within the reserved private fd00::/8 block of IPs. To get started generating an IPv6 range for your WireGuard Server, collect a 64-bit timestamp using the date utility with the following command: You will receive a number like the following, which is the number of seconds (the %s in the date command), and nanoseconds (the %N) since 1970-01-01 00:00:00 UTC combined together: Record the value somewhere for use later in this section. Next, copy the machine-id value for your server from the /var/lib/dbus/machine-id file. This identifier is unique to your system and should not change for as long as the server exists. You will receive output like the following: Now you need to combine the timestamp with the machine-id and hash the resulting value using the SHA-1 algorithm. The command will use the following format: Run the command substituting in your timestamp and machine identity values: You will receive a hash value like the following: Note that the output of the sha1sum command is in hexadecimal, so the output uses two characters to represent a single byte of data. For example 4f and 26 in the example output are the first two bytes of the hashed data. The algorithm in the RFC only requires the least significant (trailing) 40 bits, or 5 bytes, of the hashed output. Use the cut command to print the last 5 hexadecimal encoded bytes from the hash: The -c argument tells the cut command to select only a specified set of characters. The 31- argument tells cut to print all the characters from position 31 to the end of the input line. You should receive output like the following: In this example output, the set of bytes is: 0d 86 fa c3 bc. Now you can construct your unique IPv6 network prefix by appending the 5 bytes you have generated with the fd prefix, separating every 2 bytes with a : colon for readability. Because each subnet in your unique prefix can hold a total of 18,446,744,073,709,551,616 possible IPv6 addresses, you can restrict the subnet to a standard size of /64 for simplicity. Using the bytes previously generated with the /64 subnet size the resulting prefix will be the following: This fd0d:86fa:c3bc::/64 range is what you will use to assign individual IP addresses to your WireGuard tunnel interfaces on the server and peers. To allocate an IP for the server, add a 1 after the final :: characters. The resulting address will be fd0d:86fa:c3bc::1/64. Peers can use any IP in the range, but typically you’ll increment the value by one each time you add a peer e.g. fd0d:86fa:c3bc::2/64. Make a note of the IP and proceed configuring the WireGuard Server in the next section of this tutorial. The existing steps in this tutorial explain how to generate IPv6 addresses and assign them to WireGuard interfaces. However, IPv6 behavior in WireGuard differs in several important ways from IPv4, especially when WireGuard is used as a VPN gateway. Understanding these differences helps prevent routing failures, partial tunneling, and common IPv6 leaks. WireGuard supports IPv6 as a first-class protocol. IPv6 traffic is encrypted, authenticated, and routed using the same mechanisms as IPv4 traffic. There is no separate IPv6 mode or additional configuration flag. If IPv6 addresses are assigned to the tunnel interface and routing rules allow it, IPv6 traffic flows through the tunnel automatically. Unlike IPv4, IPv6 is designed to avoid NAT by using globally routable addresses, but in practice many VPN and cloud environments still use NAT for operational simplicity. However, this behavior depends on the network environment. In many VPN gateway setups, such as cloud VPS instances or home routers, the server does not receive a delegated IPv6 prefix that can be routed to VPN peers. In these common scenarios, peers are assigned private IPv6 addresses, typically from a Unique Local Address (ULA) range. When private IPv6 addresses are used and the server does not have a routable prefix for them, IPv6 masquerading is still required. This is usually implemented with ip6tables -t nat rules, similar to IPv4 masquerading, to allow VPN peers to reach the public Internet. IPv6 can avoid NAT entirely when proper prefix delegation is available. However, most simple VPN gateway deployments still rely on IPv6 masquerading to keep routing manageable. A dual-stack configuration enables both IPv4 and IPv6 on the same WireGuard interface. In this setup, the wg0 interface is assigned one IPv4 address and one IPv6 address, and each protocol is routed independently. The operating system evaluates IPv4 and IPv6 routes separately. A peer may successfully route IPv4 traffic through the tunnel while IPv6 traffic bypasses it, or vice versa. This behavior is expected and almost always indicates a configuration issue rather than a problem with WireGuard itself. For dual-stack routing to work correctly, several conditions must be met. Both the server and the peer must have IPv4 and IPv6 addresses assigned to their WireGuard interfaces. The AllowedIPs directive must include both IPv4 and IPv6 ranges. IP forwarding must be enabled separately for IPv4 and IPv6. Firewall rules must permit forwarding and return traffic for both protocols. For IPv4, WireGuard deployments typically use private address ranges such as 10.0.0.0/8 or 192.168.0.0/16. Each peer is commonly assigned a single IPv4 address. For IPv6, it is common to define the VPN network as a /64 prefix, such as fd00::/64. While Ethernet networks require a /64 for neighbor discovery and address autoconfiguration, WireGuard operates as a Layer 3 point-to-point interface and does not use these mechanisms. Because of this, it is safe and often recommended to assign each peer a /128 IPv6 address, such as fd00::2/128. Using /128 addresses ensures strict routing behavior and prevents peers from attempting to communicate directly with other addresses in the subnet without proper routing rules. Defining the network as a /64 while assigning peers /128 addresses provides clarity and avoids ambiguous routing. When WireGuard is configured as a VPN gateway, IPv6 traffic must be routed explicitly in the same way as IPv4 traffic. For IPv4, routing all traffic uses the 0.0.0.0/0 prefix. For IPv6, the equivalent prefix is ::/0. Both prefixes must be included if the goal is to route all traffic through the VPN. If only 0.0.0.0/0 is configured, IPv4 traffic is sent through the VPN while IPv6 traffic continues to use the local network interface. This situation is known as an IPv6 leak. It commonly results in DNS queries, web traffic, or application connections bypassing the VPN over IPv6 while IPv4 traffic remains protected. IPv6 leaks are a frequent source of confusion and should always be tested for when dual-stack networking is enabled. IPv6 forwarding must be enabled independently from IPv4 forwarding. Enabling one does not automatically enable the other. Both settings are required when routing traffic between interfaces. Firewall rules must also be defined explicitly for IPv6. Tools such as ufw, iptables, and nftables treat IPv4 and IPv6 as separate rule sets. Missing IPv6 rules can silently block traffic even when IPv4 connectivity appears to work. It is especially important to allow ICMPv6 traffic. Unlike IPv4, IPv6 depends on ICMPv6 for essential functions such as Path MTU Discovery. If ICMPv6 is blocked, connections may hang or fail when larger packets are transmitted, even though small packets appear to work. Several issues commonly occur in dual-stack WireGuard deployments. IPv6 routes may be missing from the AllowedIPs directive, causing IPv6 traffic to bypass the tunnel. IPv6 forwarding may not be enabled on the server, preventing traffic from leaving the tunnel interface. Firewall rules may allow IPv4 traffic but block IPv6 or ICMPv6 traffic. DNS resolvers may return IPv6 addresses even though IPv6 routing is not correctly configured. These problems often appear as intermittent failures and are frequently misdiagnosed as application or protocol issues. In some environments, using a single protocol simplifies operations. IPv4-only deployments are easier to integrate with legacy systems and tooling. IPv6-only deployments remove the need for IPv4 NAT and avoid address exhaustion, but they require consistent IPv6 support from providers and client networks. Dual-stack deployments provide the greatest flexibility but also require the most careful planning, configuration, and validation. Before creating your WireGuard Server’s configuration, you will need the following pieces of information: Once you have the required private key and IP address(es), create a new configuration file using nano or your preferred editor by running the following command: Add the following lines to the file, substituting your private key in place of the highlighted base64_encoded_private_key_goes_here value, and the IP address(es) on the Address line. You can also change the ListenPort line if you would like WireGuard to be available on a different port: The SaveConfig line ensures that when a WireGuard interface is shutdown, any changes will get saved to the configuration file. Save and close the /etc/wireguard/wg0.conf file. If you are using nano, you can do so with CTRL+X, then Y and ENTER to confirm. You now have an initial server configuration that you can build upon depending on how you plan to use your WireGuard VPN server. If you are using WireGuard to connect a peer to the WireGuard Server in order to access services on the server only, then you do not need to complete this section. If you would like to route your WireGuard Peer’s Internet traffic through the WireGuard Server then you will need to configure IP forwarding by following this section of the tutorial. To configure forwarding, open the /etc/sysctl.conf file using nano or your preferred editor: If you are using IPv4 with WireGuard, add the following line at the bottom of the file: If you are using IPv6 with WireGuard, add this line at the bottom of the file: If you are using both IPv4 and IPv6, ensure that you include both lines. Save and close the file when you are finished. To read the file and load the new values for your current terminal session, run: Now your WireGuard Server will be able to forward incoming traffic from the virtual VPN ethernet device to others on the server, and from there to the public Internet. Using this configuration will allow you to route all web traffic from your WireGuard Peer via your server’s IP address, and your client’s public IP address will be effectively hidden. However, before traffic can be routed via your server correctly, you will need to configure some firewall rules. These rules will ensure that traffic to and from your WireGuard Server and Peers flows properly. In this section you will edit the WireGuard Server’s configuration to add firewall rules that will ensure traffic to and from the server and clients is routed correctly. As with the previous section, skip this step if you are only using your WireGuard VPN for a machine to machine connection to access resources that are restricted to your VPN. To allow WireGuard VPN traffic through the Server’s firewall, you’ll need to enable masquerading, which is an iptables concept that provides on-the-fly dynamic network address translation (NAT) to correctly route client connections. First find the public network interface of your WireGuard Server using the ip route sub-command: The public interface is the string found within this command’s output that follows the word “dev”. For example, this result shows the interface named eth0, which is highlighted below: Note your device’s name since you will add it to the iptables rules in the next step. To add firewall rules to your WireGuard Server, open the /etc/wireguard/wg0.conf file with nano or your preferred editor again. At the bottom of the file after the SaveConfig = true line, paste the following lines: The PostUp lines will run when the WireGuard Server starts the virtual VPN tunnel. In the example here, it will add three ufw and iptables rules: Note: IPv6 masquerading requires kernel support for ip6table_nat. On some distributions or cloud images this module is not available or not enabled by default. In those cases, you must use proper IPv6 routing with delegated prefixes instead of NAT, and advertise a routable IPv6 prefix to peers rather than using ULA addresses. The PreDown rules run when the WireGuard Server stops the virtual VPN tunnel. These rules are the inverse of the PostUp rules, and function to undo the forwarding and masquerading rules for the VPN interface when the VPN is stopped. In both cases, edit the configuration to include or exclude the IPv4 and IPv6 rules that are appropriate for your VPN. For example, if you are just using IPv4, then you can exclude the lines with the ip6tables commands. Conversely, if you are only using IPv6, then edit the configuration to only include the ip6tables commands. The ufw lines should exist for any combination of IPv4 and IPv6 networks. Save and close the file when you are finished. The last part of configuring the firewall on your WireGuard Server is to allow traffic to and from the WireGuard UDP port itself. If you did not change the port in the server’s /etc/wireguard/wg0.conf file, the port that you will open is 51820. If you chose a different port when editing the configuration be sure to substitute it in the following UFW command. In case you forgot to open the SSH port when following the prerequisite tutorial, add it here too: Note: If you are using a different firewall or have customized your UFW configuration, you may need to add additional firewall rules. For example, if you decide to tunnel all of your network traffic over the VPN connection, you will need to ensure that port 53 traffic is allowed for DNS requests, and ports like 80 and 443 for HTTP and HTTPS traffic respectively. If there are other protocols that you are using over the VPN then you will need to add rules for them as well. After adding those rules, disable and re-enable UFW to restart it and load the changes from all of the files you’ve modified: You can confirm the rules are in place by running the ufw status command. Run it, and you should receive output like the following: Your WireGuard Server is now configured to correctly handle the VPN’s traffic, including forwarding and masquerading for peers. With the firewall rules in place, you can start the WireGuard service itself to listen for peer connections. WireGuard can be configured to run as a systemd service using its built-in wg-quick script. While you could manually use the wg command to create the tunnel every time you want to use the VPN, doing so is a manual process that becomes repetitive and error prone. Instead, you can use systemctl to manage the tunnel with the help of the wg-quick script. Using a systemd service means that you can configure WireGuard to start up at boot so that you can connect to your VPN at any time as long as the server is running. To do this, enable the wg-quick service for the wg0 tunnel that you’ve defined by adding it to systemctl: Notice that the command specifies the name of the tunnel wg0 device name as a part of the service name. This name maps to the /etc/wireguard/wg0.conf configuration file. This approach to naming means that you can create as many separate VPN tunnels as you would like using your server. For example, you could have a tunnel device and name of prod and its configuration file would be /etc/wireguard/prod.conf. Each tunnel configuration can contain different IPv4, IPv6, and client firewall settings. In this way you can support multiple different peer connections, each with their own unique IP addresses and routing rules. Now start the service: Double check that the WireGuard service is active with the following command. You should see the service listed as active. Note that wg-quick exits after configuring the interface, so active (exited) is normal. The output shows the ip commands that are used to create the virtual wg0 device and assign it the IPv4 and IPv6 addresses that you added to the configuration file. You can use these rules to troubleshoot the tunnel, or with the wg command itself if you would like to try manually configuring the VPN interface. With the server configured and running, the next step is to configure your client machine as a WireGuard Peer and connect to the WireGuard Server. Configuring a WireGuard Peer is similar to setting up the WireGuard Server. Once you have the client software installed, you’ll generate a public and private key pair, decide on an IP address or addresses for the peer, define a configuration file for the peer, and then start the tunnel using the wg-quick script. You can add as many peers as you like to your VPN by generating a key pair and configuration using the following steps. If you add multiple peers to the VPN be sure to keep track of their private IP addresses to prevent collisions. To configure the WireGuard Peer, ensure that you have the WireGuard package installed using the following apt commands. On the WireGuard Peer run: Next, you’ll need to generate the key pair on the peer using the same steps as you used on the server. From your local machine or remote server that will serve as peer, proceed and create the private key for the peer using the following commands: Again you will receive a single line of base64 encoded output, which is the private key. A copy of the output is also stored in the /etc/wireguard/private.key. Carefully make a note of the private key that is output since you’ll need to add it to WireGuard’s configuration file later in this section. Next use the following command to create the public key file: You will again receive a single line of base64 encoded output, which is the public key for your WireGuard Peer. Copy it somewhere for reference, since you will need to distribute the public key to the WireGuard Server in order to establish an encrypted connection. Now that you have a key pair, you can create a configuration file for the peer that contains all the information that it needs to establish a connection to the WireGuard Server. You will need a few pieces of information for the configuration file: With all this information at hand, open a new /etc/wireguard/wg0.conf file on the WireGuard Peer machine using nano or your preferred editor: Add the following lines to the file, substituting in the various data into the highlighted sections as required: Notice how the first Address line uses an IPv4 address from the 10.8.0.0/24 subnet that you chose earlier. This IP address can be anything in the subnet as long as it is different from the server’s IP. Incrementing addresses by 1 each time you add a peer is generally the easiest way to allocate IPs. Likewise, notice how the second Address line uses an IPv6 address from the subnet that you generated earlier, and increments the server’s address by one. Again, any IP in the range is valid if you decide to use a different address. The other notable part of the file is the last AllowedIPs line. These two IPv4 and IPv6 ranges instruct the peer to only send traffic over the VPN if the destination system has an IP address in either range. Using the AllowedIPs directive, you can restrict the VPN on the peer to only connect to other peers and services on the VPN, or you can configure the setting to tunnel all traffic over the VPN and use the WireGuard Server as a gateway. If you are only using IPv4, then omit the trailing fd0d:86fa:c3bc::/64 range (including the , comma). Conversely, if you are only using IPv6, then only include the fd0d:86fa:c3bc::/64 prefix and leave out the 10.8.0.0/24 IPv4 range. In both cases, if you would like to send all your peer’s traffic over the VPN and use the WireGuard Server as a gateway for all traffic, then you can use 0.0.0.0/0, which represents the entire IPv4 address space, and ::/0 for the entire IPv6 address space. If you have opted to route all of the peer’s traffic over the tunnel using the 0.0.0.0/0 or ::/0 routes and the peer is a remote system, then you will need to complete the steps in this section. If your peer is a local system then it is best to skip this section. For remote peers that you access via SSH or some other protocol using a public IP address, you will need to add some extra rules to the peer’s wg0.conf file. These rules will ensure that you can still connect to the system from outside of the tunnel when it is connected. Otherwise, when the tunnel is established, all traffic that would normally be handled on the public network interface will not be routed correctly to bypass the wg0 tunnel interface, leading to an inaccessible remote system. First, you’ll need to determine the IP address that the system uses as its default gateway. Run the following ip route command: You will receive output like the following: Note the gateway’s highlighted IP address 203.0.113.1 for later use, and device eth0. Your device name may be different. If so, substitute it in place of eth0 in the following commands. Next find the public IP for the system by examining the device with the ip address show command: You will receive output like the following: In this example output, the highlighted 203.0.113.5 IP (without the trailing /20) is the public address that is assigned to the eth0 device that you’ll need to add to the WireGuard configuration. Now open the WireGuard Peer’s /etc/wireguard/wg0.conf file with nano or your preferred editor. Before the [Peer] line, add the following 4 lines: These lines will create a custom routing rule, and add a custom route to ensure that public traffic to the system uses the default gateway. The PreDown lines remove the custom rule and route when the tunnel is shutdown. Note: The table number 200 is arbitrary when constructing these rules. You can use a value between 2 and 252, or you can use a custom name by adding a label to the /etc/iproute2/rt_tables file and then referring to the name instead of the numeric value. For more information about how routing tables work in Linux visit the Routing Tables Section of the Guide to IP Layer Network Administration with Linux. If you are routing all the peer’s traffic over the VPN, ensure that you have configured the correct sysctl and iptables rules on the WireGuard Server in Adjusting the WireGuard Server’s Network Configuration and Configuring the WireGuard Server’s Firewall. If you are using the WireGuard Server as a VPN gateway for all your peer’s traffic, you will need to add a line to the [Interface] section that specifies DNS resolvers. If you do not add this setting, then your DNS requests may not be secured by the VPN, or they might be revealed to your Internet Service Provider or other third parties. If you are only using WireGuard to access resources on the VPN network or in a peer-to-peer configuration then you can skip this section. To add DNS resolvers to your peer’s configuration, first determine which DNS servers your WireGuard Server is using. Run the following command on the WireGuard Server, substituting in your ethernet device name in place of eth0 if it is different from this example: You should receive output like the following: The IP addresses that are output are the DNS resolvers that the server is using. You can choose to use any or all of them, or only IPv4 or IPv6 depending on your needs. Make a note of the resolvers that you will use. Next you will need to add your chosen resolvers to the WireGuard Peer’s configuration file. Back on the WireGuard Peer, open /etc/wireguard/wg0.conf file using nano or your preferred editor: Before the [Peer] line, add the following: Again, depending on your preference or requirements for IPv4 and IPv6, you can edit the list according to your needs. Once you are connected to the VPN in the following step, you can check that you are sending DNS queries over the VPN by using a site like DNS leak test. You can also check that your peer is using the configured resolvers with the resolvectl dns command like you ran on the server. You should receive output like the following, showing the DNS resolvers that you configured for the VPN tunnel: With all of these DNS resolver settings in place, you are now ready to add the peer’s public key to the server, and then start the WireGuard tunnel on the peer. Before connecting the peer to the server, it is important to add the peer’s public key to the WireGuard Server. This step ensures that you will be able to connect to and route traffic over the VPN. Without completing this step the WireGuard server will not allow the peer to send or receive any traffic over the tunnel. Ensure that you have a copy of the base64 encoded public key for the WireGuard Peer by running: Now log into the WireGuard server, and run the following command: Note that the allowed-ips portion of the command takes a comma separated list of IPv4 and IPv6 addresses. You can specify individual IPs if you would like to restrict the IP address that a peer can assign itself, or a range like in the example if your peers can use any IP address in the VPN range. Also note that no two peers can have the same allowed-ips setting. If you would like to update the allowed-ips for an existing peer, you can run the same command again, but change the IP addresses. Multiple IP addresses are supported. For example, to change the WireGuard Peer that you just added to add an IP like 10.8.0.100 to the existing 10.8.0.2 and fd0d:86fa:c3bc::2 IPs, you would run the following: Once you have run the command to add the peer, check the status of the tunnel on the server using the wg command: Notice how the peer line shows the WireGuard Peer’s public key, and the IP addresses, or ranges of addresses that it is allowed to use to assign itself an IP. Now that you have defined the peer’s connection parameters on the server, the next step is to start the tunnel on the peer. Now that your server and peer are both configured to support your choice of IPv4, IPv6, packet forwarding, and DNS resolution, it is time to connect the peer to the VPN tunnel. Since you may only want the VPN to be on for certain use cases, we’ll use the wg-quick command to establish the connection manually. If you would like to automate starting the tunnel like you did on the server, follow those steps in Starting the WireGuard Server section instead of using the wq-quick command. In case you are routing all traffic through the VPN and have set up DNS forwarding, you’ll need to install the resolvconf utility on the WireGuard Peer before you start the tunnel. Run the following command to set this up: To start the tunnel, run the following on the WireGuard Peer: You will receive output like the following: Notice the highlighted IPv4 and IPv6 addresses that you assigned to the peer. If you set the AllowedIPs on the peer to 0.0.0.0/0 and ::/0 (or to use ranges other than the ones that you chose for the VPN), then your output will resemble the following: In this example, notice the highlighted routes that the command added, which correspond to the AllowedIPs in the peer configuration. You can check the status of the tunnel on the peer using the wg command: You can also check the status on the server again, and you will receive similar output. Verify that your peer is using the VPN by using the ip route and ip -6 route commands. If you are using the VPN as a gateway for all your Internet traffic, check which interface will be used for traffic destined to CloudFlare’s 1.1.1.1 and 2606:4700:4700::1111 DNS resolvers. If you are only using WireGuard to access resources on the VPN, substitute a valid IPv4 or IPv6 address like the gateway itself into these commands. For example 10.8.0.1 or fd0d:86fa:c3bc::1. Notice the wg0 device is used and the IPv4 address 10.8.0.2 that you assigned to the peer. Likewise, if you are using IPv6, run the following: Again note the wg0 interface, and the IPv6 address fd0d:86fa:c3bc::2 that you assigned to the peer. If your peer has a browser installed, you can also visit ipleak.net and ipv6-test.com to confirm that your peer is routing its traffic over the VPN. Once you are ready to disconnect from the VPN on the peer, use the wg-quick command: You will receive output like the following indicating that the VPN tunnel is shut down: If you set the AllowedIPs on the peer to 0.0.0.0/0 and ::/0 (or to use ranges other than the ones that you chose for the VPN), then your output will resemble the following: To reconnect to the VPN, run the wg-quick up wg0 command again on the peer. If you would like to completely remove a peer’s configuration from the WireGuard Server, you can run the following command, being sure to substitute the correct public key for the peer that you want to remove: Typically you will only need to remove a peer configuration if the peer no longer exists, or if its encryption keys are compromised or changed. Otherwise it is better to leave the configuration in place so that the peer can reconnect to the VPN without requiring that you add its key and allowed-ips each time. WireGuard relies on static public and private key pairs for authentication and encryption. This design significantly reduces configuration complexity, but it also places responsibility for key management entirely on the administrator. For long-running VPN deployments, shared infrastructure, or environments with multiple peers, careful key management is essential for maintaining security and operational stability. Each WireGuard Peer uses two categories of cryptographic keys. Long-term private keys: A private key uniquely identifies a peer and must remain secret at all times. This key is used during encrypted handshakes to authenticate the peer and derive short-lived session keys. If a private key is exposed, any system holding that key can impersonate the peer. Long-term public keys: A public key is derived from a private key and is shared with other peers. On the central hub, public keys determine which peers are allowed to communicate and which IP addresses they are permitted to use. In addition to these long-term keys, WireGuard automatically derives ephemeral session keys during encrypted handshakes. These session keys are rotated periodically and provide Perfect Forward Secrecy without administrator involvement. The following practices help reduce risk and simplify ongoing operations: Assign a unique key pair to each peer: Each device should have its own private and public key pair. Using unique keys allows access to be revoked for a single device without affecting others. Reusing keys across multiple systems increases the impact of a compromise and complicates auditing. Limit access to private key material: Private key files should be readable only by the root user. On Linux systems, this typically means setting permissions to 600 using a command such as chmod 600 /etc/wireguard/private.key. Restricting file access helps prevent accidental disclosure through backups, logs, or non-privileged users. Maintain an explicit peer inventory: Keep a record that maps each peer’s public key to its device name, assigned IPv4 and IPv6 addresses, and intended purpose. This documentation becomes increasingly important as the number of peers grows and simplifies troubleshooting, audits, and routine maintenance. Remove unused or inactive peers promptly: When a device is decommissioned or no longer requires VPN access, remove its public key from the central peer configuration. Leaving unused keys in place increases the attack surface and makes future reviews more difficult. Key rotation should be performed in several common scenario: Suspected or confirmed key exposure: If a private key may have been copied, leaked, or accessed by an unauthorized party, it should be rotated immediately to prevent impersonation. Lost or stolen devices: When a device is lost or stolen, rotating its keys ensures that it can no longer connect to the VPN, even if the original configuration is recovered. Organizational security requirements: Some environments require periodic key rotation to meet internal policies or compliance standards, even if no compromise is suspected. Changes in device ownership or role: When a peer is reassigned to a different user or purpose, rotating its keys prevents unintended continued access. WireGuard maps internal IP addresses to specific public keys using a cryptokey routing table. Because of this design, the same internal IP address cannot be safely assigned to two public keys at the same time. Key rotation therefore usually involves a brief interruption in connectivity while the configuration is updated. To rotate a peer’s keys, follow this process: This replacement-based approach reflects how WireGuard enforces cryptographic routing and avoids ambiguous or conflicting configurations. Rotating the private key of the central peer affects all connecting peers. Each peer configuration must be updated with the new public key before connectivity can be restored. Because this change impacts every peer simultaneously, central peer key rotation should be planned carefully and performed during a maintenance window. In practice, central keys are rotated less frequently than peer keys. In addition to public and private key pairs, WireGuard supports an optional Pre-Shared Key (PSK) for each peer. A PSK adds an additional layer of symmetric encryption on top of WireGuard’s existing cryptography. Pre-Shared Keys are commonly used in high-security environments as a defense against future cryptographic advances. If encrypted traffic is recorded today and the underlying public key algorithm is compromised in the future, a PSK would still prevent decryption of past sessions. If PSKs are used, they should be treated as sensitive secrets and rotated periodically. Rotating a PSK follows the same operational pattern as rotating peer keys and must be coordinated on both sides of the connection. WireGuard does not enforce a fixed key rotation schedule. Suitable rotation intervals depend on the environment. Regular rotation reduces the risk associated with long-lived credentials and aligns WireGuard deployments with common security practices. WireGuard and OpenVPN are both widely used VPN technologies, but they take very different approaches to encryption, configuration, and network behavior. Understanding these differences helps developers choose the solution that best fits their operational constraints. WireGuard uses a static configuration model based on public and private key pairs. All peers are defined explicitly, and routing behavior is controlled through fixed configuration values. There is no control channel, certificate authority, or dynamic negotiation of parameters. OpenVPN relies on TLS and X.509 certificates. It uses a control channel to authenticate clients, negotiate encryption settings, and manage sessions. This model provides flexibility but increases configuration and operational complexity. In practice, WireGuard configurations are shorter, easier to audit, and less prone to subtle misconfiguration. OpenVPN configurations offer more control but require careful management to remain secure and consistent. WireGuard uses a fixed set of modern cryptographic methods. These choices are not configurable. This design eliminates cryptographic downgrade attacks and removes the need to select cipher suites. OpenVPN supports a wide range of encryption algorithms and authentication methods. While this flexibility allows compatibility with legacy systems, it also increases the risk of weak or inconsistent configurations. Both solutions support Perfect Forward Secrecy. WireGuard performs key rotation automatically through its handshake mechanism, while OpenVPN relies on TLS session behavior. WireGuard is designed for high performance and low latency. It runs in the Linux kernel and has a small codebase, which reduces overhead and context switching. In most environments, WireGuard delivers higher throughput and more consistent latency with minimal tuning. Historically, OpenVPN runs in user space and incurs additional overhead from context switches and protocol handling. Modern versions of OpenVPN support Kernel Data Channel Offload (DCO), which significantly improves performance, but this feature is not always enabled or available in default deployments. Even with DCO, WireGuard typically achieves strong performance with fewer configuration variables. WireGuard handles network changes gracefully. If a peer’s IP address changes, such as when switching between WiFi and mobile networks, the tunnel continues to function without renegotiation. However, WireGuard operates exclusively over UDP. While UDP is efficient, it is sometimes blocked on restrictive public WiFi networks, corporate firewalls, or institutional networks. WireGuard has no native fallback when UDP traffic is blocked. OpenVPN supports both UDP and TCP. When UDP is unavailable, OpenVPN can be configured to run over TCP port 443, making VPN traffic appear similar to standard HTTPS traffic. This capability makes OpenVPN more reliable in environments with strict firewall rules or censorship. For users operating behind restrictive networks, TCP support is often the deciding factor in choosing OpenVPN over WireGuard. OpenVPN includes features that WireGuard intentionally does not provide. These include user-based authentication, dynamic address assignment, and integration with external identity systems. WireGuard focuses exclusively on secure tunneling. Authentication workflows, access control, and dynamic configuration must be handled outside the protocol. This makes OpenVPN a better fit for environments that require complex authentication or centralized user management, while WireGuard is better suited to infrastructure-level VPNs and peer-based access. WireGuard is well suited for infrastructure VPNs, site-to-site tunnels, mobile clients, and environments where simplicity, performance, and predictability are priorities. OpenVPN remains a strong choice for enterprise environments that require TCP-based tunneling, advanced authentication, or reliable operation behind restrictive firewalls. In many modern deployments, WireGuard replaces OpenVPN not because it offers more features, but because it offers fewer features with clearer behavior. WireGuard performs well with its default settings, but real-world network conditions can affect reliability and throughput. Factors such as packet size, routing scope, NAT behavior, and DNS resolution all influence how the tunnel behaves during sustained or intermittent use. Let’s look at the most common tuning areas and when adjustments are appropriate. The Maximum Transmission Unit (MTU) defines the largest packet size that can be transmitted without fragmentation. WireGuard encrypts and encapsulates packets, which reduces the effective MTU compared to a physical network interface. By default, WireGuard uses an MTU of 1420. This value accounts for the combined overhead of IPv6 headers, UDP, and WireGuard encapsulation and works well for most Ethernet-based networks. Some environments require a smaller MTU. This is common on mobile networks, PPPoE connections, and cloud platforms with additional encapsulation layers. When the MTU is too large, packets may be dropped or fragmented. This often results in connections that work for small requests but stall or fail for larger transfers. If these symptoms occur, lowering the MTU incrementally is recommended. Values such as 1360, or in more constrained environments 1280 which is the IPv6 minimum MTU, often resolve these issues with minimal impact on throughput. MTU should be set explicitly in the [Interface] section of the configuration file to ensure consistent behavior across restarts. The AllowedIPs directive influences both routing behavior and performance. Broad address ranges cause more traffic to traverse the tunnel, which increases encryption overhead and load on the server. Using narrow AllowedIPs values limits the tunnel to only the traffic that requires protection. This reduces CPU usage and avoids unnecessary encapsulation. When 0.0.0.0/0 or ::/0 is configured, all traffic is routed through the VPN. This configuration is appropriate when privacy, centralized egress control, or untrusted networks are a concern, but it increases latency and resource usage for general Internet traffic. Performance tuning often involves narrowing AllowedIPs where possible and avoiding full-tunnel routing unless it is required. WireGuard is intentionally silent when no data is being transmitted. It does not send periodic keepalive packets by default. In environments that use NAT, such as home routers, mobile networks, or many cloud networks, this silence can cause the NAT device to close the connection mapping. When this happens, inbound traffic from the server is blocked until the peer sends traffic again. This behavior is often perceived as lag, delayed connections, or intermittent failures. To prevent this, WireGuard provides the PersistentKeepalive setting. This option can be added to the [Peer] section of the peer configuration. It causes the peer to send a small keepalive packet at a fixed interval to keep the NAT mapping open. A value of 25 seconds is commonly used and works well with most NAT devices. If a connection works initially but fails after being idle, enabling PersistentKeepalive = 25 is the primary and recommended fix. DNS configuration has a significant impact on perceived VPN performance. When DNS resolvers are not correctly routed through the tunnel, applications may appear slow or unreliable even when the tunnel itself is functioning correctly. In gateway configurations, DNS queries should be sent through the VPN to ensure consistent routing and avoid leaks. This requires explicitly defining DNS resolvers in the peer configuration. When DNS is misconfigured, common symptoms include slow page loads, inconsistent connectivity, or traffic being routed outside the VPN despite an active tunnel. Selecting resolvers that are reachable through the tunnel and respond quickly improves both reliability and user experience. In dual-stack environments, IPv4 and IPv6 may behave differently. IPv6 paths can have different MTU constraints, routing policies, or firewall behavior. Testing both protocols independently helps identify protocol-specific issues. Tools such as ping, tracepath, and ip route get are useful for validating routing and MTU behavior for each address family. If IPv6 performance appears inconsistent, verify that ICMPv6 traffic is permitted. ICMPv6 is required for Path MTU Discovery, and blocking it can cause connections to stall on larger packets. WireGuard uses modern cryptography that is efficient on most systems. However, encryption still consumes CPU resources. On small virtual machines, embedded routers, or systems without hardware acceleration, full-tunnel configurations can saturate CPU under sustained load. Monitoring CPU usage during high traffic helps determine whether performance issues are caused by encryption overhead rather than network configuration. In such cases, reducing tunneled traffic or upgrading the server instance may be necessary. Performance tuning should be done incrementally. After each change, connectivity and stability should be verified before applying additional adjustments. Useful validation steps include checking handshake stability with wg, measuring latency and throughput before and after changes, and confirming routing behavior with ip route and ip -6 route. This approach minimizes risk and simplifies troubleshooting. WireGuard is a modern VPN technology designed to be much faster and easier to set up than older options like OpenVPN or IPsec. You can think of it as a secure tunnel that connects your devices directly. Unlike older VPNs that are heavy and complex, WireGuard is extremely lightweight. On Ubuntu, it works by running directly inside the Linux kernel; the core “engine” of the operating system. Because it runs deep in the system rather than as a separate application on top, it uses very little battery power and processes data incredibly fast. To establish a connection, WireGuard uses a method very similar to SSH. It generates a pair of “keys” for every device: a private key (which stays secret on the device) and a public key (which you share with the other devices you want to connect to). The connection only happens if the keys match perfectly, making the handshake fast and secure. For most users, WireGuard is considered more secure because of its simplicity and modern design. The primary reason is the size of its code. WireGuard is built with only about 4,000 lines of code, whereas OpenVPN has over 100,000. This massive difference means it is much easier for security experts to read the WireGuard code and find vulnerabilities (bugs) before bad actors do. WireGuard also forces you to use the newest, strongest encryption standards available today. Older VPNs allow crypto-agility, which means they can downgrade to weaker encryption methods to support old devices. WireGuard removes this choice, preventing attackers from tricking your VPN into using a weaker lock. Additionally, WireGuard is stealthy by default; if an unauthorized device sends a packet to your server, WireGuard simply won’t reply. This makes your server invisible to hackers scanning for open ports. Yes, you can easily set it up directly on the system without using Docker containers. In fact, running it directly is often the preferred method on Ubuntu because the software is included in the standard Ubuntu software repositories. You generally only need to run the standard installation commands below, which will pull the necessary software straight from Ubuntu’s official source. WireGuard uses a peer-to-peer concept, meaning every device you connect is treated as a “peer.” To add multiple devices, like a laptop, a smartphone, and a tablet, you simply edit the server’s configuration file (usually located at /etc/wireguard/wg0.conf). For each new device, you add a new block of text labeled [Peer]. Inside this block, you must paste the Public Key of that specific device and assign it a unique internal IP address (like 10.0.0.2 for the first device, 10.0.0.3 for the second, and so on). It is critical that these internal IP addresses do not overlap. Here’s a simple example configuration block: WireGuard uses UDP port 51820 by default. It relies strictly on the UDP protocol because it is faster for tunneling data than TCP. TCP requires a confirmation for every packet of data sent, which can slow down a VPN connection significantly. UDP just sends the data without waiting for a receipt, which is perfect for the high-speed nature of WireGuard. When setting up your Ubuntu firewall (UFW), you must specifically allow traffic on this UDP port, or the connection requests will be blocked before they reach the VPN software. Troubleshooting WireGuard is usually straightforward because there are fewer moving parts. If you cannot connect, you should follow this specific sequence of checks: First, check the handshake status by running sudo wg show on your server. If the connection is healthy, you will see a line saying latest handshake followed by a time (e.g., “1 minute ago”). If this line is missing, the devices are not talking to each other at all. This is almost always caused by a firewall blocking the UDP port or a mismatch in the Public/Private keys. Second, if the handshake is working but you cannot browse the internet, the issue is likely IP forwarding. You need to ensure your Ubuntu server is allowed to route traffic from the VPN to the internet. You can verify this by looking at the file /etc/sysctl.conf and ensuring the line net.ipv4.ip_forward=1 is active (not commented out). Yes, WireGuard has excellent support for IPv6. It is very flexible and can encapsulate (wrap) different types of traffic. For example, you can access an IPv4-only website through an IPv6 connection, or vice versa. To enable this, you simply need to include comma-separated IPv6 addresses in your configuration file alongside your standard IPv4 addresses. You would add these to both the Address field (for the server’s own IP) and the AllowedIPs field (for the client IPs). To ensure your VPN turns on automatically whenever you restart your Ubuntu server, you need to use systemd, which is the system manager for Linux. You use the enable command to tell the system to look for your specific configuration file (e.g., wg0) and load it during the startup sequence. This ensures that if your server reboots for an update, your VPN connection will come back online without you needing to manually start it. In this tutorial, you set up a WireGuard VPN on an Ubuntu server and connected a peer using both IPv4 and IPv6. Along the way, you configured keys, assigned tunnel addresses, and enabled the server to route traffic securely, giving you a working VPN that is easy to understand and operate. The guide also covered a few practical details that matter once the VPN is in regular use, such as managing keys over time, handling IPv6 and dual-stack networking, and improving reliability and performance with MTU tuning, keepalives, and DNS settings. With these pieces in place, you should be well prepared to run WireGuard in real-world environments or adapt it as your needs change. If you would like to learn more about WireGuard, including how to configure more advanced tunnels, or use WireGuard with containers, visit the official WireGuard documentation. For more tutorials related to securing your Ubuntu systems, check out the following articles: Thanks for learning with the DigitalOcean Community. Check out our offerings for compute, storage, networking, and managed databases. Learn more about our products With over 6 years of experience in tech publishing, Mani has edited and published more than 75 books covering a wide range of data science topics. Known for his strong attention to detail and technical knowledge, Mani specializes in creating clear, concise, and easy-to-understand content tailored for developers. This textbox defaults to using Markdown to format your answer. You can type !ref in this text area to quickly search our full set of tutorials, documentation & marketplace offerings and insert the link! Hi there, I have followed this instruction step by step, a few times over and over now and getting this error: beck@VPN-NL:~$ sudo systemctl start [email protected]
Job for [email protected] failed because the control process exited with error code.
See “systemctl status [email protected]” and “journalctl -xe” for details.
beck@VPN-NL:~$ sudo systemctl start [email protected]
Job for [email protected] failed because the control process exited with error code.
See “systemctl status [email protected]” and “journalctl -xe” for details.
beck@VPN-NL:~$ sudo systemctl status [email protected]
● [email protected] - WireGuard via wg-quick(8) for wg0
Loaded: loaded (/lib/systemd/system/[email protected]; enabled; vendor preset: enabled)
Active: failed (Result: exit-code) since Sun 2021-10-24 11:22:56 UTC; 7s ago
Docs: man:wg-quick(8)
man:wg(8)
https://www.wireguard.com/
https://www.wireguard.com/quickstart/
https://git.zx2c4.com/wireguard-tools/about/src/man/wg-quick.8
https://git.zx2c4.com/wireguard-tools/about/src/man/wg.8
Process: 25546 ExecStart=/usr/bin/wg-quick up wg0 (code=exited, status=1/FAILURE)
Main PID: 25546 (code=exited, status=1/FAILURE) Oct 24 11:22:56 VPN-NL systemd[1]: Starting WireGuard via wg-quick(8) for wg0…
Oct 24 11:22:56 VPN-NL wg-quick[25546]: [#] ip link add wg0 type wireguard
Oct 24 11:22:56 VPN-NL wg-quick[25546]: [#] wg setconf wg0 /dev/fd/63
Oct 24 11:22:56 VPN-NL wg-quick[25566]: Line unrecognized: `…’
Oct 24 11:22:56 VPN-NL wg-quick[25566]: Configuration parsing error
Oct 24 11:22:56 VPN-NL wg-quick[25546]: [#] ip link delete dev wg0
Oct 24 11:22:56 VPN-NL systemd[1]: [email protected]: Main process exited, code=exited, status=1/FAILURE
Oct 24 11:22:56 VPN-NL systemd[1]: [email protected]: Failed with result ‘exit-code’.
Oct 24 11:22:56 VPN-NL systemd[1]: Failed to start WireGuard via wg-quick(8) for wg0.
beck@VPN-NL:~$ systemctl status [email protected]
● [email protected] - WireGuard via wg-quick(8) for wg0
Loaded: loaded (/lib/systemd/system/[email protected]; enabled; vendor preset: enabled)
Active: failed (Result: exit-code) since Sun 2021-10-24 11:22:56 UTC; 25s ago
Docs: man:wg-quick(8)
man:wg(8)
https://www.wireguard.com/
https://www.wireguard.com/quickstart/
https://git.zx2c4.com/wireguard-tools/about/src/man/wg-quick.8
https://git.zx2c4.com/wireguard-tools/about/src/man/wg.8
Process: 25546 ExecStart=/usr/bin/wg-quick up wg0 (code=exited, status=1/FAILURE)
Main PID: 25546 (code=exited, status=1/FAILURE) I am trying to install this on a fresh Droplet. i follow the steps line by line, i enable ip forwarding using sysctl for both ipv4 and ipv6 and finally my result configs for server is : but it won’t work. i tried many times, check systemctl for service running and yes it’s runnig very good. i used tcpdump -i wg0 but sadly it’s not received any traffik. my client logged error is : from somebody that is thoroughly unfamiliar with iptables. I followed this article and it worked perfectly, except for one question My WG clients connect to the server that has forwarding set and access to the internet works perfectly. However, the WG clients would like access to other WG clients and ping times out. It seems the server setting below hints to my issue. The first line seems to indicate that ALL traffic coming in on wg0 should go out eth0 (internet in my case). However, what about incoming traffic on wg0 with a destination of 10.8.0.1/24 network (essentially the WG subnet). Is it forwarding those destination addresses to eth0? If that is the issue, how to i exclude incoming wg0 traffic destined for 10.8.0.1/24 to remain and forward appropriately? PostUp = ufw route allow in on wg0 out on eth0
PostUp = iptables -t nat -I POSTROUTING -o eth0 -j MASQUERADE
PostUp = ip6tables -t nat -I POSTROUTING -o eth0 -j MASQUERADE
PreDown = ufw route delete allow in on wg0 out on eth0
PreDown = iptables -t nat -D POSTROUTING -o eth0 -j MASQUERADE
PreDown = ip6tables -t nat -D POSTROUTING -o eth0 -j MASQUERADE The two steps with umask 077 should be run by root, otherwise sudo tee doesn’t use that mask. Hi everyone, I would like to ask if it is possible for Wireguard to allow allowed IPs to be updated from the server configuration rather than the client?
Thank you in advance for your answer! @jamonation Hello… in step 1 is the file path in sudo chmod go= /tmp/private.key a typo? I presume I need to chmod the file key created in /etc/wireguard/? Thank you. I have a question about enabling compression in WireGuard. How can I configure and enable zstd compression in WireGuard tunnel? I would appreciate your help. Hello, i’m stuck at Step 6 because everytime I do
“sudo systemctl start [email protected]” but it would show this error
“root@theboyzrighthere:~# sudo systemctl start [email protected]
Job for [email protected] failed because the control process exited with error code.
See “systemctl status [email protected]” and “journalctl -xe” for details.” and i tried doing
“sudo systemctl status [email protected]” and it says this
“● [email protected] - WireGuard via wg-quick(8) for wg0
Loaded: loaded (/lib/systemd/system/[email protected]; enabled; vendor preset: enabled)
Active: failed (Result: exit-code) since Sat 2022-02-26 15:37:53 UTC; 1min 13s ago
Docs: man:wg-quick(8)
man:wg(8)
https://www.wireguard.com/
https://www.wireguard.com/quickstart/
https://git.zx2c4.com/wireguard-tools/about/src/man/wg-quick.8
https://git.zx2c4.com/wireguard-tools/about/src/man/wg.8
Process: 5640 ExecStart=/usr/bin/wg-quick up wg0 (code=exited, status=1/FAILURE)
Main PID: 5640 (code=exited, status=1/FAILURE)” this is from a freshly deployed ubuntu 20.04 droplet, i’ve followed everything step by step but it shows that error Hello, how to solve this error and iptables? root@vpsdigital:/etc/wireguard# wg-quick up wg0
[#] ip link add wg0 type wireguard
[#] wg setconf wg0 /dev/fd/63
Warning: AllowedIP has nonzero host part: 10.0.0.2/24
Warning: AllowedIP has nonzero host part: fd4e:c8df:0af4::2/64
Line unrecognized: `PostUp=iptables-tnat-IPOSTROUTING-oeth0-jMASQUERADE’
Configuration parsing error
[#] ip link delete dev wg0
root@vpsdigital:/etc/wireguard# Hello, I tried several times now and I always get the same error. Anybody an idea? I am a complete banana in this and dont understand much. Any help very much appreciated. lines 1-22/22 (END)…skipping…
× [email protected] - WireGuard via wg-quick(8) for wg0
Loaded: loaded (/lib/systemd/system/[email protected]; enabled; preset: enabled)
Active: failed (Result: exit-code) since Sun 2022-11-06 22:36:52 UTC; 18s ago
Docs: man:wg-quick(8)
man:wg(8)
https://www.wireguard.com/
https://www.wireguard.com/quickstart/
https://git.zx2c4.com/wireguard-tools/about/src/man/wg-quick.8
https://git.zx2c4.com/wireguard-tools/about/src/man/wg.8
Process: 2435 ExecStart=/usr/bin/wg-quick up wg0 (code=exited, status=1/FAILURE)
Main PID: 2435 (code=exited, status=1/FAILURE)
CPU: 18ms Nov 06 22:36:52 climbingcervino systemd[1]: Starting WireGuard via wg-quick(8) for wg0…
Nov 06 22:36:52 climbingcervino wg-quick[2435]: [#] ip link add wg0 type wireguard
Nov 06 22:36:52 climbingcervino wg-quick[2435]: [#] wg setconf wg0 /dev/fd/63
Nov 06 22:36:52 climbingcervino wg-quick[2457]: Line unrecognized: `/etc/wireguard/wg0.conf’
Nov 06 22:36:52 climbingcervino wg-quick[2457]: Configuration parsing error
Nov 06 22:36:52 climbingcervino wg-quick[2435]: [#] ip link delete dev wg0
Nov 06 22:36:52 climbingcervino systemd[1]: [email protected]: Main process exited, code=exited, status=1/FAILURE
Nov 06 22:36:52 climbingcervino systemd[1]: [email protected]: Failed with result ‘exit-code’.
Nov 06 22:36:52 climbingcervino systemd[1]: Failed to start WireGuard via wg-quick(8) for wg0.
~
~
~
~ Please complete your information! Get paid to write technical tutorials and select a tech-focused charity to receive a matching donation. Full documentation for every DigitalOcean product. The Wave has everything you need to know about building a business, from raising funding to marketing your product. Stay up to date by signing up for DigitalOcean’s Infrastructure as a Newsletter. New accounts only. By submitting your email you agree to our Privacy Policy Scale up as you grow — whether you're running one virtual machine or ten thousand. Sign up and get $200 in credit for your first 60 days with DigitalOcean.* *This promotional offer applies to new accounts only.