Remote Management Port Changes to 0 (zero)

Question

Level 1

0 points

Remote Management Port Changes to 0 (zero)

Using Remote Desktop version 3.4 (465.14)
This seems to be a problem with the client and not the ARD program as this same will happen if I am using ARD on my PowerBook (OS X 10.5.8 and ARD 3.4) as well as with the Mac Mini.

Problem is that the Remote Management Port changes from 3283 to 0.
I can watch it change right before my eyes.
+This is happening to ONLY ONE computer that is behind a SonicWall 2400+.
This Mac is running OS X 10.4.11 and ARD 3.4 client.
The others in the list (total of 19 computers) do not have this problem.
None of the others are behind a SonicWall.
I have remove and recreated this entry many times.
When this happens I can screen share (with control) just fine. I just can't copy files.
If I do a get info and change the management port back to 3283 it will work just as intended.

The only console message is:
Remote Desktop[532] OnlineAdminReplyHandler got nil computer object for address XXX.XXX.XXX.XXX (change to protect client)

What is needed to be changed?
This change will not "stick". It makes no difference if I quit and reopen or if it sits idle for a random amount of time.

Mac Mini, Mac OS X (10.6.6)

Posted on Jan 13, 2011 2:26 PM

Reply

Answer 1

Jan 17, 2011 11:31 PM in response to macmurry

When you removed the entry, did you relaunch the app? If not, try that before adding the machine back into the computer database. If that doesn't work, you might try deleting the ~/Library/Preferences/com.apple.RemoteDesktop.plist. You'll have to re-add all your machines after this.

Reply

Answer 2

macmurry Author

Level 1

0 points

Jan 19, 2011 6:39 AM in response to CaptMrgnX

Yes, I have done this.
Same problem.
I do believe it stems from an issue with the SoncWall.
By the way it is no joy adding 19 additional computers back.

Reply

Answer 3

Jan 29, 2013 9:46 AM in response to macmurry

Hi Buddy,

Had the same issue and just resolved.

Firstly and pleasingly - it is nothing to do with ARD. Think you will also find Traceroute is not behaiving correctly to offending machines. It is to do with network hiding addresses. ie if you jump onto to an affected machine and got o whatismyip.com - will bet 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) to reflect the actual IP (non Nat'd IP) of the machine. This will solve your 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!

2 years late but you never know as it might help someone....

Reply