Client Management Suite

 View Only
  • 1.  CEM - Communication Topology and Ports Confirmation

    Posted Jun 18, 2015 09:07 AM

    All,

    We are in the beginning phases of our CEM implementation in 7.5 SP1 HF5 and have a few questions that I couldn’t exactly get from the white papers and forum posts.

    I have attached an image of how we think the communication goes between the Internet Gateway, SMP, Site Server, and Clients.

    We are mainly concerned with getting the direction of communications and the ports that are actually used.  This is due to our internal DMZ/Firewall request process is strict and needs exact ports/protocols/destinations IP’s that come from the DMZ side inside our internal network.

    By default we let nothing through obviously, so when we put this new CEM internet gateway in our DMZ we will need to punch holes for any port it might ever use, this included basic ones inherent to Windows ( RDP, DNS, LDAP, etc..) as well as the application ones used.

    CEM Topology.jpg

    Do the ports and where they need to go look correct?

    As of now our firewall request forms looks similar to this:

    Source                  Destination         Port(s) Required(TCP/25, UDP/514, etc.)   Protocol Used (SMTP, Syslog, etc)                Communication Path

    10.9.100.100       10.8.100.100       tcp/443                                                                   HTTPS                                                                 One Way with Reply

    10.9.100.100       10.8.100.100       tcp/4726                                                                CEM                                                                     One way with reply

    10.9.100.100       10.8.100.101       tcp/443                                                                   HTTPS                                                                 One Way with Reply

     

    I wasn’t sure how the communication works with a CEM Client and the Site Servers so not sure if all the Task Management ports needs to be able to reach the internet Gateway (50120,50121,50122,50123,50124) ??

     

    I just don’t want to have to keep resubmitting firewall requests as we run into issues since they all have to go through our security office.

     

    Thanks,

    Clay



  • 2.  RE: CEM - Communication Topology and Ports Confirmation

    Posted Jun 18, 2015 11:19 AM

    That looks like what we have. One way with reply is what we did on our firewalls. Once it establishes one way it will accept the other. We didn't open any extra ports except what was required by CEM and, at least in our case, the Task Mgmt ports worked with nothing opened specifically for them. How do you plan on distributing your CEM-enabled agents and certs? We distributed the certificates via GP so any new machines that come online will get it.

    Existing machines that were outside of the network either needed to be touched manually or we leveraged the outgoing (as in not signing a new contract) managed client management system that used Kaseya.

    We ran into an issue were the system-built (When the SMP was built) certificates were either damaged or somehow stripped of their key. CEM relies on those so make sure they are intact.

     

    See these docs:

    https://www-secure.symantec.com/connect/articles/how-install-cem-functionality-smp-75-sp1

    https://www-secure.symantec.com/connect/articles/about-different-cases-troubleshooting-cem-functionality

    These were created during our implementation by Symantec with great help from Igor Perevozchikov at Symantec.

     

     



  • 3.  RE: CEM - Communication Topology and Ports Confirmation

    Posted Jun 18, 2015 03:16 PM

    tloenhorst

    Thank you for the reply.

    Yes I have both Igors documents and other articles bookmarked for once we get our certificate sign form our CA and the firewall request in place.

    We will be using GPO's to distribute the certificate to all cleints and just turn on HTTPS for a small amount of clients at first then eventually all laptops.  We have not planned on converting all internal communication to HTTPS.

     

    Thanks,

    Clay