WireGuard Point to Site With Port Forwarding

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 remote web server). 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 local site 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, even though we used it in Endpoint A’s configuration file. In this example, because Endpoint A is configured with Host β’s endpoint address — and to send keepalive packets to Host β every 25 seconds — we don’t need to configure Host β with Endpoint A’s endpoint address. WireGuard will figure out Endpoint A’s address automatically when it receives the first keepalive packet from Endpoint A.

In cases where your remote endpoint has a static IP address — and its firewall allows new connections on its WireGuard port — you can reverse these settings, and include a Peer.Endpoint setting on the site side, while omitting it from the point side. You can also omit the Peer.PersistentKeepalive from either side. If we did that in this example, this is what Endpoint A’s wg0.conf would look like:

And this is what Host β’s wg0.conf file would look like:

Assuming Host β is a Linux host, we need to configure two things on it:

If you don’t have iptables installed on the host, install it now with your package manager (like sudo apt install iptables or sudo yum install iptables etc).

While there are other ways to set these two things up, the simplest way is to add PreUp commands for them in the [Interface] section of our WireGuard config file — wg-quick will execute these for us automatically when it starts the WireGuard interface up (and execute the PostDown commands when it shuts the interface down).

So update the /etc/wireguard/wg0.conf file on Host β to add the following Interface.PreUp and Interface.PostDown settings:

If you’re using IPv6 addresses for your WireGuard VPN, replace net.ipv4.ip_forward with net.ipv6.conf.all.forwarding, and iptables with ip6tables.

The first PreUp setting above makes sure that packet forwarding is turned on (this setting is global for the Linux kernel’s networking subsystem). The second PreUp setting configures iptables to forward packets sent to port 80 on Host β’s LAN address (192.168.200.2) over to port 80 on Endpoint A (10.0.0.1). Because we’re using Endpoint A’s WireGuard address as their new destination, these packets will be forwarded through the WireGuard tunnel between Host β and Endpoint A.

Note that we can forward packets to a different destination port by including the different port in the --to-destination value. For example, if we wanted to forward port 80 on Host β to port 8080 on Endpoint A, we’d do it like this:

The PostDown command deletes the iptables rule when wg-quick brings the interface down. If you change the iptables rule in the PreUp command, make sure you make the corresponding change to the rule in the PostDown command (the two commands should be identical, except the PreUp command uses the -A flag, for --append, whereas the PostDown command uses the -D flag, for --delete).

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 A, if you haven’t already, start up the web server on port 80. On Endpoint B, use curl (or any other browser) to request a page from Endpoint A:

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 packet 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 packet forwarding (see the Configure Routing on Host B section above). If the result is 1, packet forwarding is on.

The next thing to check is to make sure Host β is performing port forwarding 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:

In particular, you should see this rule under the *nat table:

If you don’t have this rule, Host β isn’t going to be able to forward HTTP requests from Endpoint B to Endpoint A. Try following the Configure Routing on Host B section above to set up port forwarding.

The numbers in brackets (like [21:432]) are the packet and byte count processed by each rule. If you see [0:0] for the DNAT rule, it means no packets have matched it. If that’s the case, you likely have some other firewall rules or network configuration blocking packets sent to port 80 on Host β.

Otherwise, 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).

As long as Site B is not configured to use Host β as a gateway, the only traffic that will be routed successfully between Site B and our WireGuard network will be packets sent to and responding from Endpoint A’s port 80. But as an extra security measure, you may want to add some additional firewall rules to Host β to prevent traffic from your WireGuard network from accessing any services on Host β itself (and if you add additional WireGuard peers to Host β’s network, to prevent those peers from connecting to one another through Host β).

Here are a few simple iptables rules that you can use to reject WireGuard traffic from accessing local services on Host β itself, and to reject any forwarded WireGuard traffic from being used to make new connections to anything other than port 80 of Endpoint A. 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:

The first set of the new PreUp firewall commands will prevent any WireGuard peers from connecting directly to services on Host β (and vice versa):

The second set of PreUp firewall commands will prevent Host β from forwarding any connections to and from its WireGuard peers, other than connections related to Endpoint A’s port 80:

For a guide to setting up a more complicated iptables firewall, check out the “Point to Site” section of the WireGuard Access Control With Iptables article.

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