I currently have a server running Unraid as the OS, which has some WireGuard integration built in. Which I’ve enabled and been using to remotely access services hosted on that server. But as I’ve expanded to include things like Octopi running on a Pi3 and NextcloudPi running on a Pi4 (along with AdGuardHome), I’m trying to determine the best way to VPN to my home network with the goal of reaching services I’m hosting, and do it safely of course.
I have a Netgear Nighthawk that has some VPN functionality built in that uses a OpenVPN account. Is that ok or would it be advisable to come in a different way?
deleted by creator
Doesn’t tailscale retain closed source for the coordination server?
I think nebula mesh is totally open and you can run your own coordination server, lighthouse?
Nebula would need static IP, TS can do that part for $
Everything but the coordination server is open source. But you can selfhost this part yourself: https://headscale.net/
Pivpn
+1
I think openvpn works completely fine for most use cases and didn’t have any trouble with it at all. I did however switch to wireguard on my gateway and I get a little better throughput compared to openvpn. That being said, I’m also using a pfsense box as my home gateway, so access to internal services has been easy as general routing gets.
I run a wireguard vpn into my home, and i can access my local services. It was a small matter of setting up routing properly.
I am using https://www.firezone.dev/ to set it up and manage it, but i believe it can be done manually if desired.
That’s looks handy. Thanks!
I set it up manually using this as a guide. It was a lot of work because I had to adapt it to my use case (not using a VPS), so I couldn’t just follow the guide, but I learned a lot in the process and it works well.
I had something manual setup originally as well, but it became a bit of a maintenance hassle. Moving configs to devices was a bit of a pain, and generating keys wasnt easy.
Adding a wireguard system that has iptables adjuated to include forwarding and masquerading will allow your single wireguard connection to see the rest of your LAN https://www.stavros.io/posts/how-to-configure-wireguard/
Yeah I know some of those words…
I’m still a newb but I’ll have a look at that link, thanks!
If you are totally new to wireguard setup, I found that reviewing all of these links gave me a better understanding of how the configuration setup worked. No one site seemed to cover it all, and each on had some good tips or explanation about a certain part of wireguard.
https://golb.hplar.ch/2019/07/wireguard-windows.html
https://emanuelduss.ch/2018/09/wireguard-vpn-road-warrior-setup/
https://docs.sweeting.me/s/wireguard#
This Stavros one has the post-up/down IP table modifications for forwarding traffic and your wg device masquerading as any device on the LAN
https://www.stavros.io/posts/how-to-configure-wireguard/
https://www.linode.com/docs/networking/vpn/set-up-wireguard-vpn-on-ubuntu/
That great, thanks for the info. I was able to get Wireguard setup in unraid but they make it pretty easy, so I didn’t have a problem. I just didn’t think about connecting to the entire network, not just the server.
I host an openVPN instance from a Debian machine with my phone permanently connected to it.
Keeps my phone within my lan while roaming so it has access to non-public services like pihole, the arr stacks management interfaces, ssh/ftp, etc. Also keeps my browsing private + secure on public/work wifi.
Only the things I share with others like Emby get exposed to WAN (through a reverse proxy), the rest is VPN/LAN access only.
As others have said, I’d play with routing/IP forwarding such that being VPN’d to one machine gives you access to everything — basically I would set it up as a “road warrior” VPN (but possibly split tunnel on the client [yes I know, WireGuard doesn’t have servers or clients but you know what I mean]).
Alternately, I think you could do some reverse proxy magic such that everything goes through the WireGuard box — a.lan goes to service A, b.lan to service B, etc., but if you have non-http services this may be a little more cumbersome.