How to limit incoming Remote Desktop connections to 1 MAC address client?

MAC addresses are not passed over the IP connection. That for various reasons, not the least of which are tracking and spoofing. It’s quite possible to spoof MAC addresses, some Apple gear deliberately spoofs its own MAC addresses to make tracking harder, and at least one network protocol deliberately changes the MAC addresses it uses, just to keep things interesting.

It’s quite possible to have an IP host that does not even have a MAC address. MAC addresses exist for Ethernet and Wi-Fi and some other data links, but that’s not the only way a host can connect to IP networks.

I usually use a firewall that supports an integrated VPN server. Use the integrated or an add-on VPN client on the Mac, connect to the VPN server in the firewall, and you’re issued a LAN local IP address on the target network, and are now mostly-local. All your network traffic into the firewall is also encrypted.

Various mid-grade firewalls offer this embedded VPN server capability, and I’ve used ZyXEL ZYWALL USG series devices, but there are various other options. It’s also possible to use a host-based NAT pass-through, but that’s not a configuration that’s preferred locally as it’s more of a hassle to use, and it’s only accessible when the target host is working and the VPN server is working. The firewall is usually very stable, and it’s less often that folks tweak the firewall configuration as tweak or update or upgrade or reconfigure the host software and network configuration.

Michael Levin wrote:

Understood. I definitely do not want to give any outsiders access to anything inside the LAN, I thought the VPN was what was suggested for this case early on in the thread.

That’s what has been being discussed throughout. Again, you are running a server now, and you wish to have authenticated, cryptographically-secure remote network traffic into your server. This is a fairly common requirement for remote server management, too.

What I want is that only 1 computer - my laptop - and only from inside the LAN - is able to connect to remote desktop or VNC on my machine.

What you want is to communicate, privately, remotely, securely, yes.

You want to remotely identify a specific client, too.

You had thought of using MAC addresses here, which are insecure and spoof-able locally, and are not available remotely.

Basically, MAC authentication is problematic locally, and unworkable remotely.

Which then led to the suggestion of a secure remote and authenticated and encrypted connection.

Also known as a VPN.

will keep reading to try to find the easiest way to set up a secure remote access (VNC or RDP) that will be the only one ever to be able to connect with one client machine.

Yes, you are looking to have a remote client pass through into your network.

Securely. Encrypted. Authenticated.

That’s called a VPN.

Maybe this can be set on my router somehow.

There’s no way to restrict an source to a specific client, on a firewall or on a server within IP networking, absent some additional information passed over the connection.

You can restrict the connection source to details such as a known and static/fixed/unchanging source IP address, but a mobile client seldom has the same source IP address.

You cannot restrict to a remote MAC address, as that does not pass through IP to the server. That’s data unavailable to the server.

You could open up the remote access for IP TCP port 5900, and lock down the access credentials. But everybody on the internet is going to be poking at an open ARD/VNC/RDP port.

How this works, securely, with authentication, and with encryption? That’s called a VPN. Either a VPN server embedded in the firewall—mid-grade and upper firewalls offer this—or what’s called VPN NAT passthrough. Which is just like the port forwarding you’ve been envisioning, but involving a few more ports and a protocol or two. (Ports and protocols are different constructs in IP networking.) This NAT passthrough is a bit more precarious and a bit more complex to get configured, but can be gotten to work.

But I’ve clearly completely been unable to communicate how any of this works in a way that’s been appropriate for the discussion, and it’s probably best if I bow out of the discussion. As an alternative, discuss this with a local business-computing and business-networking provider.

A network connection establishes a path between hosts.

Typically, from a client host and a client app, to a server host and a server app.

That client app might be a web browser, and connecting to a web server app.

(The client uses other network services on other servers—often including DHCP and DNS—to connect, too.)

That browser connection might use an IP connection (HTTP), or might use a secure path (TLS, HTTPS) connection, over IP.

A VPN is a specific type of network connection, and is used to secure apps that are not themselves using a secure path.

A secure connection might be TLS, or some other scheme.

In this case, ARD/VNC/RDP is something everybody on the internet searches for.

Not the least of which is because the unwary and the ignorant quite commonly set up servers.

These servers might be running ARD/VNC/RDP, and are variously configured with bad passwords.

Or insecure traffic, such as that found with insecure connections.

There are other protocols that are routinely sought, this mess is not limited to ARD/VNC/RDP.

Some folks still use telnet and FTP and HTTP.

Your Mac includes VPN client software for a few different VPN protocols.

There are add-on VPN client apps for other VPN protocols.

Here, a VPN client allows access to a VPN server.

That VPN server might be on the target host, or it might be on an intermediate host such as on the target network firewall.

That is, a network path. From one host, to another host.

A VPN can then—like other sorts of IP network paths—transport ARD/VNC/RDP, telnet, FTP, and HTTP traffic.

Wrapping the traffic in the VPN protects the path against sniffing.

Wrapping the traffic also prevents folks from accessing the VPN server without the necessary credentials.

Wrapping the traffic also means fewer ports are open on the target network. Quite possibly, just the VPN ports.

You’re entering into a more complex area of system and network admin here.

Running and securing a remotely-accessable server.

Which means you need to know about networks, networking, and security.

You now need to know more about the sorts of things that many of the folks running clients can ignore.

Clients are usually running a firewall or restricted services, and are usually behind a NAT firewall.

This means clients are far less accessible to remote users.

But these clients are dependent on remote servers for many of their own functions, including DHCP, DNS, and other servers.

Why do you need to know more? Because you’re starting to configure and manage and run servers and server apps.

You need to know a little more about how IP and DNS and TLS works, too.

Welcome to the deep end of the proverbial IP network pool.

For the pedants, yes, I’m playing slightly loose with the terminology.

1: why would you give the equivalent of a physical network cable and connection into your LAN to a random person?

That VPN makes the remote client computer—once the client has authenticated with your VPN server, and with the VPN-specific credentials—appear to be connected to your LAN.

To answer your question directly, they’re on your network, and they’re going to poke at any other open ports on any other devices, whether network-connected printers or scanners, or that old Mac or PC running ancient software, or whatever. Now if ARD/VNC/RDP isn’t running, they won’t be able to access ARD/VNC/RDP. But it’s pretty rare for a home network to be (effectively) locked down against a malicious local network user, and patched to current.

2: why would you have open parallel port-forwarding paths in through your firewall, and paths which largely negate the benefits of establishing the VPN? You could but that really doesn’t make much sense for a private server computer.

To answer your question directly, yes, you could block the range of local IP hosts associated with the VPN clients. But you’re probably not going to want to run a mixed-security local network, other than as a DMZ (see below). But these folks are on your network. Best to not provide VPN access.

DMZ...

If you are thinking of also using the private server computer for other and more public uses, such as adding and running a web server or such, then I’d take additional steps to partition the internal network. This as a server breach would otherwise potentially open up the rest of the local network. Plan for failures (such as the host with the VPN server, if you choose that,approach) and for breaches, in other words.

This configuration is sometimes called a DMZ configuration. This where the at-risk servers are isolated into a specific local network segment by a firewall configuration, and cannot access other internal systems.

additional...

I’d again recommend the VPN server be resident on your firewall (which might mean a firewall upgrade), and to not try to use NAT VPN pass-through into a host-based VPN server. That adds configuration complexity around the NAT, as the VPN wants to identify the end-points of the network connection, and the NAT wants to hide those.

Some general reading:

https://www.ccna-study.com/2019/06/introduction-to-vpn-virtual-private.html

https://networklessons.com/cisco/ccna-routing-switching-icnd2-200-105/introduction-to-vpns

Ignore all of what I’ve posted. Particularly on VPNs.

This whole sequence is slightly hilarious.

I’ve wasted massive time and confused things answering a question you hadn’t asked.

I’d taken your references to remote access and the cable box and the Netgear to mean, well, remote access.

That you were going to use this laptop to manage this system from another network.

You’re not. The network firewall is not involved. Only the server software firewall.

Because a laptop on another network will not have a static/fixed IP address while roaming networks.

Here’s a write-up which includes an example of a local IP address to a local IP port, which’ll do what you want.

ARD is probably a waste here, but have at. Why? The built-in Screen Sharing (which is also free) alone will do what you want for remote displays. ARD adds some other abilities, around pushing out commands and such.

And as for the port and has already been mentioned in this thread, TCP 5900.

Here’s what a web search turns up for the other ARD-related ports, but these aren’t strictly necessary for screen sharing use: https://www.how2s.org/index.php/Howto_get_Apple_Remote_Desktop_to_work_behind_a_router