Video Screencast Help

How do I securely manage SEP clients accross internet?

Created: 26 Apr 2012 • Updated: 02 May 2012 | 10 comments
This issue has been solved. See solution.

Greetings all.

I have a question that has been asked by many, but the answers always seems to avoid addressing the scenario fully.  I know what I am asking has been done because I was a road warrior for two other firms (connect over the internet) and I had the Green Dot on my SEP Client systray icon, eventhough I was not connected via VPN and I was on the airport wi-fi, coffee shop (insert your favorite brand here) wifi, etc.  

What I haven't been able to determine, is what was done in order to acheive this level of manageablilty but in a secure fashion.   

Considering compliance restrictions and the need for maintaining a secure link, it is my understanding that requests/connection must terminate in the DMZ.  It is also my understanding that having a direct link from the outside through the firewalls to the inside is not good practice. 

--So, does NAT from DMZ to internal SEPM meet this requirement?  Isn't this essentially creating an undesireable direct link to the internal network from the outside?

--Also, I thought that perhaps there is a SEPM in DMZ (same site but with DB inside LAN), but reading that authentication/communication between SEPM and DB is clear txt, leads me to think that this is not the actual config. 

I know that many of you are thinking that what is being done is to install a second SEPM site(with local DB instance) in DMZ as replication partner, and I know this is a realistic and viable option, but I also know that this is not what they were doing in thes firms.   

What am I missing?  Have one of you seen or been in a similar configuration? 

I'm at a new company where I'm not the road warrior, but rather the IT Sec guy, and I want to acheive the same level of managability without weakening the security posture.  We have a large road warrior population.  The concern isn't about updates and policy update, it is about logs, notifications, reporting, and I want to know a system is compromised before it comes back home. 

Thanks in advance for your feedback.  Feel free to ask any followup/clarification questions.

Comments 10 CommentsJump to latest comment

Thomas K's picture


Here is a great document to start with. You will find useful KB articles for configuring and managing remote clients.

Managing remote clients -

delvallejr's picture

Thomas K,

Again thanks for the links.  Regrettably, it didn't have what I was looking for.  There was a link that did a good job of justifying why what I want to do is a good idea, but it doesn't explain how to do it.

Thanks, guys.  It is starting to look like my only option is to NAT to an unpublised external IP.

Jason1222's picture

If I was in a similar situation, I would consider exactly as you said.

Except, having a second SEPM installed might not be such a good idea.

Have you consider using a LUA server in the DMZ?

* * * * * *

Figure a scenario that looks something like this.

You have mulitple public IP addresses.  Some are mapped to an actual domain name and some are not.

We take a non mapped IP and use it for the public side of our DMZ.

We place a LUA server in the DMZ and have our clients connect to the public IP mapping the port to the server.

Now, we configure the update servers policies for our groups and point to an external source, you can configure it to use the IP address sepcified above - public side.

I think by default the clients connect to port 7070.

You can modify the config file to point to a different external port and map external to internal if you choose. 

From within your network, you can configure the ports to map to the LUA from the SEPM. 

* * * * * * *

Since they are road warriors, you can also setup Location awareness, so that when they are internal, they connect to the SEPM and when they are out of office, use the "externally pointing" LUA.

delvallejr's picture

Thomas K, Thanks for your quick reply.  I'll be review the referenced links shortly.

Jason 1222,  Also, thanks for your quick reply.  I have a follow up question for your: 

With regard to the public non-mapped IP address:  Is this the way your endpoints forward their logs to your SEPM?  Like i mentioned before I'm not really worried about updates,  I have that covered.  I already have location awareness rules configured and they are included in the default installation package. 

I am primarily concerned with recieving logs from the remote clients and being able to get to them the occassional policy/communication settings/etc. when they are off the network for extended periods of time.

Thanks again!  I do appreciate the feedback.

Jason1222's picture

Public non-mapped - meaning no domain name associated to the external public IP.  Just an IP address that you could directly point to.  If you have one.

I know the article says Unmanaged, but it supposedly works for managed as well.

And this artocle for some extra configurations...

As far as logs go...  I know the LUA server keeps it's own logs -> They can be exported or mailed.

delvallejr's picture

Jason1222,  thanks for the links. 

1. For some reason, the first link takes me to the main support page and not to the article, perhaps I dont have access to that area. 

2. Concerning the second article, it is about LUA and that is not a direction I am going.  LUA in DMZ only makes some sense, IMHO, for updating servers in the DMZ.  For remote laptops and employees working from home it makes more sense to send them directly to Symantec Live update. 

My objective is to get logs and status from these remote laptops and PCs and sending the occasional commands from these clients that rarely connect to the corprate network directly or through VPN.  Most of their interaction to the company is through Web services.   I hope this helps clarify further what I am trying to achieve.

Thank you,


SMLatCST's picture

...for addressing this kind of requirement, would be to implement the last one you mentioned (i.e. separate SEP Site within the DMZ that replicates log data to the internal site).

Without doing so though, the only way I can imagine it working that you've not already described would be with the use of an inbound proxy server.

delvallejr's picture


Thanks for your feedback.  Would a replication partner need to be in the same domain?

Also, does Threat Management Gateway count as an inbound proxy?


SMLatCST's picture does not need to be in the same domain.

I don't know if TMG can do it I'm afraid, but I don't see why not as ISA was able to (though I think MS called it a reverse proxy).

Clearly though, such a setup is unlikely to be supported by Symantec, which is why I prefer the Internal Site and DMZ site setup myself.

Of couse, it also safest (and recommended) to put some sort of hardening on the DMZ SEPM too (perhaps even Symantec Critical Systems Protection if you have it).

delvallejr's picture

Hi all.  Thanks for all your feedback.  Just note that I marked SMLatCST as the solution eventhough you all have suggested DMZ site.  You all deserver credit, but I was only able to mark one.

Thanks again!