Sophos Endpoint Updates over https

This article provides examples and guidelines for situations in which there are multiple endpoint clients that never access the corporate network, either physically or via a VPN, but still need to be managed by Sophos Enterprise Console.

• Background
• Introduction
• Scenario 1: Message relay in a DMZ, using a public routable IP
• Scenario 2: Message relay in a DMZ, using a private non-routable IP
• Network Flow Walkthrough

Background
Sophos message relays are used to consolidate the policy and reporting data flowing between the Enterprise Console and client computers. They are also used to facilitate firewall rules, traffic management, and bandwidth. This article assumes the reader is familiar with Sophos message relays and their role within the Enterprise Console management structure.
For more information, or to set up a message relay, refer to the knowledgebase article Enterprise Console: configuring message relay computers

Sophos message relays are typically used to manage internal clients. These clients are usually on the corporate network, or a VPN, and have regular frequent network access to internal message relays, or the Enterprise Console directly.  If temporarily unavailable, messages to and from a client are cached on its message relay and the client respectively, until communication is re-established.

Introduction

The following scenarios provide guidelines for situations in which there are multiple endpoint clients that for various reasons never access the corporate network, either physically or via VPN, but still need to be managed by the Enterprise Console.

In these cases, it is possible for computers which never access the local network to be configured to communicate with the Sophos Management Console via a message relay located in a DMZ, rather than directly to the console or to an internal message relay. This improves accessibility and management of roaming laptops by providing a location which they should always be able to reach while on, or off, the corporate network.

The following cases give examples of hosting a service that is traditionally an internal network-facing role, on the internet. Although steps have been taken in order to prevent unauthorized systems from communicating with a message relay, it is beyond the scope of this article to give recommendations on hosting internet facing services, and securing Microsoft Windows servers for use in a DMZ.  

Steps should be taken to ensure that only legitimate traffic is allowed between clients and a message relay, as well as a message relay and the Enterprise Console, which may be on the internal corporate network.

Communication between clients, message relays and the Enterprise Console takes place via Sophos RMS on TCP ports 8192, 8193, and 8194.
For more information, refer to the knowledgebase article Sophos Anti-Virus for Windows: access to computers with firewalls.

Clients should be configured to communicate with a specific message relay upon installation. This is done by modifying the mrinit.conf file as described in the knowledgebase article Enterprise Console: configuring message relay computers, and more specifically in the following scenarios.
Note that these scenarios will result in one-way RMS communication, and while they will not cause any loss of functionality, they may slightly delay the delivery of policies and other endpoint instructions.

Scenario 1: Message relay in a DMZ, using a public routable IP

In this scenario, clients on the Remote Private Network have no VPN access to the ‘‘‘‘Private Corporate Network’’’’, and clients cannot communicate directly with the Management Server.

In such a scenario, a customer can configure all clients (or just remote clients) to use a message relay located in the DMZ, in order to facilitate communication with a console located on a corporate LAN.
Since RMS communicates on TCP ports 8192, 8193 and 8194, bidirectional traffic on these ports should be allowed between the message relay and the Management Server (including specific port forwarding, in the case of NAT) as well as inbound from the Internet to the message relay.
The Enterprise Console Management server and the message relay should be able to resolve each other via DNS.
In the above scenario, all clients that will use the message relay will need to be installed with an mrinit.conf file which includes the following:

"MRParentAddress"="192.168.0.3 ,[CONSOLE-FQDN],[CONSOLE-HOSTNAME]"
"ParentRouterAddress"="2.2.2.3,[MR-FQDN],[MR-HOSTNAME]"

This tells the client to use the router 2.2.2.3 as a message relay.

Scenario 2: Message relay in a DMZ, using a private non-routable IP

Should the DMZ use RFC 1928 IP addresses (192.168.0.0/16, 172.16.0.0/12, 10.0.0.0/8) a modification must be made to the message relay which changes the IOR message it provides the client.
A split DNS zone is also required, which resolves DNS names differently internally than externally.

Normally, when a client connects to a message relay or the console on port 8192, it will receive back an IOR string, containing the Message Relay’’’’s locally configured IP address. (In this case, 172.16.2.3)
Since the message relay’’’’s IP in this case is non-routable, a change is required so that the IP provided in the IOR is either routable, or is an FQDN.

In the above case, the message relay is named MR.domain.com, replace it with the FQDN for the message relay you will be using.

In our example, internally within the organization, MR.domain.com resolves to 172.16.2.3, an address that is routable between the Corporate Private Network and the DMZ.
Externally, MR.domain.com should resolve to 1.1.1.1, an address that is routable on the internet, and must have TCP ports 8192, 8193, and 8194 forwarded to 172.16.2.3.

How to change the message relay to make it return an FQDN in the IOR string:
This procedure must be performed on the message relay

WARNING:  Make a backup of the registry (or the necessary keys below) before changing the data values.

Replace all example values, with values that reflect your organization.

• To immediately affect the service:

1.  
   1. Modify the key HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Sophos Message Router\ImagePath
      to the following (all one line):
      
      "C:\Program Files\Sophos\Remote Management System\RouterNT.exe" -service -name Router -ORBDottedDecimalAddresses 0 -ORBListenEndpoints iiop://:8193/ssl_port=8194&hostname_in_ior=MR.domain.com
   2. Restart the Message Router service on the message relay.

• To make the change persistent when an RMS update/reinstall occurs:

Modify the key HKEY_LOCAL_MACHINE\SOFTWARE\Sophos\Messaging System\Router\ServiceArgs
to the following (all one line):

-ORBDottedDecimalAddresses 0 -ORBListenEndpoints iiop://:8193/ssl_port=8194&hostname_in_ior=MR.domain.com

Additional configuration and information for this scenario

• All clients using the external message relay need to be installed using an mrinit.conf file which includes the following:

"MRParentAddress"="192.168.0.3 ,[Console-FQDN],[Console-HOSTNAME]"
"ParentRouterAddress"="MR.domain.com”

This tells the clients to use MR.domain.com as a relay.

• TCP Ports 8192, 8193, and 8194 should be port-forwarded from the external IP: 1.1.1.1 to the message relay IP: 172.16.2.3

Internal communication on these ports between the 192.168.0.x and 172.16.2.x networks should also be allowed through the firewall, and be routable.

• The Enterprise Console management server and the message relay should be able to resolve each other via DNS to their actual IP addresses, not the external IP addresses.
  
• In this example, the message relay needs to resolve CONSOLE-FQDN.domain.com to 192.168.0.3, and both the Enterprise Console Management Server and the message relay need to resolve MR.domain.com to 172.16.2.3.

Network Flow Walkthrough

Assuming all clients (internal and external) have been configured to use one message relay:

Walkthrough – Internal clients:

1. Upon install an internal (192.168.0.x) client will read mrinit.conf, know that its message relay is MR.domain.com, and resolve it (from the Internal DNS server) to 172.16.2.3
2. It will then connect to the message relay on 172.16.2.3:8192, and receive an IOR.
   The IOR will contain the next IP and port to communicate on, and since the Registry keys were changed above to provide an FQDN instead of an IP, the IOR will contain MR.domain.com, and 8194 as the port.
3. The Client will then connect to MR.domain.com (172.16.2.3) on port 8194, and will have RMS messages passing through the message relay, to the console and back.

Walkthrough – External clients:

1. Upon install an external (192.168.1.x) client will read mrinit.conf, know that its message relay is MR.domain.com, and resolve it (from the External DNS server) to 1.1.1.1.
2. It will then connect to the message relay on 1.1.1.1:8192, get port forwarded to 172.16.2.3:8192, and receive an IOR.  The IOR will contain the next IP and port to communicate on, and since the Registry keys were changed above to provide an FQDN instead of an IP, the IOR will contain MR.domain.com, and 8194 as the port.
3. The Client will then connect to MR.domain.com (1.1.1.1) on 8194, get port forwarded to 172.16.2.3:8194, and will have RMS messages passing through the message relay, to the console and back.

This article provides examples and guidelines for situations in which there are multiple endpoint clients that never access the corporate network, either physically or via a VPN, but still need to be managed by Sophos Enterprise Console.

• Background
• Introduction
• Scenario 1: Message relay in a DMZ, using a public routable IP
• Scenario 2: Message relay in a DMZ, using a private non-routable IP
• Network Flow Walkthrough

Background
Sophos message relays are used to consolidate the policy and reporting data flowing between the Enterprise Console and client computers. They are also used to facilitate firewall rules, traffic management, and bandwidth. This article assumes the reader is familiar with Sophos message relays and their role within the Enterprise Console management structure.
For more information, or to set up a message relay, refer to the knowledgebase article Enterprise Console: configuring message relay computers

Sophos message relays are typically used to manage internal clients. These clients are usually on the corporate network, or a VPN, and have regular frequent network access to internal message relays, or the Enterprise Console directly.  If temporarily unavailable, messages to and from a client are cached on its message relay and the client respectively, until communication is re-established.

Introduction

The following scenarios provide guidelines for situations in which there are multiple endpoint clients that for various reasons never access the corporate network, either physically or via VPN, but still need to be managed by the Enterprise Console.

In these cases, it is possible for computers which never access the local network to be configured to communicate with the Sophos Management Console via a message relay located in a DMZ, rather than directly to the console or to an internal message relay. This improves accessibility and management of roaming laptops by providing a location which they should always be able to reach while on, or off, the corporate network.

The following cases give examples of hosting a service that is traditionally an internal network-facing role, on the internet. Although steps have been taken in order to prevent unauthorized systems from communicating with a message relay, it is beyond the scope of this article to give recommendations on hosting internet facing services, and securing Microsoft Windows servers for use in a DMZ.  

Steps should be taken to ensure that only legitimate traffic is allowed between clients and a message relay, as well as a message relay and the Enterprise Console, which may be on the internal corporate network.

Communication between clients, message relays and the Enterprise Console takes place via Sophos RMS on TCP ports 8192, 8193, and 8194.
For more information, refer to the knowledgebase article Sophos Anti-Virus for Windows: access to computers with firewalls.

Clients should be configured to communicate with a specific message relay upon installation. This is done by modifying the mrinit.conf file as described in the knowledgebase article Enterprise Console: configuring message relay computers, and more specifically in the following scenarios.
Note that these scenarios will result in one-way RMS communication, and while they will not cause any loss of functionality, they may slightly delay the delivery of policies and other endpoint instructions.

Scenario 1: Message relay in a DMZ, using a public routable IP

In this scenario, clients on the Remote Private Network have no VPN access to the ‘‘‘‘Private Corporate Network’’’’, and clients cannot communicate directly with the Management Server.

In such a scenario, a customer can configure all clients (or just remote clients) to use a message relay located in the DMZ, in order to facilitate communication with a console located on a corporate LAN.
Since RMS communicates on TCP ports 8192, 8193 and 8194, bidirectional traffic on these ports should be allowed between the message relay and the Management Server (including specific port forwarding, in the case of NAT) as well as inbound from the Internet to the message relay.
The Enterprise Console Management server and the message relay should be able to resolve each other via DNS.
In the above scenario, all clients that will use the message relay will need to be installed with an mrinit.conf file which includes the following:

"MRParentAddress"="192.168.0.3 ,[CONSOLE-FQDN],[CONSOLE-HOSTNAME]"
"ParentRouterAddress"="2.2.2.3,[MR-FQDN],[MR-HOSTNAME]"

This tells the client to use the router 2.2.2.3 as a message relay.

Scenario 2: Message relay in a DMZ, using a private non-routable IP

Should the DMZ use RFC 1928 IP addresses (192.168.0.0/16, 172.16.0.0/12, 10.0.0.0/8) a modification must be made to the message relay which changes the IOR message it provides the client.
A split DNS zone is also required, which resolves DNS names differently internally than externally.

Normally, when a client connects to a message relay or the console on port 8192, it will receive back an IOR string, containing the Message Relay’’’’s locally configured IP address. (In this case, 172.16.2.3)
Since the message relay’’’’s IP in this case is non-routable, a change is required so that the IP provided in the IOR is either routable, or is an FQDN.

In the above case, the message relay is named MR.domain.com, replace it with the FQDN for the message relay you will be using.

In our example, internally within the organization, MR.domain.com resolves to 172.16.2.3, an address that is routable between the Corporate Private Network and the DMZ.
Externally, MR.domain.com should resolve to 1.1.1.1, an address that is routable on the internet, and must have TCP ports 8192, 8193, and 8194 forwarded to 172.16.2.3.

How to change the message relay to make it return an FQDN in the IOR string:
This procedure must be performed on the message relay

WARNING:  Make a backup of the registry (or the necessary keys below) before changing the data values.

Replace all example values, with values that reflect your organization.

• To immediately affect the service:

1.  
   1. Modify the key HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Sophos Message Router\ImagePath
      to the following (all one line):
      
      "C:\Program Files\Sophos\Remote Management System\RouterNT.exe" -service -name Router -ORBDottedDecimalAddresses 0 -ORBListenEndpoints iiop://:8193/ssl_port=8194&hostname_in_ior=MR.domain.com
   2. Restart the Message Router service on the message relay.

• To make the change persistent when an RMS update/reinstall occurs:

Modify the key HKEY_LOCAL_MACHINE\SOFTWARE\Sophos\Messaging System\Router\ServiceArgs
to the following (all one line):

-ORBDottedDecimalAddresses 0 -ORBListenEndpoints iiop://:8193/ssl_port=8194&hostname_in_ior=MR.domain.com

Additional configuration and information for this scenario

• All clients using the external message relay need to be installed using an mrinit.conf file which includes the following:

"MRParentAddress"="192.168.0.3 ,[Console-FQDN],[Console-HOSTNAME]"
"ParentRouterAddress"="MR.domain.com”

This tells the clients to use MR.domain.com as a relay.

• TCP Ports 8192, 8193, and 8194 should be port-forwarded from the external IP: 1.1.1.1 to the message relay IP: 172.16.2.3

Internal communication on these ports between the 192.168.0.x and 172.16.2.x networks should also be allowed through the firewall, and be routable.

• The Enterprise Console management server and the message relay should be able to resolve each other via DNS to their actual IP addresses, not the external IP addresses.
  
• In this example, the message relay needs to resolve CONSOLE-FQDN.domain.com to 192.168.0.3, and both the Enterprise Console Management Server and the message relay need to resolve MR.domain.com to 172.16.2.3.

Network Flow Walkthrough

Assuming all clients (internal and external) have been configured to use one message relay:

Walkthrough – Internal clients:

1. Upon install an internal (192.168.0.x) client will read mrinit.conf, know that its message relay is MR.domain.com, and resolve it (from the Internal DNS server) to 172.16.2.3
2. It will then connect to the message relay on 172.16.2.3:8192, and receive an IOR.
   The IOR will contain the next IP and port to communicate on, and since the Registry keys were changed above to provide an FQDN instead of an IP, the IOR will contain MR.domain.com, and 8194 as the port.
3. The Client will then connect to MR.domain.com (172.16.2.3) on port 8194, and will have RMS messages passing through the message relay, to the console and back.

Walkthrough – External clients:

1. Upon install an external (192.168.1.x) client will read mrinit.conf, know that its message relay is MR.domain.com, and resolve it (from the External DNS server) to 1.1.1.1.
2. It will then connect to the message relay on 1.1.1.1:8192, get port forwarded to 172.16.2.3:8192, and receive an IOR.  The IOR will contain the next IP and port to communicate on, and since the Registry keys were changed above to provide an FQDN instead of an IP, the IOR will contain MR.domain.com, and 8194 as the port.
3. The Client will then connect to MR.domain.com (1.1.1.1) on 8194, get port forwarded to 172.16.2.3:8194, and will have RMS messages passing through the message relay, to the console and back.