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

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

Hi Alex,

Can you confirm the server returns an FQDN in the IOR as Christian mentioned?  You can do this by using telnet client or Putty to telnet to the ParentRouterAddress on port 8192.
Eg. "telnet mr.domain.com 8192"

You should get an IOR that you can copy and paste into an IOR parser such as catior. If not "How to change the message relay to make it return an FQDN in the IOR string" needs to be followed in Sophos Enterprise Console: How to use Sophos message relays in a public WAN.

This FQDN should resolve to 192.168.0.3 internally and 55.69.74.22 externally.

This old post of mine might help:

https://community.sophos.com/products/endpoint-security-control/f/sophos-endpoint-software/3154/configure-endpoint-server-10-with-rms-behind-a-firewall-nat-don-t-want-to-use-message-relay

Thanks, this helped!  Got it to work!!

Thanks, this helped!  Got it to work!!