Remote Management Port changes to 0

Question

Remote Management Port changes to 0

Anybody else seeing this issue? Somewhat niche I might point out though....

I have used ARD since it's inception and never seen this. I would point out it ONLY occurs when using a site to site IPSec VPN tunnel. I do not get the issue with host-site VPN or SSL VPN connections or any other situation I might add.

When connected to a client site via network-network IPSec VPN:-

It will randomly change the Mgmnt port to 0 on a server or 2 every now and then. It doesn't seen to make any difference what the client is running at the other end (10.4/10.5/10.6/10.7). Change this back and all works fine. It may happen after 5 mins or 5 hours to 1 or 10 machines...

I have a 3com gigabit firewall connecting to a checkpoint firewall in my case.

The main machine I am connecting FROM is a MBP 13" Early 2011 running 10.7.5 (11G63) and ARD 3.6.1 (471.19). Tried early versions (OS & ARD) to the same end result.

There are no specific log entries that would point to anything amiss.

I am testing a 'keep alive' just in case this has anything to do with it - no results either way as yet.

Any one else come across this and fixed??

I did find a discussion from a chap who had the problem back in early 2011 with a SonicWall and didn't seem to find a viable solution...

https://discussions.apple.com/thread/2719634?start=0&tstart=0

Many thanks,

Oli

MacBook Pro, Mac OS X (10.7.5)

Posted on Oct 8, 2012 4:20 PM

Reply

Answer 1

Jan 29, 2013 9:56 AM in response to Oliver Saunders

To answer my own question:

Firstly and pleasingly - it is nothing to do with ARD. Traceroute is also not behaiving correctly to offending machines. It is to do with network hiding addresses. ie if you jump onto to an affected machine and go to whatismyip.com - it lists a hiding address ie - it is being nat'd. If you traceroute to the machine for the ARD mac you are using, you will probably find it resolves to the external address. It is to do with the way certain firewalls handle traffic routing of VPN Tunnels and at what point they are injected into the network.

Solution is to add a firewall rule (from your admin ARD mac IP or range or pool) to reflect the actual IP (non Nat'd IP) of the machine. This solves the problem. If I now trace to the offending mac servers, I get a fully resolved trace. Assuming you are connecting with a NAT Transversal gateway-gateway tunnel - this will work. It should also work for client to firewall access although I have not tested this.

Have over a 100 macs on one site and 20 were exhibiting this issue. By tracerouting and ascertaining what the differences where, came upon this as the solution. Made the change on the CheckPoing box, re-linked the IPSec tunnel and problem vanished!

Why the problem is intermitent I can only put down to sporadic latency on the tunnel. When ARD goes to update the server details and does not get a prompt response - it goes about seeing if the machine has changed on the network (ie IP address update). It then ends up at the hiding address (a la traceroute) of the network. (I am afraid I do not know the internal processes ARD goes through exactly at this stage - I am just making an educated guess). Subsequently it then queries this virtual device for remote mgmnt port access and I can only assume, unsurprisingly, the response ARD receives is not as expected and it (for whatever reason) reverts the port to zero.

Hope this helps anyone else out there struggling with this chestnut.

Reply