Mac Mini on WAN

Apple Remote Desktop is an aging and only minimally supported app from Apple, but back when I used it regularly, you didn't need to set up a WAN or VPN to control a Mac not on your local network. The IP address or FQDN of the Mac you wish to connect to should be enough:

1. In Remote Desktop, select a scanner in the sidebar of the main window, then choose Network Address from the pop-up menu.
2. Enter the IP address or fully qualified domain name in the Address field, then click the Refresh button.
3. Drag one or more computers to a computer list, such as All Computers.
4. Authenticate by providing the user name and password for a Remote Desktop administrator.

I can't say that it still will work, but it did at one time. This of course presumes that the Mac you wish to control is not behind a firewall that would block the ports ARD uses.

Hope this helps. Regards.

If you have a business account with Comcast, you can set up a static IP address:

https://business.comcast.com/support/article/internet/using-a-static-ip

That should allow you to connect ARD to your remote Mac. If you have a residential Xfinity account, they don't provide static IP addresses. Addresses are assigned via DHCP locally in the modem/router and trying to get a port forward so that ARD can see the remote Mac is difficult if not impossible. And many if not most VPN providers say that they don't support RDP. So there may be no practical way to use ARD with that setup, though perhaps someone else here will have banged their head on this long enough to figure out a method.

A better, and almost certainly easier, route would probably be to use a system like LogMeIn which, at least the last time I saw it, used a central connection run by the company to provide the linkage between devices rather than having to figure out IP addresses and port pass-throughs. I don't know if any offer a free "personal" option or if their paid tiers would be affordable for you.

Regards.

This is centrally about configuring, administering, and particularly securing a server.

You’re going to need to establish a remote network connection into the server.

That connection can involve port forwarding at its simplest, or can involve a VPN.

That remote inbound network connection will also usually need either a firewall that can use dynamic DNS (DDNS), or a static (fixed) IP address acquired from your ISP.

Port forwarding here might involve use of ssh, for instance, or other remote access and administrative tooling.

There is particular no need for ARD here, as the built-in screen sharing will work fine. The firewall-associated requirements for ARD and screen sharing here are ~identical, too.

ssh is nice both for port forwarding, and for security. It does, however, assume some familiarity with the command line.

The central risk of enabling and using port forwarding is that ~everybody is going to be poking at open ports (security), and accordingly widely-accessible open ports and unencrypted connections are ill-advisable. Your server will be subject to all sorts of folks posting st the server, and any password compromises or other service breaches can potentially then be extended to exploit issues with other servers on the same local network. (I’ve mentioned use of a DMZ here, as a means of isolating internal network from a potential breach.

Zyxel USG series firewalls and Ubiquiti gateways can provide an embedded VPN server, as do some other vendors and probably some open-source options. The VPN provides a path to protect the connection, and to offload the overhead of folks poking at the connection onto the firewall / VPN server / gateway box.

Most mid- and upper-range residential and SOHO firewalls can provide port forwarding for, say, port 22 ssh.

Most firewall / gateway boxes can also port-forward a VPN connection too, though that port-forwarded VPN connection can be limited to one VPN connection at a time, and that configuration will need a VPN server running somewhere on the local network. Running a VPN server in the firewall / gateway box tends to be easier, where the box supports that.

The other option is to host the Mac requirements somewhere else, such as a Mc running at MacStadium or Amazon. This keeps potential server breaches off the local network, and offload most of the network setup and ISP-associated requirements.

Depending on what is planned for this prospective server, there may be other options or alternatives.

If you want to discuss this in more details, start with what services you plan to try to provide from this prospective server, and how widely that access might be offered. Because that can b=mean more holes poked through the firewall.

Poking holes through a firewall can be Bad.