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

multiple remote clients, no vpn, single console.

Hi all.
We are an MSP new to Sophos.
.We want to manage multiple remote clients (w/o vpn's) from a single enterprise console.
After searching thru the documentation, here are what we believe to be the articles we need:
1.) Updating via http - http://www.sophos.com/en-us/support/knowledgebase/38238.aspx
2.) Message relay over WAN: http://www.sophos.com/en-us/support/knowledgebase/50832.aspx
3.) Message relay computer setup: http://www.sophos.com/en-us/support/knowledgebase/14635.aspx

Is that all we need, or are there other articles y'all think we should follow as well?

Do we need to implement the first article even though we are doing the other two? (Or is the message relay system only for policy, etc updating?)

In the second articke listed above, i am pretty sure we should i plement scenario 1.
For the message relay computer, does that need to be on a seperate public IP than all our other stuff?

Thanks, in advance, for your help!

-eric
:34761


This thread was automatically locked due to age.
  • Hi,

    This post should help:

    http://community.sophos.com/t5/Sophos-Endpoint-Protection/Configure-Endpoint-Server-10-with-RMS-behind-a-firewall-NAT-Don/m-

    p/20971

    Otherwise, I'm sure there is a specifc PDF for MSPs, you may want to call Support to check.

    The points to consider are:

    1. Will the clients need to talk to a message relay or directly to a management server?

    2. The external clients will need to resolve an external IP address from a DNS name.  

    E.g. You have the domain name test.com which resolves to an external IP you are considering using.

    I would probably suggest create a a name on that called for example:  rms.test.com which forwards to the same IP.

    Port forward 8192 and 8194 to the relay or management server.

    Then using the post info above (hostname_in_ior) you can set that to rms.test.com.  This would also be the address the clients have as their parent address (as configured using the custom mrinit.conf in the CID).  So that they read 8192 (IOR port), that would provide them with the details to connect to rms.test.com on 8194 to communicate.

    Note: Where you use the hostname_in_ior switch (relay or SEC server) that computer needs to resolve what ever is in the IOR to itself.  I suggest using the hosts file to do this.  This is required as the local agents are also connecting to the router to read the IOR, and these need to see that rms.test.com to use our example, as the local computer.

    3. Updating is the other concern.  I assume you will have IIS/Apache setup and Sophos Update Manager (SUM) can push a distribution to that for the client to udpate?  I would suggest in SEC create a dedicated subscription, call it for example "MSP" and subscribe to the "Previous" versions of the packages.  This will minimise risk to the endpoints should the latest package have a problem and save you some time later.

    I hope these pointers help.

    Regards,

    Jak

    :34763
  • Here is a quick example to hopefully give some more insight ofn roughly what you need to do...

    Router/Gatway
    82.67.45.23 (sophos.test.com resolves to this external IP)

    192.168.1.1 (internal)

    Port forwards: 80, 8192 and 8194 to 192.16.1.2 (i.e. the intenal Sophos server)

    Sophos Server
    192.168.1.2
    Hosts file has and entry: 192.168.1.2 sophos.test.com

    Installed: SEC + IIS

    SUM configured with a custom subscription called "MSP", subscribed to "Previous" version of SAVXP for example, which creates:
    \\127.0.0.1\SophosUpdate\CIDs\S001\SAVSCFXP\  (View bootstrap locations in SEC will show this)

    IIS shares this out such that: http://127.0.0.1/SophosUpdate/CIDs/S001/SAVSCFXP is in effect the same location.

    To configure RMS for the clients from the install location:

    Copy (not move) mrinit.conf from the root of the CID:  "\\127.0.0.1\SophosUpdate\CIDs\S001\SAVSCFXP\"
    to "\\127.0.0.1\SophosUpdate\CIDs\S001\SAVSCFXP\rms\"
    edit the file in Notepad so that: "ParentRouterAddress"="sophos.test.com"

    Run: "C:\Program Files (x86)\Sophos\Update Manager\condifcid.exe" \\127.0.0.1\SophosUpdate\CIDs\S001\SAVSCFXP\
    to add this custom mrinit.conf to the checksum file cidsync.upd in the rms sub directory.

    Any client that instals from:
    \\127.0.0.1\SophosUpdate\CIDs\S001\SAVSCFXP\setup.exe with then have a RMS parent address of sophos.test.com

    I would then create top level groups in SEC for each "company" to support, and whatever hierarchy is required underneath that.


    I would configure new updating policies with the update locations to be:
    http://sophos.test.com/SophosUpdate/


    Make sure the subscription tab has the custom "MSP" subscription selected in order for the update location to add on the correct: "/CIDs/S001/SAVSCFXP". as the final update location the client gets is a concatination of what you specify in the primary update location and the part added by the subscription tab.


    You should now be able to install a client using the CID:
    \\127.0.0.1\SophosUpdate\CIDs\S001\SAVSCFXP\setup.exe
    You can copy this off to create an installer package for the clients.

    This article will then become useful for automating the install process from that CID, by passing switches: http://www.sophos.com/en-us/support/knowledgebase/12570.aspx

    You should then check that a test client, e.g.

    Client:
    88.6.5.5  (some external IP)
    has:
    ParentAddress: sophos.test.com
    UpdateLocation: http://sophos.test.com/SophosUpdate/CIDs/S001/SAVSCFXP
    And it can message in to SEC and update ok.

    You should find that upstream messages from the client to the server are pretty quick, but downsteam messages from the server to the client, i.e. policy push make take up to 15 minutes based on the client polling for messages.  THis can be changed if required on the client by creating a registry key. GeterInterval DWORD under the \Router\ key.  This needs to be a time in seconds.

    This is all of the top of my head, but it should be 99% there or there abouts.
    The other option as I mention is to get the clients to message in to a message relay rather than the SEC server directly.
    You may also have a dedicated web server. If this is the case, it would be quite easy to change the above to split out roles.

    Regards,

    Jak

    :34765