Video Screencast Help

SEP 12.1: Opinion on Firewall ownership of comms

Created: 09 May 2013 | 2 comments
MIXIT's picture

Hi all,

Just looking for experienced opinion about the setting that governs whether network communications are allowed before the firewall loads and if the firewall goes offline. 

Specifically, the setting is located at:

SEPM > Clients > [Select a client group, or top-level parent if full inheritance is used] > General Settings > Security Settings tab > Security Settins section

And the setting is called:

Block all traffic until the firewall starts and after the firewall stops

I enabled this once back on a SEP 11 setup and if I recall, it caused some issues with programs that loaded before SEP that would try to get on the network - I believe even mapped network drives as well - and due to being blocked initially, you'd get a bunch of errors and would have to hope those programs or functions would have error recovery and try to reconnect again.  If not, you had to proceed manually, which for end-users was not acceptable so end result was not to use this feature.

I'm wondering if it's gotten any better with SEP 12.1?  Does the firewall load sooner?  Is there documentation on exactly when it enters the boot sequence?  (Varies by OS of course). 

Also on a related note, are there any ways to enter exceptions into the blocked network traffic that results from this blanket policy?  I know it les NETBIOS and DHCP traffic (which may anwer my initial question above perhaps).  For example, since I remote into systems to do work, if I had to disbale NTP for troubleshooting I would get disconnected I imagine. 


Operating Systems:

Comments 2 CommentsJump to latest comment

ᗺrian's picture

Good question and probably one that only Symantec can answer in full. There is a good KBA here which may help:

About the setting "Block all traffic until the firewall starts"

padding: 1px;padding-bottom: 3px ;font: 12px Arial; text-align: left;">Article:TECH199907 padding: 1px;font: 12px Arial; text-align: left;"> |  padding: 0px;font: 12px Arial; text-align: left;">Created: 2012-11-19 padding: 1px;font: 12px Arial; text-align: left;"> |  padding: 1px;font: 12px Arial; text-align: left;">Updated: 2012-11-21 padding: 1px;font: 12px Arial; text-align: left;"> |  padding: 1px;font: 12px Arial; text-align: left;">Article URL

If the firewall "malfunctions" you could be in for a real treat cool

They key is here is there is a very small window in which some exploitability could occur. Unless, you work for some government, which requires high security, I wouldn't use this setting.

Plus, it's not recommended for use on the corporate network, per the KBA.

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.

Mithun Sanghavi's picture


Any particular reason for using this setting? This setting is disabled by default.

There is no documentation on exactly when it enters the boot sequence, however to let you know that the tie ins to other processes with Teefer are more extensive in SEP 12 than SEP 11.

This setting should be used in conjunction with a location awareness policy and only used in scenarios in which the client may be connecting to a public network or an environment beyond the control of the enterprise network administrators. It is not recommended for use inside a corporate network. Most enterprise domains require additional authentication or connection requirements at boot and log-in sequences using NTLM and kereberos.

Check this Article:

About the setting "Block all traffic until the firewall starts"

Secondly, in an active - passive cluster pair with SEP 12.1.x, it advised that all cluster servers be in groups that have the policy component “Block all traffic until firewall starts and after the firewall stops” disabled. This component can cause the cluster communications to fail and result in an undesired Active - Active scenario where both cluster partners attempt to manage the shared data. 

An alternative work-around is to set the cluster service to manual start-up and then script launching the service once the machine has finished its boot process or a user log-on event occurs. This ensures the cluster service starts after the smcservice and that the firewall is running before the cluster service comes on online.

Hope that helps!!

Mithun Sanghavi
Associate Security Architect


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