Instructions for managing macs w ARD over internet (no static IP)

This question is not particularly related to Apple Remote Desktop; to ARD. It's a generic firewall setup and networking question, so pretty much any directions for your specific firewall will work here, so long as the firewall can forward ports — TCP port 5900, for this case — or if your particular firewall has a VPN server — mid-range and upper-end firewalls often do — or if you can establish a VPN server behind your firewall and configure the firewall to forward the VPN protocols (different from ports) and ports necessary for the particular VPN.

In general... I'd suggest one of three ways... 1: Set up your firewall to port forward TCP port 5900 to the target client. Maybe TCP 5988. Or set up a VPN server in your firewall, and connect to that and use ARD via a VPN. If you need access to more than one system on the target network, you'll either have to use a range of ports to forward to specific systems behind your firewall and which gets to be a hassle with many clients — I don't immediately know off-hand if the ARD client even allows selecting different target ports — or configure and switch to a VPN. 2: Establishing and configuring the VPN server in the firewall will allow access to any of the systems on your target network — a VPN connection makes your local system seem like it's directly connected to the target network. 3: If you have the VPN server running on a system on the target network and accessible via the firewall port forwarding, that target system will always have to be available, and all VPN traffic will be routed via that system. It's more complex, and can also be somewhat fussy to get set up.

If you directly expose ARD ports to the Internet via port forwarding, you'll either want to restrict the source IP ports available (to reduce the breadth of attackers), and you'll want to be very careful about the passwords on the target systems. ARD ports are very commonly probed, and more than a few folks and botnets will be trying to gain access to the systems through password brute-forcing; through trying to guess users and passwords on the target system. Once the attackers have a connection and a password, they'll then try to spread through the rest of the network. (This is part of why I prefer to use VPNs.)

MacOS Sierra will not be supporting PPTP VPNs, so I wouldn't go that way with any VPN configuration you do consider. I'd probably use L2TP/IPsec, given that client is commonly available in macOS, iOS and most other operating systems.

There is information available on the networking ports used by Apple devices. If you select VPN port forwarding, there are discussions of the ports and protocols needed for whichever VPN you're using posted around the 'net, and not all firewalls are particularly good at port- forwarding the VPN ports and protocols. Low-end firewalls and older firewalls tend to have issues here.

To locate the systems on the target networks, you're left to use dynamic DNS from the client devices or some other means to identify the public IP address associated with the target client. If the clients are roaming across disparate networks and not simply roaming IP addresses on their private networks (those addresses can be fixed via DHCP configurations, too) and if you don't have access to the intervening firewalls, then you're probably going to have to rethink the whole approach, unfortunately. Connecting to arbitrary remote roaming systems isn't particularly feasible, there needs to be something on the client that "beacons" or "announces" its network metadata to your own client-tracking server or to some other entity's tracking server (such as announcements to the DNS servers used by the dynamic DNS providers), or the management connection has to be initiated from the client. ARD doesn't support these mechanisms. Discussions here can get fairly complex, too — both in terms of network setup, and in terms of ensuring security for both clients and servers.

There are some discussions related to this general topic in the forums; see here, here, here, here or here.

Thanks MrHoffman! These are great instructions! The only other problem I have to solve is being able to use ARD after reboot. If I'm in another country and update my remote box when that update requires a reboot I'm locked out. I don't even think osx server will work to solve this problem. Clearly this isn't an ARD problem but an ARD feature to restart and power on do exist. From what I know these are older features for a specific piece of hardware.

Not entirely sure which box is rebooting. The box running ARD, or the box that's the target of ARD.

I don't have the ARD boxes roaming around, given the associated access sensitivity — I haven't encountered the need to reboot — and I don't generally even use ARD to manage random roaming devices.

If you "just" need screen sharing, then that may be an option using the embedded screen sharing client. For some management, getting an ssh connection can be more than enough, and there are ways to establish bi-directional network connections over ssh or other such. This is not something that ARD provides, and would involve some effort and local configuration work to establish.

If you're referring to rebooting the target box and regaining access, that's always tricky, unfortunately. You may well be running into a different IP address secondary to the reboot. Only way around that involves something akin to dynamic DNS, or some other software on the client that "beacons" the address as mentioned in my earlier reply, if the client is remote and likely to shuffle addresses.

I'd tend to question whether ARD (or even screen sharing) is even the most appropriate tool here, too — this if everything is wandering around across different networks, that is.

Sorry I meant what if the target box needs a reboot after update. I have tried rebooting the target box from the ard client and I can never get back into the target box. It is a tricky thing but isn't only the local ip have a chance of changing? the external ip is pretty static. It rarely changes.

What you're referring to with TeamViewer is what I was referring to with "beaconing" or "announcing".

To some added software on the target system that reports its IP address and configuration.

Neither ARD nor macOS provide that particular capability.

That capability would necessarily have to be add-on software, such as via some locally scripted ssh or some other local client-access software that's been installed onto the client (target, managed) systems.

This is what various of the add-on remote-access packages provide.

Anti-theft packages are in this same general product range.

I tend to prefer to have those services contacting a server I control, as otherwise I'm ceding more than a little of the client (and likely also server) access control to the third-party provider. This as I'd prefer to be subject to (only) my own security breaches, rather than also subject to breaches of often very large remote-access aggregators. Though some of them do undoubtedly have solid security. These particular folks are very interesting targets for attackers, too.

I just noticed there are two folks posting questions and feedback. Are both of you working the same request and the same requirements, or are there two different sites and two different requirements being discussed in parallel here?

I thought the OP was me O_o. whoops.