Help with deployment

HI,

The Remote Management System (RMS), relies on a one to one mapping between Sophos Message Routers.  I.e. 

Server <> Client

Server <> Relay <> Client

Server <> Relay <> Relay <> Client

etc...  There is a limit to the number of relays (probably related to the length of the hostname), but I've never considered any more than 2 relays in the chain.

The key thing is to ensure that the path a client communicates over must always be the same.  It can work to a point, having the client move between parent routers but you would loose messages.

Firstly, it is important to know that if a client is unable to connect to the parent router it will queue messages and deliver them when it can.  Likewise any commands issued to a disconnected client will be queued on the server until the client comes online.  So in a reasonable time frame, you don't loose messages.

However, to maintain management, regardless of location, VPN connections asside, you would need to set up a publically routable message router, such that a client can wander and always find its parent router.

So you would need to have a routable "ParentAddress" for the clients to use that always points them at the same parent router regardless of location.

So I would have SEC on the internal network, have a message relay in the DMZ.  The clients would message in via the relay when in both locaitons.  For example if the parent address of the clients was: relay.domain.com, internally that address would resolve the same machine as externally.

The post here:

/search?q= 20971

has some relevant info.

Regards,

Jak

Hi jak and thank you for your reply.

However, the solution you provide is exactly the one I'm trying to avoid: when always using the RMS, you elevate the number of single point of failure to 3 (dmz firewall, rms server in dmz, sec in lan), when it could be just 1 for the internal clients.

I'm thinking of exclude the rms at all and force the sec to publish updates via http. Then I will publish the 8192 and 8194 ports on the Forefront TMG firewall pointing straight to the sec server. It's possible, right?

Hello Dario,

first of all, please note that updating and management are two distinct components.

Let's look at updating first. Usually "outside" clients are not set to use a UNC path but http. Thus you could use \\ServerA\SophosUpdate as Primary and http://ServerB.yourdomain.com/SophosUpdate/ as Secondary - the drawback is that you will see updating errors for the outside clients. Another option would be updating from http://SoUpd.yourdomain.com/SophosUpdate where SoUpd.yourdomain.com internally resolves to ServerA and externally to ServerB.

RMS is, as said, a different thing. In principle you could forward the ports but you'd have to make sure that only the FQDN is returned in the IOR - as this FQDN is likely an alias you'd also have to check if it works (I haven't done so lately), i.e. that the management server is also able to talk to itself. May I point out that you don't reduce the POFs from 3 to 1but "only" from 3 to 2 as the firewall is still involved. Using the suggested setup adds the risk of RMS on the relay failing - which is very unlikely unless the whole server goes belly up (in this case clients would also fail to update and that would be our primary problem).

Christian

Hi Christian

I was talking about the internal clients update process, so my statement is right, 3 to 1. And, also, for external client it's a 3 to 2 reduction, but with somewhat reduced security (the idea to have an RMS in the DMZ is, from the security point of view, a good one).

Back to the internal clients, I find the concept to go out to the dmz and then back to the lan just... dumb, plain and simple.

What I did so far:

update from an http source, so I can use split dns and pat to make clients inside and outside my lan to update themselves using the very same settings, as you suggested

What I still have to do:

tweak the management server to accept connections for the alias. I found some articles talking about doing it on RMS, but can I do the same on the sec server?

Hello Dario,

I find the concept to go out to the dmz and then back to the lan just... dumb, plain and simple

well, the general case is still - I assume - managed clients on the LAN or VPN, or a complex installation with several sites where you already use relays for "traffic consolidation".  Dunno about the long-term future of RMS - newer features (Patch assessment and Web Control) use a different mechanism for communication (directly or port-forwarded to the management server, but this is naturally one-way client-pull) - but it will likely be around for some more time.

Just made some test on a test management server. In mrinit.conf set MRParentAddress to just the FQDN and ParentRouterAddress   to the alias - this works without problems so no tweak on the management server is needed for this. But - article 50832 states: 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. Now it says should - right now I don't see why this should be required.

Don't have a split DNS available so I can't test. I'd just set ParentRouterAddress to - say - SophosMR.yourdomain.com which on the LAN resolves to the management server and outside (including the relay) to the relay and change the relay to return just the FQDN in the IOR. 

Christian

Hi Christian,

I also made my tests using my workstation:

1) Stopped the Sophos Message Router Service

2) changed the mrinit.conf: ParentRouterAddress to the alias, MRParentAddress unchanged.

3) executed C:\Program Files (x86)\Sophos\Remote Management System \ClientMRInit.exe

4) Started the Sophos Message Router Service

the alias resolve, from the inside lan, to the ip of the SEC server.

The client seems to work just fine. Messages and updates are flowing nicely. No RMS for me, then.

Now I'll make some test with a notebook so that I can take it to the external world and see how it plays out...

If this solution will not work, maybe i'll try using an RMS in the DMZ while keeping the modded mrinit.conf: the clients will then connect directly to the sec when inside the lan (and it works, we just verified it) and to the RMS when outside the lan...

I'll post the results...

Dario