Sophos Endpoint Public RMS cannot get certificate

Sophos Endpoint Public RMS cannot get certificate 
we're using Public ip address that is nat'd to private ip address, we've changed some configuration based on this KB methode 2 https://community.sophos.com/kb/en-us/50832
the ssl connection is trying to connect to private ip of SEC (192.168.12.80) using port 51285 (i don't know what port is this) , anyone know how to solve this ? 

see the following log : 
02.09.2019 17:19:52 0960 T C:\Program Files\Sophos\Remote Management System\RouterNT.exe|<<< StatusReporting::StatusReporter::Done
02.09.2019 17:19:52 0960 I C:\Program Files\Sophos\Remote Management System\RouterNT.exe|Getting a new router certificate...
02.09.2019 17:19:52 0960 D C:\Program Files\Sophos\Remote Management System\RouterNT.exe|Getting the parent message router object using IOR
IOR:010000002600000049444c3a536f70686f734d6573736167696e672f4d657373616765526f757465723a312e300000000100000000000000a4000000010102000e0000003139322e3136382e31322e38300054c84100000014010f004e5550000000210000000001000000526f6f74504f4100526f7574657250657273697374656e740003000000010000004d657373616765526f7574657200000003000000000000000800000001009702004f4154010000001800000001009702010001000100000001000105090101000000000014000000080000000100a600860055c8
02.09.2019 17:19:52 0960 D C:\Program Files\Sophos\Remote Management System\RouterNT.exe|TAO (5604|2400) - Stub::base_profiles, acquired profile lock this = 0x16fef48
02.09.2019 17:19:52 0960 D C:\Program Files\Sophos\Remote Management System\RouterNT.exe|Getting the certification object...
02.09.2019 17:19:52 0960 D C:\Program Files\Sophos\Remote Management System\RouterNT.exe|ACE (5604|2400) - SCG:<ctor=0197F430> - config=01872828 repo=01872888 superceded by repo=01872888
02.09.2019 17:19:52 0960 D C:\Program Files\Sophos\Remote Management System\RouterNT.exe|TAO (5604|2400) - Invocation_Adapter::invoke_i, making a TAO_CS_REMOTE_STRATEGY invocation
02.09.2019 17:19:52 0960 D C:\Program Files\Sophos\Remote Management System\RouterNT.exe|ACE (5604|2400) DSB::instance, repo=01872888, name=TAO_ORB_Core_Static_Resources type=0187BDB8 => 0187C060
02.09.2019 17:19:52 0960 D C:\Program Files\Sophos\Remote Management System\RouterNT.exe|TAO_SSLIOP (5604|2400) - Connector::connect, looking for SSLIOP connection.
02.09.2019 17:19:52 0960 D C:\Program Files\Sophos\Remote Management System\RouterNT.exe|TAO (5604|2400) Initializing SSLIOP_Endpoint
02.09.2019 17:19:52 0960 D C:\Program Files\Sophos\Remote Management System\RouterNT.exe|TAO (5604|2400) - TAO_LF_CH_Event[0]::state_changed_i, state LFS_IDLE->LFS_CONNECTION_WAIT
02.09.2019 17:19:52 0960 D C:\Program Files\Sophos\Remote Management System\RouterNT.exe|TAO (5604|2400) - SSLIOP_Connector::ssliop_connect, making a new connection
02.09.2019 17:19:52 0960 D C:\Program Files\Sophos\Remote Management System\RouterNT.exe|TAO (5604|2400) - Transport_Cache_Manager_T::fill_set_i, current_size = 0, cache_maximum = 10
02.09.2019 17:19:52 0960 I C:\Program Files\Sophos\Remote Management System\RouterNT.exe|TAO (5604|2400) - Transport_Cache_Manager_T::purge, Cache size after purging is [0]
02.09.2019 17:20:13 0960 D C:\Program Files\Sophos\Remote Management System\RouterNT.exe|TAO (5604|2400) - TAO_LF_CH_Event[24044520]::state_changed_i, state LFS_CONNECTION_WAIT->LFS_CONNECTION_CLOSED
02.09.2019 17:20:13 0960 D C:\Program Files\Sophos\Remote Management System\RouterNT.exe|TAO (5604|2400) - Transport[24044520]::purge_entry, entry is 00000000
02.09.2019 17:20:13 0960 E C:\Program Files\Sophos\Remote Management System\RouterNT.exe|TAO (5604|2400) - SSL connection to <192.168.12.80:51285:51285> failed (errno: connection timed out)
02.09.2019 17:20:13 0960 D C:\Program Files\Sophos\Remote Management System\RouterNT.exe|TAO (5604|2400) - Transport[24044520]::~Transport
02.09.2019 17:20:13 0960 D C:\Program Files\Sophos\Remote Management System\RouterNT.exe|TAO (5604|2400) - Transport[24044520]::cleanup_queue_i, cleaning up complete queue
02.09.2019 17:20:13 0960 D C:\Program Files\Sophos\Remote Management System\RouterNT.exe|TAO (5604|2400) - Transport[24044520]::cleanup_queue_i, discarded 0 messages, 0 bytes.
02.09.2019 17:20:13 0960 D C:\Program Files\Sophos\Remote Management System\RouterNT.exe|TAO (5604|2400) - Stub::next_profile_retry, acquired profile lock this = 0x16fef48
02.09.2019 17:20:13 0960 D C:\Program Files\Sophos\Remote Management System\RouterNT.exe|ACE (5604|2400) SCG:<dtor=0197F430> - new repo=01872888
02.09.2019 17:20:13 0960 D C:\Program Files\Sophos\Remote Management System\RouterNT.exe|ACE (5604|2400) - SCG:<ctor=0197E8A8> - config=01872828 repo=01872888 superceded by repo=01872888
02.09.2019 17:20:13 0960 D C:\Program Files\Sophos\Remote Management System\RouterNT.exe|TAO (5604|2400) - Invocation_Adapter::invoke_i, making a TAO_CS_REMOTE_STRATEGY invocation
02.09.2019 17:20:13 0960 D C:\Program Files\Sophos\Remote Management System\RouterNT.exe|ACE (5604|2400) DSB::instance, repo=01872888, name=TAO_ORB_Core_Static_Resources type=0187BDB8 => 0187C060
02.09.2019 17:20:13 0960 D C:\Program Files\Sophos\Remote Management System\RouterNT.exe|TAO_SSLIOP (5604|2400) - Connector::connect, looking for SSLIOP connection.
02.09.2019 17:20:13 0960 D C:\Program Files\Sophos\Remote Management System\RouterNT.exe|TAO (5604|2400) - SSLIOP_Connector::ssliop_connect, making a new connection
02.09.2019 17:20:13 0960 D C:\Program Files\Sophos\Remote Management System\RouterNT.exe|TAO (5604|2400) - Transport_Cache_Manager_T::fill_set_i, current_size = 0, cache_maximum = 10
02.09.2019 17:20:13 0960 I C:\Program Files\Sophos\Remote Management System\RouterNT.exe|TAO (5604|2400) - Transport_Cache_Manager_T::purge, Cache size after purging is [0]
02.09.2019 17:20:13 0960 D C:\Program Files\Sophos\Remote Management System\RouterNT.exe|TAO (5604|2400) - TAO_LF_CH_Event[0]::state_changed_i, state LFS_IDLE->LFS_CONNECTION_WAIT

  • the client hasn't yet managed by SEC

  • In reply to oki.herdian:

    Hello oki.herdian,

    as far as I can see the server advertises just the private IP and port 51285 (that usually is 8193). Ideally it should put its public FQDN (or at least the NATed public IP) into the IOR. Apparently you have made some modification - where and which?

    The article outlines how to make the server return a FQDN instead of an IP. The FQDN should either resolve to the private IP on the internal network or the server should be reachable on the public IP from the internal network.

    Christian 

  • In reply to QC:

    Hello QC, 

    Yes, i actually have configured the FQDN as well, the FQDN is resolved to external ip public of SEC that is already NATed to internal private ip address. 

    so how can i change that to our Public FQDN and port 8193 ? 
    which file do i need to check ? 

  • In reply to oki.herdian:

    Hello oki.herdian,

    apparently the endpoint connects to the server's NATed port 8192 as it receives an IOR. The How to change applies also to the main server and modifying these keys should make the Message Router return the FQDN instead of the private address. Can't say why it returns port 51285 - what is the current value of the mentioned keys?

    Christian

  • In reply to oki.herdian:

    Hello oki.herdian,

    I don't think that the gateway would fiddle with just the port in the IOR, to make sure please compare it with an IOR received on the internal network (either from the logs or with telnet server 8192).

    Christian

  • In reply to QC:

    Hi Christian,

    I found that if there's a typo in in -ORBListenEndpoints, it will change the port to a really high number.  I've just tested this in my lab with this key:

    "C:\Program Files (x86)\Sophos\Enterprise Console\Remote Management System\RouterNT.exe" -service -name Router -ORBDottedDecimalAddresses 0 -RBListenEndpoints iiop://:8193/ssl_port=8194&hostname_in_ior=MR.domain.com

    It returned port 52524.  With "OBListenEndpoints" it returns 52395.

  • In reply to QC:

    both IOR are identic

    from : external IP :

    010000002600000049444c3a536f70686f734d6573736167696e672f4d657373616765526f757465723a312e300000000100000000000000a4000000010102000e0000003139322e3136382e31322e38300054c84100000014010f004e5550000000210000000001000000526f6f74504f4100526f7574657250657273697374656e740003000000010000004d657373616765526f7574657200000003000000000000000800000001009702004f4154010000001800000001009702010001000100000001000105090101000000000014000000080000000100a600860055c8

    from internal IP :

    010000002600000049444c3a536f70686f734d6573736167696e672f4d657373616765526f75

    7465723a312e300000000100000000000000a4000000010102000e0000003139322e3136382e3132

    2e38300054c84100000014010f004e5550000000210000000001000000526f6f74504f4100526f75

    74657250657273697374656e740003000000010000004d657373616765526f757465720000000300

    0000000000000800000001009702004f415401000000180000000100970201000100010000000100

    0105090101000000000014000000080000000100a600860055c8

  • In reply to MEric:

    Hi MEric,

    here are the registry:

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

    -ORBDottedDecimalAddresses 0 -ORBListenEndpoints iiop://:8193/ssl_port=8194&hostname_in_ior=xxx.co.id

    HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Sophos Message Router\ImagePath

    "C:\Program Files (x86)\Sophos\Enterprise Console\Remote Management System\RouterNT.exe" -service -name Router -ORBDottedDecimalAddresses 0 -ORBListenEndpoints iiop://:8193/ssl_port=8194&hostname_in_ior=xxx.co.id

    so based on your statement, it means the ssl connection config is coming from server's side (message router registry of the server) instead of what we specify in mrinit.conf, so the client will initiate the connetion (rms connection) based on what we specified inside mrinit, and then client's  message router contact server's message router then the server will send IOR to the client, after that, ssl connection will be generated based on IOR code, is it correct ?

    Thanks

  • In reply to MEric:

    Hello MEric and oki.herdian,

    apparently the TAO library simply ignores unknown flags/parameters (there might be a warning at startup in the log) but otherwise it commences work. In the absence of an explicit port it requests an ephemeral port (that's why you get different ones - not because of the different typo) and listens on it. As long as the path isn't blocked by a firewall this works, CORBA is dynamic.

    Christian

  • In reply to oki.herdian:

    Hello oki.herdian,

    the keys look ok, I don't see a typo.

    the ssl connection config
    is not really complicated but mrinit.conf is not involved in actual operation. As its name implies it's only used for initialization (performed by ClientMRInit.exe). Registry values under the Messaging System and Remote Management System registry keys are set according to the parameters it contains.
    Client and server have to agree on the IORSenderPort (and the cryptographic Keys). The client tries to connect to this port trying all of the ParentRouterAddress addresses (in case the client acts as a message relay it uses MRParentAddress) until it succeeds. The server (could be the management server or a relay) responds with an IOR (interoperable object reference) that contains one or more "profiles" (i.e. host/port pairs that tell the client where to find the desired "object" -  in this case the server's Message Router).

    Does this answer your question?

    Christian

  • In reply to oki.herdian:

    Hi oki.herdian,

    Christian's last reply explains how the connection gets established in more detail than I know it. After mrinit.conf initialization, the client will try to connect to all ParentRouterAddress addresses on port 8192 in order until it receives an IOR.  This IOR returned by the server contains an IP/FQDN + port that the client will then attempt to establish an SSL connection to.

    The registry key doesn't seem to line up with the IOR that is being given back. Was the Sophos Message Router restarted after this change was made?  The IOR you posted returns an internal IP address while the registry key you posted should return xxx.co.id.

  • Not that this is your problem, but it could be.

    I have found that doing a copy/paste of the extra syntax (specifically the "-ORBDottedDecimal 0" parameter) didn't work, but if i typed it in manually it did work for me.  Something with the infamous dash character such as what happens when you put in a dash in MS Word vs typing it into Notepad.