Mac VPN Settings Don't Start a Server: Where the Gateway Lives

Two different jobs wear the name VPN in macOS, and the settings pane handles only one of them. If you want this Mac's traffic to leave through a provider or a remote gateway, a client entry is all you need. If you want to reach the printer, the NAS or an admin page on your home network from a hotel room, then something on that network has to accept connections from outside, and a current Mac is not that something out of the box. Three questions settle which case you are in, and they are worth answering before you type an address into a field.

A client entry names a destination, not a listener

In System Settings > Network > VPN on macOS Ventura and later, the fields that older releases keep under Network preferences describe how to reach someone else's endpoint: a server address, a remote ID, an account or certificate, and optional connect-on-demand rules. Saving that entry stores a connection in your Mac's network configuration. Nothing in the process binds a port, opens a listener or enrolls a remote user.

You can check this from the shell. On a Mac you suspect is serving, run sudo lsof -nP -iUDP and look for the ports your protocol uses: 500 and 4500 for IKEv2, 1194 for OpenVPN's default, 51820 for WireGuard. A client-only machine shows sockets paired with a remote address and port, not a wildcard bind that anything on the internet could reach. Tunnels that run inside a Network Extension can hide from lsof, so cross-check the app's own status panel either way; what you will not find is an Apple preference that turns this Mac into the gateway.

Three questions separate the two roles

Work through them in order. The first one usually decides the rest, and the third one is where most Mac-specific planning goes wrong.

1. Who starts the conversation? If your Mac dials out and the other side answers, you need a client. If devices on the internet must dial in to reach your network, you need a gateway with a public entry point, and the Mac can stay a client of that gateway.

2. What has to be reachable while the tunnel is up? One service on one host is a port-forwarding decision. A whole subnet, name resolution included, is a routing and DNS decision, and it changes what the gateway must forward rather than what the client entry says.

3. Which OS release runs the accepting end? For Macs that question has a hard answer. Apple lists VPN as removed from macOS Server 5.7.1, and the macOS Server app itself was discontinued on April 21, 2022; the service history notice is the page to read when an old tutorial walks you through a VPN service checkbox that no longer exists.

When the first answer is "someone outside initiates", stop looking for a switch in the Mac's client pane and go choose the host that will terminate the tunnel.

Where the gateway can live instead

Four arrangements cover most home and small-office cases. A router with a genuine server mode, as opposed to a client mode with a different label, terminates the tunnel at the edge and keeps the host count low, at the cost of being tied to that firmware's protocol support. A NAS or an always-on mini PC runs the vendor's server package and leaves you logs you can read. A small cloud VM gives you a public address you control and reaches home over a second tunnel. A mesh overlay built on WireGuard, or a managed service that relays between peers, sidesteps inbound port forwarding by having both ends dial out.

The boundary between those options is usually your internet connection, not the software. If the ISP puts you behind carrier-grade NAT, no amount of router port forwarding produces a reachable entry point, and a relay or mesh arrangement is the honest answer. Compare the WAN address your router reports with the address the outside world sees; if they differ and the router's value sits in a private or shared range, plan for the relay case.

Whichever host you pick, forward one protocol on one port rather than a range, and keep the Mac out of the inbound path unless that specific product documents a server role for the macOS release you are running.

Confirm the role before you hand out profiles

On the candidate gateway, prove a listener exists instead of trusting that the installer created one. On macOS that means sudo lsof -nP -iUDP filtered to the ports above, plus sudo pfctl -s nat if packet filter rules are part of the design. On Linux, ss -lunp shows the same facts without ambiguity.

Then test from outside the network, using the protocol itself. Ping proves little: ICMP is commonly filtered and says nothing about UDP 51820. A client handshake with verbose logging, run from a phone on cellular data, is the cheapest real test because it crosses the same path a remote colleague will.

Only after that do you touch client profiles. On the Mac, scutil --nc list prints the VPN services the system knows about; if the gateway you just built is not among them, you are configuring a different machine than the one you tested. If the handshake succeeds on the LAN but fails from outside, the fault is in the inbound path: NAT rule, provider CGNAT, or a firewall on the gateway, in that order.

Before you build anything, settle four points:

• Which side initiates the connection, your Mac or a remote device.
• Whether the accepting host's OS release and product actually support a server role.
• Whether your ISP gives you a reachable public address at all.
• Which single port and protocol the gateway will accept, and which service behind it answers.

The next step is concrete: pick the gateway host, confirm its listener from outside, and only then create the client entry on the Mac that points at it.