2024-04-01 Home Vpn with wireguard
Safely making your internal network visible from your cafe
Background
After setting up a wireguard router you have several paths that can exist between your laptop and your target server. The process to setup the wireguard-server/client atre twp parts of a 4 part part process. The wireguard client, whilst setup on your laptop, needs some network rules created to ensure the path to the network is discovered and hostnames can be resolved from the appropriate dns.
Requirements
- A Static IP for your home network or
- Dynamic DNS configured (I like https://freedns.afraid.org/zc.php)
- Ensure your wireguard client on your laptop is pointing to the public endpoint
$> sudo wg show wg0
interface: wg0
public key: 34rwefewdjkewrw445dsdssd=
listening port: 51820
peer: 23fe4fgrRTYYJU76445ERRFFSFefefet=
endpoint: {{public_ip|public_host}}:51820
allowed ips: 10.1.100.0/24, 192.168.1.0/24
- Ensure your router is accepting inbound connections to your wireguard server
Wireguard Interface/Zone 
Wireguard Zone paths Egress/Ingress
Additional requirements
There is a previous document that will be written discussing Turris Omnia Wireguard setup. This is my router, and it has built in wireguard compatibility, all you need to do is:
- Add the packages in the administration interface
- Add the wireguard config file as explained on previous posts as if it’s a normal server
- Wireguard interface and zones will automatically detect the wireguard configuration
- Ensure Firewall rule is created for Wireguard Ingress from WAN to WG zone.
If your wireguard-server is a turris, setup is little more than a standard wireguard-server as described previously
Optional
If your wireguard-server is other than your router, add another rule to port foward wireguard traffic through to that internal host (generally port 51820)
Paths to your wireguard server
You can connect to your local proxmox server at least 4 ways:
- External, tethered phone or cafe to internet router - many hops 31.9 < time < 176ms (shown first)
- Local, direct on WIFI without wireguard - Two hops via your router switch <2ms
- Local, WITH wireguard router and LAN/WIFI - Two hops via router and switch <3.52ms (shown 2nd)
- Local, With internal wireguard server host, - 4 hops router, wg-sever, router, switch <10ms
- Local, direct on LAN without wireguard - One hop via your switch <2.92ms (shown last)
Wireguard costs for local use are a relatively trivial 2ms. This is the path switching to go from passing the double encrypted wifi/lan traffic to wg0 port, decrypt it, then pass the SSL/HTTPS traffic into the local LAN. I’m not likely to noticed this as I develop locally for most things anyway and if I keep traffic always passing through wireguard even when local my config settings for DNS and my wireguard gateway can be statically written. Otherwise dynamic network detection and auto-update scripts would be required with wg syncconf would be required and that would be a bit of work to make connectivity reliable (put it on the backlog?).
As a result my resolvectl output is very simple, and works locally with unnoticable latency reduction and immediately resolves dns and routing when I tether to my phone at a cafe hence: Pass all local traffic through vpn, as it doesn’t actually exit the premises, as the local wireguard tunnel is established directly to the wan interface on your router.
Use default stub resolver that will pickup localdomain resolution via the stub.resolver and ensure wg0 link uses the wireguard link for DNS (in my case router==DNS). note internal IP’s are not visible for DNS through wireguard, so you must use wireguard IP’s for DNS registration. In my case DNS IP on my wg0 interface is registered as the wg0 IP of 10.1.100.1 even though upon connection, all internal hosts are visible. Hence resolvectl dns wg0 10.1.100.1 was executed explicitly:
Outcome
At this point all ports of all VM’s are visible from your laptop at the local cafe on your laptop, securely without any likelihood of interception. In my case normal benefits associated with the VPN are that:
I can execute nmap -p22 192.168.1.0/24 and return all my machines that expose SSL ports.
All my local browser booksmarks of hostname.localdomain always work, rather than ssh -L commands needing to map all connections via localhost and custom ports, yuck!
In the end the performance of local connections with wireguard is around 1.5ms with is hardly noticable for local use so having it turned on at all times is not a burden given the convienience of all your hosts resolving and connecting.