RMS client not reporting.

Hi,

I'll explain how it works from what I know.  That garbage is the IOR (Interoperable Object Reference) of the parent router.  This IOR string contains within it, among other things, information the client uses to connect back to the parent router.  The handshake is as follows:

1. The client, by using the registry keys:

HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Sophos\Messaging System\Router

ParentAddress

ParentPort

Is able to find the IOR port of the parent router.

2. This IOR is read by the client router process. Within it are the IP addresses of the server and the SSL port being used, by default this is 8194.  So for a parent router, with 5 IP addresses, it will be a longer string.

Here is one IOR parser, I've found on the net with Google should you wish to take a look at it.

http://www2.parc.com/istl/projects/ILU/parseIOR/. This will show you the IP addresses and the ports encoded within.  Within the CORBA world there is a more official tool called catior.exe that will pass it.

3. With this new information, the client router is then able to connect back to the IP address and SSL port of the parent router.

Obviously if you have a parent router that has an IP in multiple networks for example.  The client router might first try connecting back to an IP address and port that is un-routable but it will go through the list of IPs and should finally make a connection to the server on port 8194.

Note: Because of this possible delay when multiple IP addresses are in play (does anyone remember Rupert the Bear!), it's for this reason the Upgrade Advisor tool warns that messaging might be delayed, primarily for this bootstrap procedure of the client finding 8194 on the right IP of the server.

For some setups, i.e, if the parent router is managing clients in multiple networks and does indeed need to host multiple IPs in the IOR this delay will have to be there.  However if the parent router only needs to talk to clients in one of the networks I would suggest following:

http://www.sophos.com/support/knowledgebase/article/12507.html

as a way of binding the router to listen on just one interface.  This will essentially mean it only has that IP in the IOR.

So the above stages occur each time the client router starts up as a way of establishing a connection to 8194 of the parent router.  As a bit of further information, with regards to the certification process which happens when the client is still being set-up for the first time (until the client has its certificates).

The client router is now connected to port 8194 but it has no certificate. So whilst logged onto the certification interface of the parent router, it makes a token request.  This token in just a number the system appends to the RMS address of the client to ensure that the address is unique in the system.  As the rest of the RMS address is formed based on the machine name, there could be multiple machines with the same name in the system.  So this token request is passed from client router to parent router, and is serviced by the Certification Manager on the management server.

Once the client has it's token it requests a certificate.  Again it does this by sending a cert request message to the parent router and again it's serviced by the Certification Manager on the management server.  This certificate is then polled for by the client.  

You can see the router cert under:

HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Sophos\Messaging System\Router\Private

The client router then receives its certificate and at this point can set-up its own IOR, which essentially means the client starts listening on port 8192 or whatever is defined in the key:

HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Sophos\Messaging System\Router

IORSenderPort

So a Telnet to the client router on port 8192, is essentially testing that the router has a certificate and is hosting the IOR.

This now enables the Management Agent service on the client to connect to the local router (it's been trying to establish a connection to port 8192 the whole time and failing but now it can) and make it's own certificate request via the client router, again this is send as a certification request message up to the parent router and on to the Certification Manager on the management server.  The server router then attempts to send the certificate to the client router.  

Once the management agent obtains its certificate; as visible now under:

HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Sophos\Remote Management System\ManagementAgent\Private\

it logs on to the client interface of its local router and is then able to report the status of the client with respect to the management clients.  The EM-GetStatus-Reply message it sends at this stage is the one responsible for the client appearing in SEC with details about the computer.

That's a rough overview of the procedure that is happening and as a couple of points to take from it:

1. The only components that talk across the network are the routers.  RouterNT.exe.  

2. You need to ensure that port 8192 TCP and 8194 TCP incoming are open on the server.

3. You should open port 8194 TCP incoming on the client.  I say should, as the system will cope if the server cannot connect to the client but it is then reliant on the client polling for messages which can delay the client getting messages by the polling interval or "GetterInterval" as it can be seen under the key:

HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Sophos\Messaging System\Router

4. If the client machine doesn't have a pkc and pkp value under:

HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Sophos\Remote Management System\ManagementAgent\Private

it will not be managed in SEC.

I hope this helps explain a little as to what is going on under the hood.

That being said, I would expect in your case the IOR of the parent router has a non routable address in it.  The system will cope fine if the client is behind a NAT, as the client can always find the server but in this case, where the server is behind a NAT the client doesn't have a chance based on the IP address given to it in the IOR.  To work around this, the IOR needs to be modified with something the client can resolve and ensure it can find port 8194 on the parent.  This can be done by passing the switch hostname_in_ior to the parent router as detailed in this article:

http://www.sophos.com/support/knowledgebase/article/50832.html

Once you have modified the IOR of the router, it is important that both the client can resolve the address and so can the local clients and routers that are connecting to it.

One example of this is if the parent router sits behind a device which is port forwarding ports 8192 and 8194 to the router.  The router may have the IP address 192.168.1.100, the device in front of it might have an external interface and an internal one, e.g. 82.54.34.34 and 192.168.1.1.  So you point the client at 82.54.34.34 on port 8192 to read the IOR, this essentially then makes a transparent connection to 192.168.1.100 on port 8192.  All looks good, however, the client router is going to read back from the IOR, IP 192.168.1.100 and port 8194.  Of course the reconnect back to that will be unresolvable.  Thinking about it, it could be resolvable and the client ends up pointing at some other router on a local network to the client.  If that happens to have the same certificates it could start to use that, sounds a bit like a message relay has been born anyway I digress a bit. So the only way this will work is if the address in the IOR resolves to 82.54.34.34 in this case.

Wow, that could be my longest post ever.  Hopefully that hasn't put anyone to sleep!

Jak

Hi,

I'll explain how it works from what I know.  That garbage is the IOR (Interoperable Object Reference) of the parent router.  This IOR string contains within it, among other things, information the client uses to connect back to the parent router.  The handshake is as follows:

1. The client, by using the registry keys:

HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Sophos\Messaging System\Router

ParentAddress

ParentPort

Is able to find the IOR port of the parent router.

2. This IOR is read by the client router process. Within it are the IP addresses of the server and the SSL port being used, by default this is 8194.  So for a parent router, with 5 IP addresses, it will be a longer string.

Here is one IOR parser, I've found on the net with Google should you wish to take a look at it.

http://www2.parc.com/istl/projects/ILU/parseIOR/. This will show you the IP addresses and the ports encoded within.  Within the CORBA world there is a more official tool called catior.exe that will pass it.

3. With this new information, the client router is then able to connect back to the IP address and SSL port of the parent router.

Obviously if you have a parent router that has an IP in multiple networks for example.  The client router might first try connecting back to an IP address and port that is un-routable but it will go through the list of IPs and should finally make a connection to the server on port 8194.

Note: Because of this possible delay when multiple IP addresses are in play (does anyone remember Rupert the Bear!), it's for this reason the Upgrade Advisor tool warns that messaging might be delayed, primarily for this bootstrap procedure of the client finding 8194 on the right IP of the server.

For some setups, i.e, if the parent router is managing clients in multiple networks and does indeed need to host multiple IPs in the IOR this delay will have to be there.  However if the parent router only needs to talk to clients in one of the networks I would suggest following:

http://www.sophos.com/support/knowledgebase/article/12507.html

as a way of binding the router to listen on just one interface.  This will essentially mean it only has that IP in the IOR.

So the above stages occur each time the client router starts up as a way of establishing a connection to 8194 of the parent router.  As a bit of further information, with regards to the certification process which happens when the client is still being set-up for the first time (until the client has its certificates).

The client router is now connected to port 8194 but it has no certificate. So whilst logged onto the certification interface of the parent router, it makes a token request.  This token in just a number the system appends to the RMS address of the client to ensure that the address is unique in the system.  As the rest of the RMS address is formed based on the machine name, there could be multiple machines with the same name in the system.  So this token request is passed from client router to parent router, and is serviced by the Certification Manager on the management server.

Once the client has it's token it requests a certificate.  Again it does this by sending a cert request message to the parent router and again it's serviced by the Certification Manager on the management server.  This certificate is then polled for by the client.  

You can see the router cert under:

HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Sophos\Messaging System\Router\Private

The client router then receives its certificate and at this point can set-up its own IOR, which essentially means the client starts listening on port 8192 or whatever is defined in the key:

HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Sophos\Messaging System\Router

IORSenderPort

So a Telnet to the client router on port 8192, is essentially testing that the router has a certificate and is hosting the IOR.

This now enables the Management Agent service on the client to connect to the local router (it's been trying to establish a connection to port 8192 the whole time and failing but now it can) and make it's own certificate request via the client router, again this is send as a certification request message up to the parent router and on to the Certification Manager on the management server.  The server router then attempts to send the certificate to the client router.  

Once the management agent obtains its certificate; as visible now under:

HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Sophos\Remote Management System\ManagementAgent\Private\

it logs on to the client interface of its local router and is then able to report the status of the client with respect to the management clients.  The EM-GetStatus-Reply message it sends at this stage is the one responsible for the client appearing in SEC with details about the computer.

That's a rough overview of the procedure that is happening and as a couple of points to take from it:

1. The only components that talk across the network are the routers.  RouterNT.exe.  

2. You need to ensure that port 8192 TCP and 8194 TCP incoming are open on the server.

3. You should open port 8194 TCP incoming on the client.  I say should, as the system will cope if the server cannot connect to the client but it is then reliant on the client polling for messages which can delay the client getting messages by the polling interval or "GetterInterval" as it can be seen under the key:

HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Sophos\Messaging System\Router

4. If the client machine doesn't have a pkc and pkp value under:

HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Sophos\Remote Management System\ManagementAgent\Private

it will not be managed in SEC.

I hope this helps explain a little as to what is going on under the hood.

That being said, I would expect in your case the IOR of the parent router has a non routable address in it.  The system will cope fine if the client is behind a NAT, as the client can always find the server but in this case, where the server is behind a NAT the client doesn't have a chance based on the IP address given to it in the IOR.  To work around this, the IOR needs to be modified with something the client can resolve and ensure it can find port 8194 on the parent.  This can be done by passing the switch hostname_in_ior to the parent router as detailed in this article:

http://www.sophos.com/support/knowledgebase/article/50832.html

Once you have modified the IOR of the router, it is important that both the client can resolve the address and so can the local clients and routers that are connecting to it.

One example of this is if the parent router sits behind a device which is port forwarding ports 8192 and 8194 to the router.  The router may have the IP address 192.168.1.100, the device in front of it might have an external interface and an internal one, e.g. 82.54.34.34 and 192.168.1.1.  So you point the client at 82.54.34.34 on port 8192 to read the IOR, this essentially then makes a transparent connection to 192.168.1.100 on port 8192.  All looks good, however, the client router is going to read back from the IOR, IP 192.168.1.100 and port 8194.  Of course the reconnect back to that will be unresolvable.  Thinking about it, it could be resolvable and the client ends up pointing at some other router on a local network to the client.  If that happens to have the same certificates it could start to use that, sounds a bit like a message relay has been born anyway I digress a bit. So the only way this will work is if the address in the IOR resolves to 82.54.34.34 in this case.

Wow, that could be my longest post ever.  Hopefully that hasn't put anyone to sleep!

Jak