1 Reply Latest reply on Feb 18, 2013 5:23 AM by BlairK

    LANDesk Using Legacy Ports for Agent Discovery?

    Rookie

      Hello all,

       

      Having issues with sending updated Scan and Repair settings via either scheduled jobs or policy pushes over firewalls.

       

      We have a number of systems that have to be managed over firewalls by our LANDesk cores. We are having problems with only a small number of these systems.

       

      On the firewall, I see that UDP port 38293 is being blocked. Great, open firewall up and problem is solved, right?

       

      Issue with that is that UDP 38293 is supposed to be a legacy LANDesk port that is no longer used in versions 8 or higher and isn't even listed in the latest port list.

       

      So question is, why is LANDesk still using this port and how do I force our cores to use TCP for discovery instead?

       

      By the way, I should point out that I set the cores to only use TCP for discovery and the UDP port still gets used. Pretty annoying.

       

      Hopefully, someone has some insights.

       

      Thanks

        • 1. Re: LANDesk Using Legacy Ports for Agent Discovery?
          Apprentice

          Hi,

           

          UDP is always used as a default by the core and delivery methods as generally its a faster device discovery mechanism when targeting lots of devices.

          If you disable it then the task will use a TCP port but it actually results in a HTTP connection to each system. For systems that are off or non discoverable each HTTP connection attempt waits for a timeout and therefore the tasks can run a lot slower. It states this in the LANDesk help file and I can see it in wireshark. Bear this in mind if you don't want to use UDP.

           

          Did you disable the UDP option both in configure services on the core and the delivery method(s) used for the scheduled task? Each delivery method has its own discovery setting. See the screenshots. If you don't want to use UDP discovery you can disable these options. Unless even with both these checked something hardcoded is still trying to use that port. I'd have to run some wireshark tests to prove that.

           

          You will need to make sure TCP ports 9593, 9594 and 9595 are open in the firewall between core and clients for your discovery and tasks to work.

           

          Regards

          Blair