Best way to run a VPN server on a Mac (replacing MacOS Server’s VPN)

Hi all, I’d appreciate any advice or words of wisdom with the following. I’m decommissioning MacOS Server 10.12 running on a Mac mini. It has been providing device management, user management, and file sharing for a small organisation. We’re moving that all into the cloud. However, there is one service provided by Server that I need to retain, and that is its VPN server. It allows me to connect to the local office network for some of the support tasks I carry out, including screen sharing with the Mac mini which will remain in use to make local backups of the online file library.

MacOS Server has been discontinued in any case, so this move is long overdue. Apple’s migration guide provides details on how to enable the vpnd (the VPN server that MacOS Server used) on normal MacOS. However, I feel that managing and configuring this will be cumbersome, require a lot of re-education on my part every time I want to do anything, and lack much information or help from the internet. I also think that it uses the LDAP directory for authentication, and I don’t want to have to maintain that.

Apple’s support page about Server being discontinued lists three alternatives to the Server’s VPN service:

I know pretty close to nothing about these options. The one thing I’ve heard is that WireGuard is relatively new and well regarded in terms of efficiency, speed, and security. But I’m not sure if my impression is well-founded or not. Nevertheless, at the moment my plan is to use WireGuard, and I’ve found what looks to be a good reference for setting it up as a server at There’s another tutorial on OakHost (who provide Apple Silicon Mac mini hosting).

Before I roll up my sleeves, I thought I’d check in here to see if others with more experience think this is a good route to take, or if I should be looking at OpenVPN or elsewhere? Many thanks!

I’m using TailScale for this myself. It basically creates an ad-hoc private network and easily allows me to do screen sharing remotely.

I think under the hood it’s wireguard?

This is potentially a big topic, but I might have a workaround that would save you the trouble.

First, if you truly want/need a full VPN, then Wireguard is a fine choice. It’s what I would go with were I starting from scratch. I implemented my VPN servers back in 2005 before Wireguard existed, so inertia has me still using OpenVPN (which is also fine, but I think Wireguard has significant advantages).

There might be a way you could forego a full-fledged VPN altogether. Do you, by chance, have the ability to log into a shell on the server using SSH? If you’re already doing that, you can use SSH port forwarding to access services on the machines in your “local office network.” For example, consider this command:

$ ssh -L 5910:

I run it on my MacBook Pro where it opens a command-line shell on the machine which is in my (former) office and magically forwards port 5910 on the MBP, through oroute, then to port 5900 on the machine on the remote LAN at I can then use screen sharing on the MacBook Pro and connect to localhost:5910 and I’m screen sharing with the remote machine at on my office network. That one command is all it takes. You can similarly create tunnels for any other services on the “local office network” just by changing the local network IP address ( in this case) and port and then connect to it via localhost.

Of course, if you’re not already into using SSH and command lines, this probably doesn’t make much sense and setting up remote SSH logins would likely be at least as difficult as a full-fledged VPN setup, but if you’re already doing remote terminal logins this is easier, faster, and more secure than trying to set up and maintain a full VPN.

Please feel free to message me off-list if you’d like more detail. (Even after 30+ years, I can still get a headache trying to keep addresses and ports straight while I’m setting up forwarding, but once you’ve finished the exercise it will just-work from then on.)

Big fan of Mullvad VPN which offers Wireguard.

This is an interesting option which I’d not considered. One thing I’m not clear on from reading through their website, is whether it would make my (remote) laptop a device on the local office network. Part of what I need the VPN for is to screen share with the Mac mini. But I also connect to the VPN so that I’m on the local network and can run Remote Desktop to control some of the Macs in the office. The need for this has greatly decreased, and there’s probably a better solution these days in any case. But if I’m reading the Tailscale website correctly, I would have to install it on each Mac in the office that I want to control. This is impractical for logistical reasons. As I say, though, maybe I should give up on this functionality.

This is also an approach I hadn’t considered which is attractive. I do have SSH access to the Mac mini, but at the moment I have it configured so that you have to be on the local network to access it over SSH. So I have to connect to the VPN before I have terminal access over SSH. It might make sense to switch this around, open SSH to the internet, and forgo a VPN altogether as you suggest. And I greatly appreciate the offer of further help off-list. Two complicating details with this approach are that I don’t think it would make my remote Mac a part of the local network generally, so I would have the above mentioned issue with not being able to access other Macs on the office network. And the other is that the building’s IT support is pretty bad, and I would have to contact them to rearrange the building router’s port forwarding so that I could SSH in from outside. The prospect of having to deal with them unfortunately presents quite a high barrier.

I’m aware of Mullvad as a VPN provider that allows me to connect and route all my internet traffic through one of their VPN servers in any number of countries. But do they also provide server software so that I can install a VPN server on my Mac mini? I couldn’t find this on their website, so if you have further info on it that would be great.

Thanks all. I think WireGuard is still the top of my list, but I’m mulling over both Tailscale and using SSH tunnels.

I’ve not done it myself, but TailScale supports something that they call subnet routers.

Ah, this is helpful. I’d seen that in the feature list but not explored further as I assumed (wrongly) that it had to be installed on an actual router. But the page you linked to makes it clear that this is exactly the feature I’m looking for (and it was previously called a “relay node” which fits with my mental model of what I want). Having read up more details on the WireGuard configuration, and with this subnet router feature, I’m now thinking I prefer Tailscale. The WireGuard configuration is certainly possible, but Tailscale looks a lot easier. So I will likely try Tailscale first and use WireGuard as a fallback. SSH tunnels are still in my mind, but I think I want something where I don’t have to configure each service I need to access separately (which I think SSH tunnels would require). Thanks again!

Once you’re able to ssh to one machine on the office network, you can then tunnel through that machine to any TCP port at any address in the office’s local network. So you would have access to all of them.

You would, indeed, have to enter a separate ssh command for each service you wanted to access, so if there are more than a few that would tip the convenience balance toward a VPN.

You would have the same problem implementing a VPN server on the office network. There would have to be at least one TCP port forwarded to your VPN server from outside the office LAN, whether you’re doing SSH, OpenVPN, or Wireguard.

If you already have any port forwarded to any ssh capable machine on the office LAN, you can simply bind SSH to that port and you’d be golden.

1 Like

Ah, that’s a good point, I was just thinking of using the standard SSH port. I do already have port forwarding set up (to use the existing VPN), so want to use those existing ports. The IT support used to be provided by a different company who were much easier to deal with (and more competent), so luckily I have working port forwarding from that time.