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

RMS client not reporting.

We have remote sites (10.0.0.0)  that cannot report back to the server (192.168.0.0.). The server has a NAT'd address to the 10.0.0.0 network via a firewall and WAN connection. Through the Enterprise Console the client deploys and it collects updates via a UNC path. However the Console remains ignorant of the client status  apparently due to the RMS not being able to talk back. I've found a few articles on setting up DMZ message relays however that isn't our setup and would be difficult to implement. I've tried amending the mrinit.conf to use the 10. address with no success.

Is there anyway to get the client to talk back via RMS or am I missing something?

:7839


This thread was automatically locked due to age.
Parents
  • Hello Steven,

    First and formeost, thank you for your quick response.

    Let me give you a brief background about this issue.

    Around 44 machines are affected by this issue and none of them are reporting on console. These machines are on a different IP range (10.x.x.x) and a firewall separates them from Sophos servers (192.x.x.x). NATting is enabled to enable the communication between client machines and Sophos servers.

    From the message router log files it is clear that these machines are unable to complete the certification process. Now I checked the routernt.exe logs on one of the machine (same machine for which we uploaded sdu logs) and here is my observation:

    1. Client machine (10.x.x.x) connects to parent router at port 8192 using parent router hostname. This hostname has a nat’’’’d entry (192.x.x.x --> 10.x.x.x) and hence connection is established.
    2. Client machine reads the IOR information and extracts the server IP address and port information i.e. a 192.x.x.x address and port 8194
    3. Client machine (10.x.x.x) tries to connect to the IP obtained in step 2 (192.x.x.x) and as this is where it fails.
    • Is there a parser that we can use to interpret the IOR information.
    • Can we make some changes at client machine to facilitate this communication.
    • Is it possible to modify IOR on Sophos server and include the nat’’’’d (10.x.x.x) IP address to ensure that this is what client gets when it queries IOR.  

    Did  you made changes to the way IOR is handled or on local client machine.

    Thanks

    Mayank

    :12431
Reply
  • Hello Steven,

    First and formeost, thank you for your quick response.

    Let me give you a brief background about this issue.

    Around 44 machines are affected by this issue and none of them are reporting on console. These machines are on a different IP range (10.x.x.x) and a firewall separates them from Sophos servers (192.x.x.x). NATting is enabled to enable the communication between client machines and Sophos servers.

    From the message router log files it is clear that these machines are unable to complete the certification process. Now I checked the routernt.exe logs on one of the machine (same machine for which we uploaded sdu logs) and here is my observation:

    1. Client machine (10.x.x.x) connects to parent router at port 8192 using parent router hostname. This hostname has a nat’’’’d entry (192.x.x.x --> 10.x.x.x) and hence connection is established.
    2. Client machine reads the IOR information and extracts the server IP address and port information i.e. a 192.x.x.x address and port 8194
    3. Client machine (10.x.x.x) tries to connect to the IP obtained in step 2 (192.x.x.x) and as this is where it fails.
    • Is there a parser that we can use to interpret the IOR information.
    • Can we make some changes at client machine to facilitate this communication.
    • Is it possible to modify IOR on Sophos server and include the nat’’’’d (10.x.x.x) IP address to ensure that this is what client gets when it queries IOR.  

    Did  you made changes to the way IOR is handled or on local client machine.

    Thanks

    Mayank

    :12431
Children
No Data