iTechGuides is reader-supported. When you buy through links on our site, we may earn an affiliate commission. As an Amazon Associate I earn from qualifying purchases. Learn more
To install a WireGuard VPN server on Ubuntu, install the wireguard package, create separate keys for the server and each peer, configure /etc/wireguard/wg0.conf, then bring up the interface with wg-quick. If clients should reach the internet through the server, you must also enable IPv4 forwarding and configure source NAT on the server’s actual outbound interface. A tunnel that is merely up does not prove that traffic can reach its destination.
What should you decide before installing WireGuard?
First choose what the VPN should let a peer reach. WireGuard is best understood as a network interface: its configuration assigns addresses and describes peers, while wg-quick creates the interface and applies its addresses and routes. The routing design determines whether you need forwarding, NAT, proxy ARP, or additional firewall rules.
Choose the traffic destination
- Peer-to-site access: Clients use the tunnel to reach selected private addresses or subnets. Their destination scope is narrower than sending all traffic through the VPN.
- Default-gateway access: Clients send all IPv4 destinations through the tunnel. The server must route that traffic onward; for internet access, it usually needs IPv4 forwarding and source NAT.
- Site-to-site access: Two gateways route traffic between their respective networks. Both sides need peer and route settings appropriate to the networks they connect.
Plan addresses and reachability
Reserve a private tunnel subnet that does not overlap with the LANs used by the server or clients. Assign the server a tunnel address and a distinct address to every peer. Also identify the server’s public UDP listen port and its real outbound network-interface name. The sample subnet and port below are examples, not requirements.
Windows Errors? Fix Them Before They Spread
Repair common Windows errors and clear accumulated junk for a smoother, more stable PC - no reinstall needed.Free scan · no reinstallCrashes, No Sound, or Screen Glitches?
Random freezes, missing sound and display glitches usually trace back to one bad driver. Find and replace yours safely.Free scan · under a minuteAddress planning is important because AllowedIPs is tied to routing. If two connected networks use the same range, the operating system cannot reliably determine whether a packet belongs on the tunnel or the local LAN. Record the server tunnel address, each peer address, remote LAN ranges for a site-to-site design, and the interface that leads to the internet before writing the configuration.
#1 Best Overall
Decide how peers will find one another. A server that needs to initiate toward a peer may need that peer’s fixed endpoint. A client behind changing NAT can commonly initiate the connection instead, so the server does not necessarily need a fixed client endpoint. These choices affect the peer configuration, not the basic installation.
How do you install WireGuard on Ubuntu?
Install the Ubuntu package with APT. The package and tool versions depend on the Ubuntu release, so check the version installed on the target host if you need to confirm a particular feature or behavior.
- Refresh the package index:
sudo apt update - Install WireGuard:
sudo apt install wireguard
These commands install the software; they do not yet create a working VPN or make the Ubuntu host an internet gateway. The interface configuration, peer keys, firewall policy, and routing are separate parts of the setup. Make sure you are working on the Ubuntu system that will own the public UDP listener, and note whether an upstream cloud security group or network firewall also controls that port.
Free tools Windows power users keep installed
One-click scans. No signup required.
How do you generate and protect WireGuard keys?
Create a distinct key pair for the server and for every client or other peer. A peer’s public key is shared with the other side; its private key stays secret on the device that owns it. Never reuse one private key for multiple peers.
- Create the configuration directory and generate the server key pair with restrictive file permissions:
sudo install -d -m 700 /etc/wireguard cd /etc/wireguard sudo sh -c 'umask 077; wg genkey > server.key; wg pubkey < server.key > server.pub' - Keep
server.keyprivate. Read or transferserver.pubas needed to configure the client peer; do not distribute the server private key. - Repeat key generation for each peer, using a separate private/public pair for each. Store each private key only where that peer’s configuration needs it.
umask 077 limits access to files created by the key-generation command. Protect the configuration and key files after creating them as well; the following permission command is used after the server configuration is in place. A copied public key is safe to place in the opposite side’s peer section, but a private key should never be pasted into a peer’s PublicKey field or sent through an untrusted channel.
How do you configure wg0.conf?
Create /etc/wireguard/wg0.conf with an interface section for the Ubuntu server and a peer section for each client. Replace the example key and address values with the real values for your topology.
Rank #2
[Interface]
Address = 10.90.90.1/24
ListenPort = 51820
PrivateKey = <contents of /etc/wireguard/server.key>
[Peer]
PublicKey = <client-public-key>
AllowedIPs = 10.90.90.2/32What each setting does
Addressassigns the server its address on the tunnel interface. Here,10.90.90.1/24is an example from a private tunnel subnet.ListenPortselects the UDP port on which the server listens. The example uses51820; make sure the host and any cloud firewall allow the chosen port.PrivateKeyauthenticates the server interface. Use the contents of the server’s private-key file and keep that key secret.PublicKeyidentifies the peer to the server. Use that peer’s public key, not its private key.AllowedIPsspecifies addresses routed to that peer and accepted from it. For the sample peer,10.90.90.2/32identifies its individual tunnel address. If the peer should route additional destinations, the address scope must reflect that design.
Add an [Peer] section for every additional client or gateway, with its own public key and appropriate AllowedIPs. A client peer normally has one unique tunnel address, while a gateway peer may represent one or more remote network ranges. Do not assign the same tunnel address or overlapping peer ranges to two peers.
Add Endpoint = <host>:<port> when the server needs a fixed destination for that peer. For a client behind changing NAT that initiates the connection, a fixed client endpoint is commonly unnecessary. The server still needs its own reachable public address or hostname and UDP listen port for clients to contact it.
What belongs on a client?
The client also has an interface section containing its own private key and tunnel address, plus a peer section containing the Ubuntu server’s public key. Its AllowedIPs expresses the destinations it should send through the tunnel: a private site subnet for peer-to-site access, or 0.0.0.0/0 when it is intended to use the VPN as the default IPv4 gateway. The server’s peer entry, in turn, normally contains that client’s single tunnel address.
Protect the configuration
Once the file exists, restrict access to the configuration and private-key files:
sudo chmod 600 /etc/wireguard/wg0.conf /etc/wireguard/*.keyCheck that the private key in the interface configuration belongs to this server and that the peer public key is the matching peer’s key. Key mismatches or a copied private key in place of a public key prevent the intended peer relationship. Keep a written inventory of which public key belongs to each device so that adding or revoking a peer does not require guessing.
The Tool Desk
Outbyte Driver Updater FREEFix the driver behind crashes, sound loss and screen glitchesFind Drivers →Outbyte PC Repair FREERepair Windows errors before they cause bigger problemsFix Now →How do you route client internet traffic through the Ubuntu server?
A WireGuard tunnel by itself does not turn the Ubuntu host into a gateway. For clients to reach the internet through it, enable IPv4 forwarding and add a source-NAT rule that uses the server’s actual outbound interface. The interface name shown below as eth0 is only an example; substitute the name on your host.
Enable IPv4 forwarding
- Create
/etc/sysctl.d/70-wireguard-routing.confcontaining:net.ipv4.ip_forward = 1 - Apply the setting:
sudo sysctl -p /etc/sysctl.d/70-wireguard-routing.conf -w
Forwarding is a kernel function separate from WireGuard encryption. Without it, the Ubuntu host may answer its own tunnel address while dropping or refusing to route packets between wg0 and the external interface.
Add source NAT for the tunnel subnet
For the example tunnel subnet, add a MASQUERADE rule on the outbound interface:
sudo iptables -t nat -A POSTROUTING -s 10.90.90.0/24 -o eth0 -j MASQUERADEReplace 10.90.90.0/24 if your tunnel subnet differs and replace eth0 with the interface that carries traffic toward the internet. The rule translates packets from the tunnel subnet as they leave that interface. Make the rule persistent using the firewall-management method chosen for the host; do not assume that /etc/rc.local exists on every Ubuntu installation. A reboot test is important because a rule that works only in the current firewall state will disappear unless your selected firewall system restores it.
Quick wins for a faster PC:
Repair Windows errors before they cause bigger problemsFix Now →Scan for outdated or missing drivers - takes under a minuteDriver Scan →On the client, sending all IPv4 traffic through the VPN requires an AllowedIPs value of 0.0.0.0/0. That setting changes the client’s destination routing, but it does not create forwarding or NAT on the server. Both halves are required: the client must select the tunnel, and the server must route and translate the traffic onward.
For a private-LAN design, do not automatically apply internet NAT as a substitute for routing. A routed LAN may need an explicit route back to the tunnel subnet on the LAN side. Ubuntu also documents proxy ARP for an internal-system design: alongside forwarding, that setup can require net.ipv4.conf.all.proxy_arp = 1. The right choice depends on the topology and return path. NAT can hide the original tunnel source, while a routed design preserves it and therefore requires the LAN to know how to return traffic.
How do you start and test the VPN interface?
Start the interface with wg-quick, inspect the resulting WireGuard state and operating-system routes, then test from a client to the destination the VPN is meant to provide.
Rank #4
- Bring up the interface:
sudo wg-quick up wg0 - Inspect WireGuard interfaces and peers:
sudo wg show - Confirm that the tunnel interface has an address:
ip address show dev wg0 - Inspect the host’s routes:
ip route - From the client, test the server’s tunnel address first, then test the intended LAN host or internet destination. For routed setups, a successful test to the VPN server alone is not proof that traffic can reach beyond it.
wg-quick creates the interface, applies its address and routes, and loads WireGuard settings. wg show helps distinguish interface and peer state from the separate question of whether end-to-end routing works. When checking a failure, note whether the peer appears in wg show, whether a recent handshake is present, and whether the client’s route table sends the test destination to the tunnel.
Recommended Free Tools
How do you make WireGuard start after reboot?
Enable and start the systemd unit for the named interface:
sudo systemctl enable --now wg-quick@wg0The command starts wg0 immediately and enables it to start at boot. Use the configuration’s interface name in the unit: for example, a different configuration name requires a correspondingly different unit instance. After a reboot, verify the service and test client traffic again rather than relying only on the fact that the unit is enabled. If the service fails during boot, inspect its status and the configuration permissions before changing routing rules.
Which WireGuard routing design fits your use?
The main configuration decision is how much traffic should use the tunnel, how the server will route it onward, and which peer can be reached at a known endpoint.
| Design | Destination scope | Server routing responsibility | Peer reachability |
|---|---|---|---|
| Peer-to-site | Selected private addresses or subnets in AllowedIPs. |
Route to the intended LAN; arrange a return route or the appropriate internal-network behavior. | A peer may initiate from behind changing NAT; configure a fixed endpoint when the server must initiate to a peer at a known address. |
| Default gateway | All IPv4 destinations, represented by 0.0.0.0/0 on the client side. |
Forward client traffic and, for internet egress, apply source NAT on the real outbound interface; firewall policy must permit the traffic. | The server must be reachable on its public UDP port. Ubuntu’s guidance recommends a system reachable on the internet and controlled by the operator for this pattern. |
| Site-to-site | The remote site’s network ranges, rather than only an individual client address. | Route between the connected networks and ensure return paths exist at both sites. | Each gateway needs a peer configuration appropriate to its counterpart and the networks being routed. |
AllowedIPs is not just a peer label: it determines which destinations are associated with a peer and which source addresses are accepted from it. On a server, each client normally has its own tunnel address in its peer entry. On a client, the allowed destination range must match the traffic the client is meant to send through the tunnel. A private subnet scope and 0.0.0.0/0 therefore describe different routing intentions, not interchangeable ways to write the same setup.
What should you check when WireGuard does not work?
Diagnose the failure at the point where it occurs: configuration and interface startup, peer handshake, or routing beyond the VPN endpoint. An interface reported as up proves only that it was created, not that the intended destination is reachable.
wg-quick up wg0 fails
- Check the syntax and section names in
/etc/wireguard/wg0.conf, including that key values are complete and the interface name matches the filename. - Check access permissions on the configuration and private-key files.
- Confirm that the selected UDP listen port is allowed by the Ubuntu host firewall and any cloud firewall.
- Inspect the reported error and correct the configuration before retrying.
No handshake appears
- Verify that each side has the other side’s correct public key. A peer needs the other peer’s public key; private keys must remain private.
- Check the endpoint host and UDP port, and confirm that the server is reachable through the relevant firewall rules.
- Confirm that
AllowedIPsincludes the intended peer tunnel address and, where needed, the routed destination ranges. - Check whether the peer behind NAT is the side expected to initiate the connection, or whether the server has a usable fixed endpoint for a peer it must reach.
Handshake works, but internet traffic does not
- Confirm IPv4 forwarding is enabled on the Ubuntu host.
- Check that the MASQUERADE rule uses the real outbound interface and the correct tunnel subnet.
- Check the return route and firewall policy, including any host or cloud firewall that may block forwarded traffic.
- Verify that the client uses the intended destination scope, such as
0.0.0.0/0for a full-tunnel design. - Test from the client to a destination beyond the VPN server; a handshake does not establish that forwarded traffic is working.
The peer reaches the server but not another LAN host
- Check that the LAN has a return route to the VPN tunnel subnet. Without a return path, requests may arrive but replies may not get back to the peer.
- For an internal-system deployment, check whether the topology requires proxy ARP or explicit routes.
- Test against a LAN destination beyond the WireGuard host, not only the host’s tunnel address.
- Ensure the destination range is assigned to the correct gateway peer and does not overlap another peer’s
AllowedIPs.
The interface works until reboot
- Confirm that
systemctl enable --now wg-quick@wg0was run for the actual interface name. - Check that the configuration remains at
/etc/wireguard/wg0.confwith restrictive permissions. - Verify that your firewall or NAT management method restores the MASQUERADE rule after startup; an interactive rule added with
iptablesmay not be persistent by itself.
Frequently Asked Questions
Can I use one WireGuard key pair for several Ubuntu clients?
Use a separate key pair for every peer instead. A unique public key lets the server identify each peer independently, and keeping each private key on its own device limits the impact if one device’s key is exposed.
Does a WireGuard handshake mean my VPN is routing correctly?
No. A handshake indicates the peers have established WireGuard communication, but traffic can still fail because of missing forwarding, an incorrect NAT interface, firewall policy, or a missing return route. Test the actual LAN or internet destination the client needs.
Can I use WireGuard on a private Ubuntu server with no public address?
A peer must be able to reach the listening server through the network path and UDP port you configure. If the server is not publicly reachable, the available network topology must provide another route to it; the configuration alone cannot make an unreachable endpoint reachable.
What should I put in AllowedIPs for a full-tunnel client?
Use 0.0.0.0/0 when all IPv4 destinations should go through the VPN. For peer-to-site access, use only the private subnet or addresses that belong across the tunnel. The server still needs forwarding and, for internet egress, source NAT.
Do I need proxy ARP for every WireGuard installation?
No. Proxy ARP is associated with an internal-system or routed-LAN design documented by Ubuntu. A default-gateway internet design generally relies on forwarding and source NAT, while a routed LAN may instead use explicit return routes or proxy ARP according to its topology.
Why can the client reach the Ubuntu server but not the internet?
Reaching the tunnel address proves only the WireGuard path to the server. Check IPv4 forwarding, the MASQUERADE rule’s source subnet and outbound interface, host or cloud firewall policy, the client’s destination scope, and the return path. Then test a destination beyond the VPN endpoint.
How many configuration files do I need for multiple clients?
The Ubuntu server can keep one interface configuration with one [Peer] section per client. Each client has its own key pair, tunnel address, and peer settings. Keep every private key on only the device that owns it and avoid overlapping peer address ranges.
Do these 3 things before closing this tab:
1Repair Windows errors before they cause bigger problems2Scan for outdated or missing drivers - takes under a minute3Clear out junk files and repair common Windows errorsThe Bottom Line
Install the Ubuntu package, create a unique key pair for the server and every peer, and build /etc/wireguard/wg0.conf around a non-overlapping tunnel subnet. Use wg-quick and wg show to bring up and inspect the interface, then test traffic beyond the VPN host. If clients need internet access, enable IPv4 forwarding, apply MASQUERADE on the real outbound interface, permit the UDP listener through every relevant firewall, and persist both the service and firewall configuration for reboots.
Quick Recap
Product prices and availability are accurate as of the date/time indicated and are subject to change. Any price and availability information displayed on Amazon at the time of purchase will apply.
