Endpoint Protection

I cannot find instructions in the Admin guide or anywhere else for my need. I will describe my need here.

First some background:

 I have a corporate WAN (Windows Servers) with offices in varying parts of the US.  These offices are networked back to the main office where the SEPM is located.  Those clients are fine as far as being managed goes. They get policies changes/updates, if they get infected I receive an email, etc.  Basically normal SEPM to SEP client environment.

 But, I have over 100 computers that were in an office only for software installations before being deployed. They have the SEP 11.xx client or SEP 12.1 client on them with policies from the time of their initial software installations, but are not being managed by the SEPM because they are out of the office, not in the WAN, therefore are not networked back to the SEPM because they are not in the Windows Domain. They will never be part of the domain.  They do have internet access but not to the Windows network. So, while they do ge their AV definitions via their internet connection,  they don't get updated POLICIES, and if they get infected no email is sent to the SEPM, because the client cannot reach the SEPM. Many need upgrading from SEP 11 to SEP 12 and the SEPM cannot communicate with them.  I have new policies that need to be installed. The SEPM is only available to communicate with f computers that are in the WAN I have mentioned.

I want to avoid manual exporting of policies at each client.  The time it would take to physically touch each client is HUGE and I don't want to even try that. And anyway they need to be managed, even though they are outside the Windows network. Additionally, there are many existing domain SEP clients that are laptops and travel out of the office often. I want them to be managed as well via their internet connections when outside the Domain.

Now, for what I want to do with SEPM:

My question: Is is possible to set up the SEPM as, effectively, a public facing server through a DMZ, maybe even with a proxy server between the DMZ and the SEPM on my network to increase security; in order to manage these SEP client computers that are never in the network?  I see instructions for Symantec reporting servers or additional servers in a DMZ, but I find no guidelines/instructions to set up what I have just described.  Keep in mind there is no more IIS in SEP 12.  It is Apache Tomcat which I am not familiar with.

I think it can work this way, conceptually:  I wonder if anyone has tried this before with SEP. Here goes:

First of all my SEPM servers name is not the FQDN of the server, but only the host name.  It appears I'll have to reinstall SEPM from scratch and make the server name the FQDN of the server. Recall this server is already managing clients in a Windows network. Then, after the reinstall, register the FQDN of this server as an MX record on the internet. Then setup the FQDN of the SEPM on a DMZ in one of my network engineers routers, maybe take the extra step of pointing the DMZ to a Proxy server. Then point the proxy server to my internal SEPM.  Now that this path of communication is set up to reach the internal network SEPM from anywhere on the internet, the clients that have SEP 11 and SEP 12 installed hopefully will start to communicate? It's at this point I can update policies on those clients, upgrade the SEP 11.xx client to SEP 12, etc. 

Does anyone know for sure if this can work?  Or perhaps another way to set this up? 

Thank you.

yes, you can have SEPM with public IP address and the firewall should allow port the SEPM is built on (port 8014 default)

I need to do the exact same thing.  Virtually all of my clients are out of network.  The previous AV product we had - Sunbelt VIPRE Enterprise - was able to handle this without issue.  Were you able to get this working with your SEP implementation?

I wouldn't change the FQDN of the server, just to feed externally facing clients. 

Yes, you can have you server in the DMZ.  You will need to open some ports for your clients to connect to the server. 

Why the MX record?  That would just give you a larger, more public facing attack vector.

Just assign a public IP or if you prefer, register a public DNS name for your server.  Point your public IP NAT'ed through your router/firewall to the IP and port of the SEPM.

* * * * * * * * *

For added security, you can have a LUA server between 2 SEPMs in a VLAN/second DMZ/between proxy servers/routers/etc. To communicate with the first (main SEPM server) and replicate data through the LUA in a single directional (Internal to DMZ) for the external clients.

You limit your attack vector and still protect your internal server.... 

Thanks for the reply.  We have a public DNS name for the server and have the necessary ports open through the firewall, but how do the clients know about the public DNS name for the server?  It seems that would need to be in the install package that is used to install the client.  In the SEPM management console, however, it just lists the internal NAT'ed IP address of the server.

Is this SEP 12.1?  Or earlier? Yes, the name of the server is in the install package.  But I understand that can't be edited directly.  The name of the server that is embedded in the install package is taken from the FQDN name of your server, if I remember this correctly. 

So, two potential causes come to mind. It seems to me that probably the registered public DNS name does not match exactly the SEPM FQDN name. And the second thing would be to make sure the port the client is trying to use connect to the SEPM matches the SEPM port config. You can test this with a command through a browser.

If you run this command in a browser (filling in details to fit your environment between the "<" and ">")  from a client out on the public internet, it would show right away whether the communication is working or not between the SEPM and the client,  and test those two areas at the same time; that is DNS resolution and port of communication. (Maybe you've done this already, though..) Here is the command:

http://<server_name_or_IP_address>:<current_communication_port>/secars/secars.dll?hello,secars

You should see the response of "OK" if communication is working when using the command above. So, if the above command through the browser fails, then it's likely to be one of the two causes I mentioned.  Or so, that is what makes sense to me. Maybe a more seasoned tekkie here has a better idea?

Additionally, if you run the above command on a client that is inside your network, you can confirm what DNS name the client needs and the port number it needs, then doublecheck if that matches the port opened on your DMZ and registered public DNS name for your SEPM. 

Now, since I have not yet implemented this in my environment, my comments are theoretical, not practical. But I would start with the command given above if you have not done so already.  Hope that helps.

--IT Monkey Boy

From your comment, it looks like the FQDN for the machine hosting SEPM is not the same as public DNS for the server.

One of the possibilities to allow clients to connect to SEPM using public DNS is to create a Management Server List with public DNS name as priority 1 entry. You can create a new Management Server List in the Policies tab, under Policy Components, and then assign it to the group of clients. For more details on how to create and assign management server list, please refer to the following URL -

http://www.symantec.com/business/support/index?page=content&id=HOWTO55402

Of course, now as you have mentioned this information will be exported along with the client package. So need to export the client export package for the group (to which MSL is assigned) and install the client. For already installed clients, you can probably export sylink.xml for the group and import this in the clients.