Wireguard setup for Ubuntu server with LAN access

readme.md

Wireguard setup for LAN access

Assumptions

• The network 192.168.1.0/24 is your LAN
• Your Ubuntu server is on your LAN at 192.168.1.10, through the network interface eth0
• The network 192.168.5.0/24 is non existent
• Your LAN DNS is at 192.168.1.1

Server installation

1. Ensure IPv4 forwarding is enabled

   sysctl -w net.ipv4.ip_forward=1

2. You might need to allow the VPN server port UDP 51820:

   sudo ufw allow 51820/udp
   sudo ufw enable

3. Install Wireguard Kernel modules and CLI tools

   sudo add-apt-repository ppa:wireguard/wireguard
   sudo apt-get update
   sudo apt-get install -y wireguard

4. Create the VPN interface configuration file

   sudo nano /etc/wireguard/wg0.conf

   with the following content

   [Interface]
   Address = 192.168.5.1
   ListenPort = 51820
   PrivateKey = <server private key>
   PostUp = iptables -A FORWARD -i %i -j ACCEPT; iptables -A FORWARD -o %i -j ACCEPT; iptables -t nat -A POSTROUTING -o eth0 -j MASQUERADE
   PostDown = iptables -D FORWARD -i %i -j ACCEPT; iptables -D FORWARD -o %i -j ACCEPT; iptables -t nat -D POSTROUTING -o eth0 -j MASQUERADE
   
   [Peer]
   # Your first client
   PublicKey = <client 1 public key>
   AllowedIPs = 192.168.5.2/32
   
   # [Peer]
   # Your second client
   # PublicKey = <client 2 public key>
   # AllowedIPs = 192.168.5.3/32

5. Generate a keypair on the server

   privateKey=`wg genkey`
   publicKey=`echo "$privateKey" | wg pubkey`
   echo "Private Key: $privateKey"
   echo "Public Key: $publicKey"
   unset -v privateKey

6. Copy the private key into /etc/wireguard/wg0.conf in the [Interface] section, replacing <server privatekey>

7. On your client, generate a key pair (see comment below to know how), and copy the client public key to the server's /etc/wireguard/wg0.conf in the [Peer] section and replace <client 1 public key>.

8. Finally, launch the interface on the server

   wg-quick up wg0

   If it complains about Wireguard not being a type of interface, you can try modprobe wireguard or you will have to reboot your server to load the new Kernel module.

   You can remove the VPN interface with wg-quick down wg0.

9. On your client, use this configuration

   [Interface]
   Address = 192.168.5.2
   PrivateKey = <client 1 auto generated private key>
   DNS = 192.168.1.1
   
   [Peer]
   PublicKey = <server public key>
   AllowedIPs = 0.0.0.0/0
   Endpoint = 192.168.1.10:51820
   PersistentKeepalive = 25

   And replace <server public key> with the public key you generated.

10. You can try now to connect, it should take 3-5 seconds to connect.

11. To access from outside, port forward for example port UDP 443 to 192.168.1.10:51820 and change the client endpoint to :443

Lucky you I made a new Gist that should answer that!

Hi,

I've been trying to setup my VPN as you instructed above so that my remote client (e.g. laptop at coffee shop) can access machines on my home LAN. The Wireguard server is also on the LAN. Currently I'm testing with my laptop at home first. Before connecting to the VPN server, the client is able to ssh into the LAN host using its LAN IP (192.168.0.158), After connecting the client to the VPN server, it's no longer able to ssh into the LAN host at the same IP. In general, it seems I've lost all ability to ping/route traffic to IPs on the original LAN network.

I noticed that if I connected both the host and the client to the VPN server, then the client can ssh the host using the host's VPN IP address, but still not using the LAN IP address.

Some minor differences - I am using a raspberry-pi for the VPN server, and my client and host machines are Windows.

Here's the setup:

LAN subnet is 192.168.0.0/24
LAN DNS is the router, 192.168.0.1

Server config:

[Interface]
PrivateKey = <server_priv_key>
Address = 192.168.5.1
MTU = 1420
ListenPort = 51820
PostUp   = iptables -A FORWARD -i %i -j ACCEPT; iptables -A FORWARD -o %i -j ACCEPT; iptables -t nat -A POSTROUTING -o eth0 -j MASQUERADE
PostDown = iptables -D FORWARD -i %i -j ACCEPT; iptables -D FORWARD -o %i -j ACCEPT; iptables -t nat -D POSTROUTING -o eth0 -j MASQUERADE

# host
[Peer]
PublicKey = <host_public_key>
PresharedKey = <host_preshared_key>
AllowedIPs = 192.168.5.2/32

# client
[Peer]
PublicKey = <client_public_key>
PresharedKey = <client_preshared_key>
AllowedIPs = 192.168.5.3/32

Client config:

[Interface]
PrivateKey = <client_priv_key>
Address = 192.168.5.3/24
DNS = 192.168.0.1
MTU = 1420

[Peer]
PublicKey = <vpn_server_pub_key>
PresharedKey = <client_preshared_key>
AllowedIPs = 0.0.0.0/0, ::/0
Endpoint = <router_public_domain_name>:<public_port>

Host config:

[Interface]
PrivateKey = <host_priv_key>
Address = 192.168.5.2/24
DNS = 192.168.0.1
MTU = 1420

[Peer]
PublicKey = <vpn_server_pub_key>
PresharedKey = <host_preshared_key>
AllowedIPs = 0.0.0.0/0, ::/0
Endpoint = <router_public_domain_name>:<public_port>

Any debugging pointer or folks to talk to would help. Thanks for the resources!

@jonchancode I also have the issue, on my home network and on another network too.

Activating Wireguard from within the same LAN network blocks access to the LAN. If you try from outside your LAN it does work though.

I didn't dig further as that fitted what I wanted and was fine with deactivating Wireguard when inside my LAN.

I'm not sure if this is a firewall iptables issue or a routing issue, or a Wireguard issue. But I would be curious how to solve it as well!

Actually using my Android Wireguard app I don't have the problem, maybe that's a Windows Wireguard client issue (I was using Windows too).

Ah interesting, yeah, looks like it works the same for me too (can access externally, but not internally). I'll post back here if I find an answer. Thanks for the response!

If Wireguard is running on the server change your CLIENT CONFIG from AllowedIPs = 0.0.0.0/0 to AllowedIPs=192.168.0.0/24.
If Wireguard is running in Docker do the same but be aware that: If your Wireguard server is a container on your server, when your clients connect and try to traverse the LAN their traffic will be routed through the Docker network subnet where that container lives... Makes sense now but took digging through UFW logs to find out why I couldn't SSH to my server.

That's right. UFW block network traffic from the docker container, since it comes from a different subnet.