WireGuard Point to Site Configuration

Install WireGuard on both Endpoint A and Host β by following the installation instructions for the appropriate platform on the WireGuard Installation page. You can verify that you’ve installed WireGuard successfully by running wg help on both hosts.

Next, generate two WireGuard keys, one for Endpoint A, and one for Host β. A WireGuard key (also known as a “key pair”) is composed of two parts, the “private key” (also known as the “secret key”), and the “public key”. The magic of this kind of crypto (known as “public-key cryptography”) is that it’s trivial to compute the public key if you know the private key, but practically impossible to compute the private key if all you know is the public key.

While you don’t have to generate the keys on the hosts, generating a host’s key on the host itself often is the best way to keep its private key secure — that way the private key never leaves the host. If you generate your keys outside of the host, be very careful with the private keys, as WireGuard’s security depends entirely on keeping the private keys a secret.

Run the following commands to generate a new key pair for Endpoint A:

And similar commands to generate a new key pair for Host β:

This will generate four files: endpoint-a.key, endpoint-a.pub, host-b.key, and host-b.pub. The *.key files contain the private keys, and the *.pub files contain the public keys. The content of each will be 44 characters of Base64-encoded text:

You don’t actually need to keep these files around — the content of each will be used in the WireGuard configuration files we build for Endpoint A and Host β in the next sections. The private key for a host goes in the host’s own configuration file; and its public key goes in the configuration file of every other host you want to connect it to. Each end of a connection must be pre-configured with the other end’s public key in order for WireGuard to establish the connection.

Now let’s configure Endpoint A (the “client” side of the connection). On Endpoint A, create a new file at /etc/wireguard/wg0.conf with the following content:

Set the file’s owner to root, and its permissions to 600 (owner can read+write; everyone else is denied access — the file contains the endpoint’s private key, which must be kept secret).

Let’s go through the configuration, setting-by-setting:

Now let’s configure Host β (the “server” side of the connection). On Host β, create a new file at /etc/wireguard/wg0.conf with the following content:

Set the file’s owner to root, and its permissions to 600 (owner can read+write; everyone else is denied access — the file contains the host’s private key, which must be kept secret).

Let’s go through the configuration, setting-by-setting:

You will notice that we omitted the Peer.Endpoint setting from Host β’s configuration file that we used in Endpoint A’s configuration file. In this scenario, because Endpoint A initiates all connections to Site B (like when the end user makes HTTP requests from Endpoint A to Endpoint B), Host β doesn’t need to know how to initiate a connection to Endpoint A — and so it doesn’t need a pre-configured value for Peer.Endpoint.

If Host β is already set up as the Internet gateway for Site B (or the gateway for Site B to a subnet that includes the WireGuard VPN we’re setting up — in this example, just 10.0.0.1/32), you don’t need to do anything extra for WireGuard; just skip on to the next section.

Otherwise, we need to configure Host β to route packets from Endpoint A to Endpoint B (and back). When a packet sent from Endpoint A destined for Endpoint B comes through the WireGuard tunnel we’ve configured between Endpoint A and Host β, and into the wg0 interface on the Host β end, its source address will be 10.0.0.1, and its source port will be an ephemeral port chosen by Endpoint A, like 49999; and its destination address will be 192.168.200.22, and destination port 80.

The destination address and port are good the way they are — Host β just needs to be configured to allow it to forward packets like this on to other hosts. But the source address is a problem — Endpoint B won’t know how to send packets back to Endpoint A at 10.0.0.1. So we need to use SNAT (Source Network Address Translation) on Host β to re-write the packet’s source address to use Host β’s own address on the Site B LAN (192.168.200.2). Endpoint B will know how to send packets back to this address (and Host β will know to forward those packets back to Endpoint A — with SNAT it will re-write the source port of the original packets, 49999 in this example, to some other ephemeral port that it will remember is associated with Endpoint A, like 50123).

So, assuming Host β is a Linux host, we need to configure 2 things on it:

IP masquerading is just a simplified form of SNAT, where iptables automatically chooses the source address to re-write packets to (which in our scenario will always be 192.168.200.2). If you don’t already have iptables installed on Host β (try running sudo iptables -L to check), install it now.

While you can also use other services to do this, the most expedient way for us to turn on IP forwarding and IP masquerading is to have the wg-quick service do it when we bring the WireGuard interface up. To do it this way, update the /etc/wireguard/wg0.conf file on Host β to add several Interface.PreUp and Interface.PostDown settings like the following:

If you’re using IPv6 addresses for your WireGuard VPN, use these settings instead:

The first PreUp setting turns on IP forwarding. Note that IP forwarding is a potentially dangerous setting to turn on if you don’t have appropriate firewall rules in place in front of the host (or as part of the host’s own firewall) — with it on, the host will blindly try to forward on any packets it receives that are destined for other hosts (allowing a malicious actor with network access to the host to access any other hosts that the host itself can access).

The second PreUp setting adds an iptables rule to mark all packets emerging from the wg0 interface with a value of 0x30. The third PreUp setting adds an iptables rule to apply IP masquerading to all packets with this 0x30 mark before they’re forwarded off to their destination (as long as that destination is not back out through the wg0 interface again). Note that 0x30 is an arbitrarily-chosen value, meaning nothing to anyone other than these two iptables rules — any other value would work just as well.

The two PostDown settings delete the iptables rules added by the PreUp settings. The PostDown iptables settings should match the corresponding PreUp settings exactly, except the PostDown ones use the -D (delete) flag instead of the -A (append) flag.

On both Endpoint A and Host β, start the wg-quick service. On Linux with systemd, run the following commands:

On systems without systemd, run this command instead:

Either way, starting up the wg-quick service will set up a WireGuard network interface named wg0 on the host, and configure some routing rules to route packets destined for any IP address listed in the Peer.AllowedIPs setting(s) of the /etc/wireguard/wg0.conf file to go out the wg0 interface.

Note that the name wg0 is just the standard convention for your first WireGuard interface. You can create as many WireGuard interfaces as you like, and name them however you like. For example, you could create another configuration file named /etc/wireguard/mytunnel.conf, and start it up with the command wg-quick up /etc/wireguard/mytunnel.conf; this would create a new WireGuard interface named mytunnel.

But for now, if you ran wg-quick up directly, you’ll see output like the following:

This output shows the routing rules that wg-quick set up for you automatically.

If you ran systemctl start instead, you can see the same output by running the journalctl tool, like so:

On Endpoint B, start up a webserver on port 80 (or any other port, like 8080). If you don’t have a webserver handy, a dead-simple substitute is to use the http.server module of Python 3, like the following, running as root to listen on port 80:

Or run it as a regular user to listen on any port above 1023 (like port 8080):

The http.server module will serve the directory listing of and files in your current directory. A somewhat safer version of this is to create an empty directory in your current directory, and serve that instead:

On Endpoint A, use curl (or a regular webrowser) to request a page from the webserver running on Endpoint B port 80:

Or if the webserver is running on port 8080 (or some other port), specify that port explicitly:

If you see any HTML output from this, your WireGuard tunnel works!

If curl hangs, or you see an error like like Connection refused or No route to host, you may have neglected to turn on IP forwarding for Host β. Run this command on Host β to double check:

Or, if you’re using IPv6 addresses, run the IPv6 variant:

If the result is 0, you need to turn on IP forwarding (see the Configure Routing on Host B section above). If the result is 1, IP forwarding is on.

The next thing to check is to make sure Host β is performing IP masquerading for Endpoint A. Run this command on Host β to list out all your iptables tables rules:

If you don’t have any iptables rules in place, the result will be blank. What you should see instead is something like this:

If you set up IP masquerading like the Configure Routing on Host B section above suggested, you should have this rule under the *mangle table:

And this rule under the *nat table:

If you don’t have a rule with a MASQUERADE or SNAT target under your *nat table, Endpoint B isn’t going to be able to send packets back to Endpoint A. Try following the Configure Routing on Host B section above to set up IP masquerading.

The numbers in brackets (like [123:12345]) are the packet and byte count processed by each rule. If you see [0:0] for the -j MAQUERADE rule, it means no packets have matched it (ie no packets have been marked with 0x30 and forwarded directly out of one of the host’s physical network interfaces). And if you see [0:0] for the -j MARK rule, it means no packets have come in the host’s wg0 interface.

If no packets have come in the host’s wg0 interface, you likely have some other firewall rules or network configuration blocking the WireGuard tunnel itself from being set up. Try running sudo wg on both Endpoint A and Host β, to see if the WireGuard interface on both is up and configured as you expect.

On Host β, you’ll probably see output like this:

If Endpoint A had successfully connected, this display would include a “latest handshake” field for the peer, as well as a “transfer” field indicating some data had been received. The above output indicates that Endpoint A has not successfully connected yet.

On Endpoint A, you’ll probably see output like this:

If the “transfer” field indicates some data has been sent to Host β, but none has been received (as it does above), it likely means packets are being blocked or misdirected somewhere between Endpoint A and Host β. If this is the case for you, you need to fiddle with your firewalls or other network configuration until they allow Endpoint A to send UDP packets to Host β via the IP address and port configured in Endpoint A’s Peer.Endpoint setting (in this example, it’s 203.0.113.2:51822).

If you already have some basic firewall rules set up on Host β itself, you don’t need to do anything else to your WireGuard configuration. You may want to add additional rules to your firewall specifically for restricting the forwarding of WireGuard traffic, but you don’t have to.

If you don’t already have some basic rules in place, here are a few simple iptables rules that you can use to reject unexpected WireGuard traffic from accessing local sockets on Host β itself, and to reject any WireGuard traffic from being forwarded to an unexpected destination.

First, bring down the WireGuard interface on Host β with wg-quick or systemctl:

Then edit the /etc/wireguard/wg0.conf file to add several new Interface.PreUp and Interface.PostDown settings, like the following:

Then bring the interface back up again with wg-quick or systemctl:

This updated configuration will cause wg-quick on Host β to add five new iptables rules before it brings up the WireGuard interface, and remove the same rules after it brings the interface down.

The first two rules (added to the INPUT chain) apply to traffic destined for Host β itself:

The first rule will accept all packets for already-established connections (ie connections that Host β initiated) coming through the WireGuard tunnel; and the second rule will reject anything else coming through the tunnel destined for Host β.

The last three rules (added to the FORWARD chain) apply to traffic forwarded from Endpoint A to Site B:

Similar to the rules for the INPUT chain, the first and third of the rules for the FORWARD chain allow already-established connections, but reject new connections.

The second rule, however, will allow new TCP connections to be forwarded to port 80 of Endpoint B (192.168.200.22 in Site B). If you want to allow access to a different port of Endpoint B other than port 80 (like 8080), specify that port instead of 80. If you want to allow access to multiple ports of Endpoint B, adjust the rule slightly to use the multiport match directive with the --dports flag (note the trailing s in --dports) — like, for example, to allow both port 80 and 443:

Whenever you make changes to these rules, make sure you make the exact same change to both the PreUp setting and its corresponding PostDown setting (the PreUp and PostDown rules should be the same, just with a -A flag for PreUp and -D flag for PostDown). And if you use IPv6 addresses in your WireGuard VPN, substitute the ip6tables command for iptables in everything above.

Also note that when you’re fiddling with PreUp and PostDown settings, it’s best to bring the interface down first, make your configuration changes, and then bring the interface back up again (rather than making the configuration changes while the interface is still up, and then trying to restart afterward). The reason is that most of the time, your “Up” and “Down” settings are meant to be symmetrical (like start up a service with PreUp and shut it down with PostDown, or add a firewall rule with PreUp and remove it with PostDown) — so if you change a PostDown rule while your WireGuard interface is still running, you might inadvertently leave a stray service running or firewall rule in place from the previous configuration version (which you’ll have to track down and clean up manually).

For tips on how to set up an iptables firewall under a more complicated point-to-site scenario, check out the “Point to Site” section of the WireGuard Access Control With Iptables guide.

To use UFW to set up a firewall similar to the firewall described in this article, see the “Point to Site” section of the How to Use WireGuard with UFW guide; to use firewalld, see the “Point to Site” section of the How to Use WireGuard with Firewalld guide; or to use nftables, see the “Point to Site” section of the How to Use WireGuard With Nftables guide.