I would like to setup remote access for my home network, to allow both Android phone and W10 laptop to access the network. I know there are a variety of VPN options, and am a bit unsure which would be the easiest to setup and deploy.
This is not something I would use every day, and don’t require major throughput and performance…just remote access to manage a few services.
Can you recommend the best option?
This is not something I would use every day, and don’t require major throughput and performance…just remote access to manage a few services.
Can you recommend the best option?
With those criteria, it might actually be better for you to use OpenVPN. Wireguard is fantastic for a number of reasons, but for being able to reliably connect, OpenVPN has some advantages still, at this time.
That said, there’s no reason you can’t set both up. You do start running into potential other things on your side, if you run a web server, but those are things you can work with, as opposed to just setting up Wireguard, and then ending up somewhere you can’t connect from, and you’re just stuck. This is less likely to happen with OpenVPN because it can use both ports almost no one blocks(443) and ports that are well known as VPN ports, so don’t tend to get blocked.
I’m going to recommend OpenVPN or Zerotier for your use case, especially if the number of clients is > 1.
Why? Even though Wireguard talks a big talk about how little code they have and how simple it is, it provides absolutely no client management and client configuration. Peers have to manually exchange each others public keys and the IPs available via the peer, and communication will work. The ecosystem for managing client devices is just not there.
OpenVPN has a ton of additional features relating to client authentication, options such as using internal/external user databases, and pushing IPs and routes to the client from the server. All of this essentially makes the client zero-configuration, you just need the IP, Port, and Protocol (TCP/UDP) and the server will push the rest of the configuration to the client once it authenticates with a username/password. For a more secure setup, you also have the option of using client keys to authenticate instead of or in addition to a username and password. You can add new subnets and routes to them from the server side, or change the IP assignment policies on the network, and clients will automatically get the updates next time they connect. It’s also possible to allow one set of user credentials to connect from multiple devices at the same time, which does not work at all in Wireguard.
Zerotier is a bit different, but also provides a lot of client configuration features. However, since all nodes are clients, you either need to configure the network with no IP management in Zerotier and then tell OPNsense to provide DHCP and client management on the network, or set a ‘static’ client IP for OPNsense on the Zerotier network configuration site with static routes to the networks accessible through OPNsense’s client. The main advantage here is neither end needs port forwarding, so it can work better when the OPNsense side is behind another router. You have to rely more on the Zerotier website for configuration of the network authentication, since they manage the network, not the OPNsense client.
I use wireguard, but not the opnsense package. I couldn’t get it to work at first, but after spinning up a Debian VM for wireguard I realized the issue was the allowed IPs.
Now it’s easier to leave it in a VM, does everything I need it to, and it is easier to setup new devices as well.
Zerotier and tailscale? Are other options to check out, zerotier works very well if you just want access.
If you’ve got a docker service running somewhere on your network, I setup an OpenVPN server using this: GitHub - hwdsl2/docker-ipsec-vpn-server: Docker image to run an IPsec VPN server, with IPsec/L2TP, Cisco IPsec and IKEv2
and it was pretty straightforward. I struggled with the wireguard through docker containers for a while but recently got the OPNSense wireguard service going and have been using it for two months or so. The setup is a bit arcane, but once running it’s noticeably faster to connect - but the OpenVPN setup I had going ran for years (literally) without any issues. (I was just tempted to try wireguard cause everyone’s always talking about it).
Both are fine once you get them going, I don’t think either is a bad choice. Sure Wireguard’s faster to connect initially, but for a home network, both are more than adequate.
Until you try and use it and realize lots of places actually block random UDP ports and you can’t establish a connection.
Wireguard is great, but you have to understand what the issues can be.
No, it’s not that simple, because Wireguard is UDP.
go to your nearest mcdonalds and you will
Yup, but OpenVPN is well-known, and the VPN ports for it are left open often on purpose, which was one of my original points. You’re only thinking about one half of the problem, the client side. And your comment about OpenVPN being UDP by default is besides the point. The point with it being UDP is that many places will just block UDP…which is the reason why OpenVPN can also do TCP. Wireguard has no such facility in itself…so you actually just supported my argument in favor of OpenVPN over Wireguard.
It’s also not that simple because we’re also talking about what the OP would have to have setup at home to facilitate this. If you start forwarding common ports that do other things like 53 and 443 through, you have to start considering if that will cause problems as well. 53 is probably not as big a deal, but plenty of people might have a web server on 443. Which means knowing more about what the OP has going on, and they might have to start thinking about having smarter TCP traffic redirection.
Everything you’ve said is not wrong…in a very basic, simple setup. We don’t know what the OP has, but it doesn’t mean your right, and your view of those as solutions only work in simple setups, but rapidly run into problems if you have much else going on.
It’s great that it’s worked for you, but you cannot assume that it will always work.