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.