Port 402 is used to connect, but the client uses a random port to connect back... I found this information in the documentation;

'Remote control via Console to Deployment Agent for Windows (AClient)

This process uses IP and doesnít use a specific port. The Windows

operating system picks a free port number to use. That port number is

sent to the client and the client makes another connection back to the

console on that port. Remote control uses dynamic ports much the same

as file copy. Consequently, if file copy works, remote control should also

work.'

This doesn't help me as it is an untrusted network we are connecting to. It would conflict our (and I would imagine most other organisations) security policies in order to allow TCP connectivity on random ports back from this network. This is why I want to restrict the connectivity back to a specified port.

By default, these comms are on dynamic ports. When performing a remote control  task , the server sends a request to the aclient on port 402 to indicate that a session has been requested. This AClient communication also  contains the tcp port the server has selected for the remote control session.

This way, the server and the client can communicate on the correct port.

For servers behind firewalls, this can be a problem.  Altiris provides for this by allowing you to fix the tcp comms to a static port.

In the Console, navigate to Tools -> Options. On the Global tab, you'll find the option to set the Primary and Secondary Remote Control Ports. In this tab,  notice this is where the Client/Server file transfer port is also configured.

Kind Regards,
Ian./

Hi there,

I followed Stu's link to the knowledge base and set the DC comms port to be TCP 1505. I then allowed this port back through the firewall from the curriculum network to our adminstrator network range. This allowed connectivity back on the specified port.

I used wireshark to make sure the destination port was always 1505 and tested various different client connections to make sure that this worked correctly, which it did...

I also set the file transfer/copy port to a designated port also and updated the agents to see if this also worked, which again it did...

Thanks for your help on this, the connections are now tied to ports and as a PIX admin I am happier with this way than allowing random ports above TCP 1024!

Cheers,

Ed