Video Screencast Help

SEP 12.1 - Client Activity: Push or Pull?

Created: 07 Nov 2012 • Updated: 27 Nov 2012 | 9 comments
This issue has been solved. See solution.

Hey Everyone,

I have SEP and I have quite a few different DMZ arms. I'd like to use a single management console, however I can only really do that if the content and policy update proceses are on a "push" delivery method from the management console. I plan on using an individual GUP for each arm of my DMZ (each arm has a different subnet) which covers the content but the policies and informational updates are something I can't quite find any info on. I know that the policies come directly from the SEPM and do not proxy off the GUP. 

IIRC from SEP 11 these are the client related ports:

  • 80 - Client-Manager Comm
  • 443 - Client-Manager Comm
  • 2967 - Something related to the Update Providers
  • 8014 - Client-Manager Comm

What I am specifically looking for, is information relating to the direction of the communication initiation. For example, if the clients attempt to update policy via port 80, this would not work for my company's audit regulations as an untrusted zone would be initiating communication back into a trusted zone. In this instance I would most likely have to create a seperate SEP in the DMZ arm. 

So quick summary, I have three basic questions:

  1. GUP activity: Do the GUPs intitiate requests to the SEPM for content? 
  2. Policy Activity: Do the clients initiate requests to the SEPM for policy?
  3. If the clients initiate all conversations, is there a way to specify that the SEPM pushes the policies and content instead of the clients requesting the push?

Thanks in advance.

Comments 9 CommentsJump to latest comment

.Brian's picture

1. The GUP will check in and SEPM will tell it there is new content, and will download it.

2. Depends. In push mode, clients maintain a connection to the SEPM, once a policy change is made, it will be pushed to client. In pull mode, clients will check in at random intervals. If a new policy is available, the client will grab.

3. You can either use push or pull mode. In Pull mode, clients will do the checking. In Push mode, SEPM will initiate the update. However, in Push mode the client maitains a constant connection so this could cause bandwidth issues.

See this:

How the client computers get policy updates

https://www.symantec.com/business/support/index?pa...

Please click the "Mark as solution" link at bottom left on the post that best answers your question. This will benefit admins looking for a solution to the same problem.

sandra.g's picture

In push mode... once a policy change is made, it will be pushed to client.

Not entirely true, in a hairsplitting sort of way. Push is not a true push. The SEPM prompts the clients to check in within 1-2 seconds to get the new content or policy. The persistent connection means the clients can begin the heartbeat process that quickly.

Be it Push or Pull Mode, the actual heartbeat process is always initiated by the client.

sandra

Symantec, Information Developer
Installation, Migration, Deployment and Patching
User Protection & Productivity, Endpoint Protection

Don't forget to mark your thread as 'solved' with the answer that best help

Chetan Savade's picture

Hi,

I would like to answer your questions.

1. GUP activity: Do the GUPs intitiate requests to the SEPM for content? 

--> Yes

2. Policy Activity: Do the clients initiate requests to the SEPM for policy?

--> As per the policy.

3. If the clients initiate all conversations, is there a way to specify that the SEPM pushes the policies and content instead of the clients requesting the push?

--> It's possible with push mode however pull mode is recommended if using GUP in the environment.

Push mode

The client establishes a constant HTTP connection to the server. Whenever a change occurs with the server status, it notifies the client immediately.

Pull mode

The client connects to the server periodically, depending on the frequency of the heartbeat setting. The client checks the status of the server when it connects.

Because of the constant connection, push mode requires a large network bandwidth. Most of the time you can set up clients in pull mode.

Helpful Articles:

Steps to change the communication mode in client groups

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

Configuring communication settings for a location

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

Configuring push mode or pull mode to update client policies and content

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

 

Chetan Savade
Technical Support Engineer, Endpoint Security
Enterprise Technical Support
CCNA | CCNP | MCSE | SCTS |

Don't forget to mark your thread as 'SOLVED' with the answer that best helps you.<

Beppe's picture

Hi,

the key concept is that we are talking about a server-clients architecture.
The server is the Manager and it is listening on port 80 or 8014, HTTP protocol (or 443, HTTPS), for requests from the clients.
The clients are the SEP agents, they always initiate the communication (this is the principle of server-clients communication model), it can't be in the other way since they do not listen on any port; the difference between push and pull mode is if that communication must be kept always established or closed and re-opened at regular intervals, in any case and in any configuration the clients need to initiate the communication to port 80 or 8014 (and port 2967 to use the GUP). Once the HTTP channel is open, standart GET and POST commands are used to transfer the data (logs, policies, updates, etc.).

The GUP is acting as a client for the SEPM and as a server (listesting on port 2967) for the other clients.

Please, find below further details:

1) GUP activity: Do the GUPs intitiate requests to the SEPM for content?

It works like that:
1. the client asks for the new content to the SEPM (via port 80 or 8014)
2. the SEPM answers "Yes, there's X but go to your GUP to get it" and it will prepare X for the GUP
3. the client goes to the GUP and asks for X (via port 2967)
4. if the GUP already has X, it is sent to the client
5. if the GUP does not have X, it will get it from the SEPM (via port 80 or 8014), hence go to 4.

2) Policy Activity: Do the clients initiate requests to the SEPM for policy?

As explained above, it can't be in other way.

3) If the clients initiate all conversations, is there a way to specify that the SEPM pushes the policies and content instead of the clients requesting the push?

As explained above, the SEPM can't initiate any communication with the clients.

So, if this kind of architecture is not considered safe for you, you may consider to make it safer by using HTTPS instead of HTTP for the cliets-server communication (443 instead of 80 or 8014):

Enabling SSL in SEP 12.1:http://www.symantec.com/docs/S:TECH162326
 

Regards,

Giuseppe

SOLUTION
Linklight's picture

This probably won't work for us then. I think the obvious solution is to place a SEPM with subnets that make up the arms of the DMZ. I am much more comfortable allowing the SEPM console to call out to the web for an update and allowing the SEPM console to directly communicate with the servers on it's subnet or at the same security context level. License management may be a bear, but as long as we purchase what we use, it should be ok.

Chetan Savade's picture

Hi,

Is there any update on this? If issue is resolved then mark this thread as a solved.

Chetan Savade
Technical Support Engineer, Endpoint Security
Enterprise Technical Support
CCNA | CCNP | MCSE | SCTS |

Don't forget to mark your thread as 'SOLVED' with the answer that best helps you.<

Linklight's picture

Yes, I am sorry. I have marked a solution and dealt with the issue. Thanks for your assistance. 

SMLatCST's picture

As Sandra said, communications are always initiated by the client ("Thumbs Up" wink), even in PUSH mode.

You might want to consider setting up an additional/replicated SEP Site within the DMZ to manage your DMZ endpoints.

While this will not resolve the issue of DMZ -> Internal network traffic in general, you will be able to restrict it to just the DMZ-SEPM to Internal-SEPMs (rather than DMZ endpoints connecting to Internal-SEPM), thus mitigating the risk.

Clearly, it's up to you if this is sufficient.  If you do want to pursue this route, I'd recommend taking a look-see at the below articles:

http://www.symantec.com/docs/TECH178325

http://www.symantec.com/docs/TECH122858