Many services I’ve noticed offer the convenience of accessing the service anywhere, sometimes for a fee (i.e., Control4 home automation, Home Assistant). While I do want to access my data or services from anywhere, I don’t necessarily want to pay a subscription fee for each service forever. I’d much rather build something that would enable that myself, which is when I started looking into VPNs.
In the past I had used OpenVPN, but when I did some research and saw WireGuard is a super-efficient and secure option, I decided to use it. I have an Omada (a small business-class) router, which has WireGuard as an option, so I set it as a server. At the time I set up the VPN, there was no option for ‘server’ vs. site-to-site, so I set up a site-to-site WireGuard VPN with each device I use.
Infrastructure:
- Omada Router (Server)
- Tablet (Client)
- Fedora Laptop (Client)
- Android phone (Client)
- iPhone (Client) – much to the chagrin of my daughter, to be a tester when it sometimes doesn’t go well…
Client Setup Example
- Name: Home VPN
- Private / Public Key – Auto generated by the client
- Address: 1.2.3.4/32 <– This assigns the address 1.2.3.4 when the vpn connects to the remote network
- DNS Server: 1.2.3.5 <– example DNS server on the remote network
- MTU and Listen Port – I leave these default
- Peer Options: Public Key – This is the server-side public key
- Pre-Shared Key – This is a key that enables (theoretically) quantum-safe encryption between the client and server
- Persistent Keepalive – I set this to 300 seconds; it will attempt to keep the session alive every 5 minutes. I set it to 5 minutes to preserve battery life and to make it look more unusual from a network footprint perspective
- Endpoint – I redirect the port to 443 on a specific FQDN for security and to make it seem, unless closely inspected (and the UDP traffic is noticed instead of TCP), like normal https traffic
- Allowed IPs – 1.2.3.0/24 – I only specify the example 1.2.3.0 255 IP network to traverse the VPN; all other traffic will route from the device directly to the internet connection
The Issues
The VPN is generally great and behaves exactly the way I’d want. Unfortunately, there were two issues I struggled with:
- When the router ever reboots (happens a few times a year), the client-side VPN blindly stays up but is not functional, essentially breaking the client internet connection for all traffic, even though it is set as a split tunnel.
- Root cause: 2 root causes; the first is that when the router reboots, it grabs a new internet IP from my ISP. My dynamic DNS automated update process is functioning as expected. The default WireGuard VPN client, however, caches the IP when it first establishes the tunnel, and when the keepalive functionality triggers, it uses the cached IP address to re-establish the connection, which is no longer valid because the router IP changed. This is primarily a VPN client issue. The second issue is the same root cause as issue 2…
- Resolution: Updating the client from the base WireGuard app to WG Tunnel for Android and Passepartout for Apple devices addresses this issue.
- If the router goes down for a power outage (extremely rare, but happened for hours last week as of this writing), the client-side VPN stays up but is not functional, again breaking the internet connection for all traffic.
- Root cause: Since I only specify a single DNS entry, it’s not a routing issue to prevent internet traffic; it’s that the client cannot contact the valid DNS server specified in the client configuration because the VPN client assumes the tunnel is up when it isn’t. If I updated the DNS configuration to add a second internet DNS server (i.e., 4.4.4.4), then due to the way DNS works (round robin), I wouldn’t be able to consistently access servers or services on my remote network. This is also a VPN client issue.
- Resolution: Updating the client from the base WireGuard app to WG Tunnel for Android and Passepartout for Apple devices addresses this issue.
I rolled out the updated clients yesterday as of this writing and am looking forward to testing, hopefully resolving the two issues identified over the last year or so of testing.
