You're going to have to describe your gateway device and failover gateway device in rather more detail, including some details of their particular capabilities, or identify the devices. (If I've inferred your configuration correctly, this also seems to be a generic networking question and not particularly Apple-specific, too.)
Screen sharing is TCP 5900 as you're probably aware, which can either be port-forwarded directly to the target server(s) through various rules and settings on the gateway server(s), or you can (potentially) establish a VPN to a VPN server embedded in the gateway devices (if the gateway contains a VPN server), and then use the VPN to connect to TCP 5900 on the target system more directly. My preference is to use VPNs for these sorts of network configurations, and not VPN pass-through.
Some gateways have settings to control triangle routing, and you might want to research that for your particular devices. Triangle routing means that the gateway won't necessarily detect the egress traffic (because it's using a different route back out to the internet), and that routing can potentially cause the connection to shut down as the ingress gateway doesn't receive the return traffic; depending on whether triangle routing is enabled or not.
Thank you MrHoffman.
My question is not generic but tied to Apple's VNC. It was the only service disrupted. AFP worked great because the Mac minis are set up as DHCP with manual address.
The gateway should not have been mandatory for this service to work because of the LAN-only connexion requests.
Now that my usual gateway has been replaced, I thought I could reproduce the screen sharing malfunction by simply diconnecting it from the network, shutting down ad restarting all Macs. It's not that simple. I did that and screen sharing works as expected, without any internet gateway on the network.
The only thing I can think of is: while there was no gateway or only my failover gateway on the network, I tried to control my Mac minis with 2 devices that were used on other networks with DHCP just before re-connecting to my network.
As a sum-up:
- All the concerned devices have been attached to different DHCP servers, VNC servers on my own LAN and VNC clients on other networks
- In this case, regarding Apple's VNC, a LAN is not realy a LAN until a replacement internet gateway helps devices get back on their feet.
While I understand the terms, I do not yet fully understand what your IP network looks like.
By "usual gateway", are you referring to a hardware device — commonly called a "gateway router" — that's been replaced here, or to the IP gateway settings present within most (all?) hosts on an IP network?
IP needs a gateway for traffic outside of the subnet. That commonly includes DNS traffic, either from the DNS server(s) on your LAN, or for IP hosts that are communicating more directly. This can also include determining the source of in-bound IP traffic, as that involves DNS translations.
Swapping gateway routers can also sometimes require flushing the ARP caches, depending on what hardware and software is involved. (Normally the new device will broadcast that on the LAN and thus update the caches, but sometimes things get a little wonky.) This if it's at the same address. If it's at different addresses, then the DHCP server, DHCP clients and static-addressed hosts all need to be updated.
In general (and because I'm not certain of your configuration), I prefer to avoid using Macs as IP routers, as they're expensive for and comparatively clumsy at that task. I prefer to use dedicated devices for that, and often preferanly including an embedded VPN server as I'd mentioned earlier.
Again, I'm not clear about your configuration, so the above might not address your question.
By gateway, I mean the hadware device routing traffic between my LAN and the internet. My LAN is composed of a single subnet. I have two gateways, my ADSL router and a spare ISDN router that used to be my usaul router years ago.
No device is in between my LAN and the routers, for failover purposes or whatever. When the ADSL router fails, I manualy activate the DHCP server function on the ISDN router. The two routers are simultaneously on the LAN, thus with different IP addresses, and I sometimes use a special network setting on my MBPro to use the ISDN router as a VPN-like device for remote maintenance operation for some of my clients (I'm a freelance developper operating from home).
Because all the Macs acting as servers on my LAN are set up as DHCP with manual address and because ADSL router failures happened when I came back after a global shutdown for vacations, manual failover should do the job.
...but it only happened twice in 5 years, so I have no real experience. The first time it happened, years ago, I was using Timbuktu, not Apple's VNC and experienced zero troubles.
What puzzled me is that the Mac being controlled (the VNC server) needed an operating internet access (at least temporarily).
Cache flushing could be an explanation.
I suspected the authentication services to be responsible for the troubles, not Apple's VNC server, but AFP worked fine so it mignt not be the explanation. I also suspected a kind of phone-home-reporting-for-sotware-quality-purposes included in Apple's software preventing VNC authentication as a side effect.
Network authentication is based on DNS services translations, so I'd look at that.
There's no "phone home" stuff that would block RDP/VNC.
Might also look to use a BGP-capable gateway router, as those can connect to two (or potentially more) links. I'm in the midst of deploying one of those with what look to be decent firewall capabilies and connecting via a DSL bridge (not a DSL router) and (soon) a secondary network link. This particular box also supports fail-over to a parallel gateway router. These boxes are getting cheaper, too.
Once installation completed, i went to System preferences > Security & privacy > Privacy > Diagnostic and usage
I unchecked the checkbox for sending data to Apple
Unfortunately, I remember having to tell Little snich to allow/deny sending data to Apple not related to a perceptible application crash. This is what I call phone-home (unwanted BTW).
That RDP/VNC seemed not to be blocked (i say seemed because i did press on the screen sharing button in a Finder window, but i'm not competent enough to say if it is a valid statement).
Alas, the VNC client could not connect to the VNC server, waiting for the connection to establish and giving up with an error message after a while. Same thing on the iPad with the iTeleport app. The VNC clients, Mac and iPad, both have the correct passwords stored. I mean it's not a typing mistake on my part.
I didn't know about BGP-capable router devices. Thank you.
I'm planning to give a serious try to IPNetRouterX for cheap failover during the next weeks. I used it recently for that purpose at a client's site because they ended their ADSL phone line contract by mistake. I could not spend enough time to set up DNS and SMTP to auto switch between ISP's specifics, but it allowed me to ease the pain a lot for end-users by putting ISP swintching in a single mouse clic and no mandatory wires handling on their part.
Bonjour Browser - can be used to see the services advertised on your LAN. "Remote Frame Buffer" (_rfb._tcp.) are the VNC servers.
Other ways to start a Screen Sharing session
Finder -> Go -> Connect to server -> vnc://remote.mac.local
Finder -> Go -> Connect to server -> vnc://nn.nn.nn.nn # the IP address
Or from an Applications -> Utilities - Terminal session
The Screen Sharing App is located at
You create an Alias and launch it from whereever you put the Alias. Then use the Screen Sharing -> Connection menu
I could not spend enough time to set up DNS and SMTP to auto switch between ISP's specifics, but it allowed me to ease the pain a lot for end-users by putting ISP swintching in a single mouse clic and no mandatory wires handling on their part.
If you're running OS X Server on a private subnet with the typical and expected private DNS services running on the LAN, then no references to ISP DNS are required nor necessary. There's no reason to add those ISP DNS dependencies, and thus no reason to switch references. FWIW.
Having invalid local DNS can cause delays and outages, too.
My client does not want it's server connected to the internet. That's it's choice.
I'm allowed to connect directly to it via ISDN or via internet indirectly through a remote access dedicated Mac.
In the coming months, i'll have the oportunity to sell them the idea of a VPN among other security measures, with an up to date OS X Server.