This discussion has been locked.
You can no longer post new replies to this discussion. If you have a question you can start a new discussion

How to connect outside-of-network endpoints/clients to sophos enterprise console?

Hi guys,

I've been doing a ton of research and am still at a lost on how to proceed.  We currently have Sophos Enterprise Console and endpoints only show up when they are connected to the network either directly or on VPN.  We are having issues because a lot of our users work from home and do not contact the console until they reconnect to the VPN (if at all).  We also have some servers that cannot connect to the VPN.  

How do we get endpoints to contact the console when not connected to the network?  I've read about message relay but still don't completely understand that.  Can someone dummy it down for me, if that's the only way?

Thanks!



This thread was automatically locked due to age.
  • Hi Alex,

    You can set up a publicly available server that will forward all Sophos endpoint communications to the Enterprise Console.  The endpoints will and can always connect to this publicly available server, whether inside the network or out.  It would be Scenario 1 in this KBA: community.sophos.com/.../50832

  • It is possible but does require some work.  Would you consider Sophos Central - The cloud based management platform? Then it's all done for you :)

    Do you have plans to move to Sophos Central?  If this is a fixed set of assets that are always remote, would it be worth calling sales to see if you could convert some of your existing on-prem licences to Central ones.  I'm not sure this is possible but I would think they would encourage a migration to Central.  It also gives better protection and a more complete EP solution than on-premise.  Could these users be some sort of pilot?

    Regards,
    Jak

  • Hi Dianney.  Thanks for the reply.  I've never set up a DMZ or a message relay before.  

  • jak said:

    It is possible but does require some work.  Would you consider Sophos Central - The cloud based management platform? Then it's all done for you :)

    Do you have plans to move to Sophos Central?  If this is a fixed set of assets that are always remote, would it be worth calling sales to see if you could convert some of your existing on-prem licences to Central ones.  I'm not sure this is possible but I would think they would encourage a migration to Central.  It also gives better protection and a more complete EP solution than on-premise.  Could these users be some sort of pilot?

    Regards,
    Jak

     

     

    hi Jak,

    We had a demo on Sophos Central and was a bit more costly than what we'd like to spend on it.  I am able to update from a WebCID but that machine is not showing up in our enterprise console.  Any idea why?

  • MEric said:

    Hi Alex,

    You can set up a publicly available server that will forward all Sophos endpoint communications to the Enterprise Console.  The endpoints will and can always connect to this publicly available server, whether inside the network or out.  It would be Scenario 1 in this KBA: community.sophos.com/.../50832

     

     

    Hi Meric,

    I am able to update from the Web CID but still not able to retrieve the machine information in the console.  There's gotta be an easier way to pull this info, right?

  • Hello Alex Plevell,

    first of all, a summary of the concept

    • Updating and showing up (i.e. management communication) are distinct functions
    • Updating is either from a UNC location (SMB/NetBIOS) or a WebCID (HTTP)
    • Communication uses ports 8192 and 8194

    How do we get endpoints to contact the console when not connected to the network?
    How do your endpoints update when not connected to the network? from the Web CID suggests that either
     a) your SEC has a public IP and at least port 80 is open to the Internet
     b) you are NATting and/or port-forwarding
     c) you have a dedicated public webserver that publishes the CID

    In order to be able to manage outside endpoints you could
     a) additionally open ports 8192 and 8194
     b) open/forward these ports
     c) configure the webserver as relay (naturally its ports 8192 and 8194 must also be open)

    Christian

  • QC said:

    Hello Alex Plevell,

    first of all, a summary of the concept

    • Updating and showing up (i.e. management communication) are distinct functions
    • Updating is either from a UNC location (SMB/NetBIOS) or a WebCID (HTTP)
    • Communication uses ports 8192 and 8194

    How do we get endpoints to contact the console when not connected to the network?
    How do your endpoints update when not connected to the network? from the Web CID suggests that either
     a) your SEC has a public IP and at least port 80 is open to the Internet
     b) you are NATting and/or port-forwarding
     c) you have a dedicated public webserver that publishes the CID

    In order to be able to manage outside endpoints you could
     a) additionally open ports 8192 and 8194
     b) open/forward these ports
     c) configure the webserver as relay (naturally its ports 8192 and 8194 must also be open)

    Christian

     

     

    Hi Christian,

    Ports are opened on the firewall and on the server and are being forwarded from the public IP to the private IP.  I can download updates but the machine does not show up in the console :(

  • Hello Alex Plevell,

    if 8192 and 8194 are open/forwarded but the endpoints can't communicate then likely mrinit.conf and/or the IOR the server returns need some amendment.

    mrinit.conf is created during install and normally contains "MRParentAddress|ParentRouterAddress"="CONSOLE-IPv4[,CONSOLE-IPv6],CONSOLE-FQDN,CONSOLE-HOSTNAME.

    Step1: The endpoints try to connect to port 8192 using the addresses and names as specified.
    Presumably the addresses are private and won't work from the outside, nor will CONSOLE-HOSTNAME. Depending on your network and DNS CONSOLE-FQDN could be just CONSOLE-HOSTNAME, an internal FQDN (e.g. secserver.acme.local), or a publicly resolvable FQDN (e.g. secserver.acme.com). If it's not the latter the endpoints will already fail at this step.

    Step2: In case the FQDN is resolvable the endpoints will receive an IOR from the server. Basically an IOR tells a client where to find a certain "object" - in this case the Remote Management Service, notably the host (server and port). Normally the server advertises its IP in the reply - in your setup this would be the local IP, and this is of no use to the outside endpoints. Thus you have to tell the server to return its FQDN in the reply. Please note that this FQDN must either resolve to the private IP for the internal endpoints or the internal endpoints must be able to connect to the server using its public IP.

    Christian 

  • QC said:

    Hello Alex Plevell,

    if 8192 and 8194 are open/forwarded but the endpoints can't communicate then likely mrinit.conf and/or the IOR the server returns need some amendment.

    mrinit.conf is created during install and normally contains "MRParentAddress|ParentRouterAddress"="CONSOLE-IPv4[,CONSOLE-IPv6],CONSOLE-FQDN,CONSOLE-HOSTNAME.

    Step1: The endpoints try to connect to port 8192 using the addresses and names as specified.
    Presumably the addresses are private and won't work from the outside, nor will CONSOLE-HOSTNAME. Depending on your network and DNS CONSOLE-FQDN could be just CONSOLE-HOSTNAME, an internal FQDN (e.g. secserver.acme.local), or a publicly resolvable FQDN (e.g. secserver.acme.com). If it's not the latter the endpoints will already fail at this step.

    Step2: In case the FQDN is resolvable the endpoints will receive an IOR from the server. Basically an IOR tells a client where to find a certain "object" - in this case the Remote Management Service, notably the host (server and port). Normally the server advertises its IP in the reply - in your setup this would be the local IP, and this is of no use to the outside endpoints. Thus you have to tell the server to return its FQDN in the reply. Please note that this FQDN must either resolve to the private IP for the internal endpoints or the internal endpoints must be able to connect to the server using its public IP.

    Christian 

     

     

    Thanks for the reply, Christian!  Based on the guide you linked, I followed it (without the DMZ) and have the following configuration