Add Firewall Rule to Open Port 53 on Server?

[John_N]

We have an unmanaged client installation of Symantec Endpoint Protection (12.1) on a server running Windows Server 2012 R2 Essentials as the operating system.  Per Microsoft, the server OS is configured to function as the DNS server for the small domain network involved.  We are having problems with the workstations seeing/finding the server.  This can be seen in everything from the initial Essentials "Connector" software (which is what is used to add a workstation to the Essentials domain) to later workstation boot-up where mapped server drives aren't found and the Internet connection is shown as a workgroup network, rather than the domain network that is actually there.

The only way I can consistently make the workstation start up and operate properly on this small domain network is to disable the SEP firewall on the server.  When I do that, the workstation/server connection works every time.  With the SEP firewall enabled, it almost always fails (and a workgroup network setting is shown, with no sign of the server being recognized).

For security purposes, I would rather not permanently disable the SEP firewall on the server.  However, I have to have the workstations start up properly and find the server/network.  As a less extreme way of handling what seems to be a DNS problem, could I create a new firewall rule that opens Port 53 on the server (the DNS port)?  The SEP help screen mentions doing this for UDP but should I also create a rule for TCP?  For this to work, do I also have to disable the Smart DNS function in the SEP firewall settings?

Thanks for any advice or suggestions you can offer.

[ℬrίαη]

What's showing in the Traffic log on the client?

The smart DNS feature should already allow DNS to work without the need for adding a firewall rule to allow it. If this is off then you need to add the rule.

This was also a bug in an older version, see here:

DNS traffic may be blocked at client when Endpoint Protection is installed

[John_N]

When I look at the traffic log in SEP (under Network Threat Protection), I can't see further back than today's date.  Even when I set the log filter to include a month or all entries, the internal SEP screen display stops too soon.  Is there a place I can see the "raw" traffic log that includes all entries (i.e. the name and location of the actual ltraffic log file)?

Just to clarify, if I do want to add a new rule opening port 53, should I turn off Smart DNS or will the rule permit all DNS traffic from the workstation to the server even with SmartDNS enabled?  Should I include just the UDP protocol in the rule or do I need to also add TCP?

Thanks again for your help with this.

[ℬrίαη]

Traffic log (tralog.log) is located in C:\ProgramData\Symantec\Symantec Endpoint Protection\version number\Data\Logs

It would be redundant to add a rule to allow DNS with Smart DNS already turned on. For the rule, you only need to allow UDP 53.

If you want to further test the firewall try the steps in this article:

Troubleshoot blocked network traffic due to the Endpoint Protection firewall

[John_N]

Thanks for the helpful suggestions.  I will be going to the office with this system in it tomorrow afternoon.  I will try and create a new SEP firewall rule opening port 53 then.  I'll report back with the results.

[John_N]

When connected remotely to the workstation this morning, I ran the NSLOOKUP command.  Here are the results:

NSLOOKUP XXX.local (the domain server)

DNS timed out

timeout was 2 seconds

Server: UnKnown

Address:  (returned correct server IP 6 address here)

 

DNS request timed out

timeout 2 seconds  (repeat these two lines four times)

 

*request to UnKnown timed out*

 

Please let me know your interpetation of this NSLOOKUP command.  I will be going on-site to the office as planned this afternoon, in part to work on this problem further.

Thanks.

[John_N]

Brian,

The only way I could get the workstation to reliably "see" the domain at login was to add an "Allow All" firewall rule, as the article you sent me indicates.  Things also work if I disable the SEP firewall.  In either case, the NSLOOKUP command returns the expected response (no timeouts) and the network icon on the taskbar indicates the presence of a domain network.

One of the interesting things about this frustrating situation is that we are using the Enterprise edition of the SEP client for the first time (due to the lack of future upgrades for the Small Busines Edition).  We have used SEP SBE many times in the past on small Windows Server Essentials networks with none of these problems in terms of workstation DNS traffic.  I guess we should have stayed with the the tried-and-true SBE version, frozen in time though it may be.

 

 

[ℬrίαη]

What is the exact SEP version being used? It could've been a bug in an older version, although I can't recall off the top of my head.

[John_N]

The software was purchased online from the Symantec store a couple of weeks ago.  It should be the lastest version of the SEP Enterprise client.  Here is the specific version information:

12.1.6  (12.1 RU6, MP3, build 6608.6300)

[ℬrίαη]

The latest is 12.1 6 MP4, however, I've not seen this specific issue in 12.1.6 MP3. The closest bug I was able to find in 12.1.6 MP3 is mentioned here:

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

Either way, may need to get a support case open. Definitely odd behavior.

[John_N]

Thanks very much for your additional assistance, Brian.  Actually the MP3 technical article above almost exactly describes the problem we are having.  At first my custom "open local port 53 on the server" worked perfectly.  I checked the traffic log and my custom rule was allowing the DNS communication between the workstation and server.  Then I rebooted the server as part of my testing process.  I was then no longer able to connect to the server domain.  In the traffc log, the cause was the Block All rule, which apparently had overriden my custom rule, even though the custom "allow port 53" rule was at the very top of the rule list.

At this point, I think it is definitely worth trying the MP4 build.  I have to say that I don't really understand how a newly (with the last few weeks) purchase of SEP Enterprise directly from the Symantec store could be over a year out-of-date (the MP4 build was released in March 2015).  Since this is an unmanaged client, I don't think it has a serial number (or if it does, I'm not sure where to find it).  There is no license file in use,  Given this, how can I obtain a copy of the MP4 build of Endpoint Protection?  It does not appear to get automatically installed by LiveUpdate.

[ℬrίαη]

MP4 was just released in March 2016:

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

All downloads can be gotten from here:

https://symantec.flexnetoperations.com

...but you do need a serial number. If you purchased SEP recently, they should've given you a serial number. If not, you'd need to call support to get this worked out.

[John_N]

Sorry for the confusion on the MP4 release date.  I got that information from Symantec tech bulletin 103088.  That document shows the SEP MP4 release date as March 16, 2015.  The year value was probably just a typo.

I have one other quick question for you.  Will I need to completely remove SEP MP3, then install MP4 from scratch?  I wasn't sure if minor version upgrades (MP3 to MP4, for example) were part of the LiveUpdate process or if they require a full remove/reinstallation.

Thanks.

[ℬrίαη]

You should be able to upgrade right over it, no uninstall is needed.

[John_N]

Thanks Brian.  I am going to (attempt to) download the MP4 release today and install it within the next couple of days.  I'll let you know if that solves the problem.

[John_N]

I have downloaded the SEP 12.1.6 MP4 file, Brian.  When unzipped, it created a 64-bit Windows client executable, which I assume is what I should use to upgrade the MP3 unmanaged client currently on the server.  To perform an in-place upgrade, I need to copy the file over to the server, then just run/execute this file, correct?

Thanks again for all your help with this problem.  I'll let you know how it goes after I perform the MP4 upgrade (tomorrow afternoon).

[ℬrίαη]

Yep, just run the exe, it will upgrade over the previous version.

[John_N]

Sorry to keep bothering you with this problem, Brian.  Unfortunately the installation of SEP MP4 did not solve the problem.  It still occurs most of the time.  Oddly, when the workstation sees the server/domain once, it retains that connection through multiple logins/logouts.  However, if I reboot the workstation, it goes back to a workgroup configuration and does not see the server/domain.

I have attached the SEP traffic log file for you to see firsthand.  In looking at what I can see of the log in SEP, it looks like even the "Allow All" rule I created is being trumped by the Block_All rule.  It looks like the workstation's initial connection is via TCP and its IP v6 address.  Once this has been blocked a few times (in spite of the Allow All rule being at the top of the firewall rule list), the workstation tries to connect with its IP v4 address (10.1.10.81).  That connection is allowed through the SEP firewall, but it occurs after the unsuccesful TCP/IP 6 attempts, so the domain network is not found (the workgroup continues to be shown on the workstation).

FYI, I am testing this with only one workstation and the server on the network.  There are other workstations that need to be added to the network next week, but I really need to get this problem resolved before doing that.  There is no reason to assume it won't also happen to them as well.  Sometimes when the domain/server is not detected at login, the workstation also sends out an error message that the mapped network drives cannot be reached.  To connect to them requires manually logging into the server, which does work.

I will be able to try and suggestions you may have after looking at the traffic log when I visit this office tomorrow.  Thanks again for all of your help.  I hope we are nearing the end of this adventure.

Attachment(s)

tralog_0.txt   511 KB 1 version

[ℬrίαη]

The 'Block_All' rule is a built-in rule that isn't configurable. However, the rules you've created should've worked.

At this point, I would suggest completely wiping SEP off and starting with a fresh install of 12.1.6 MP4. There seems to be something else going on here. Support may need to be called in as well so someone can get on the box and enable advanced logging.

[John_N]

I removed SEP as you suggested.  Windows Firewall on the server was re-enabled by default after SEP was removed.  Once SEP was gone, the problems I have described above immediately vanished.  Everything between the workstation and server now works perfectly, every time, even after multiple reboots. 

Based on my experience, there appears to be a problem with the SEP firewall rule function.  As you said, the two rules I added (including the Allow All rule at the top of the list) should have allowed the DNS traffic to pass between the server and workstation.  For whatever reason, the Block_All default SEP rule overrode my custom rules and blocked needed initial DNS traffic between the workstation and server.  Once I removed the SEP firewall (and program) from the server, the problem was gone,

SEP seems to offer superior security compared to the Windows firewall.  However, I am not going to reinstall SEP right away.  This small office network is supposed to go "live" on Friday, and I simply can't spend any more time trying to troubleshoot this underlying problem with the firewall and rule enforcement.  I will do so after the users are up and running on the network and things settle down somewhat.  I am interested to see if the problem recurs when I reinstall SEP M4 from scratch.  I will post back then and let you know.

Thanks again for all of your assistance throughout this process.  I greatly appreciate it.

 

[ℬrίαη]

Another thing to check is to ensure the Base Filtering Engine is running. It's a Windows service and the SEP firewall relies on it to function properly.

[John_N]

I checked three servers we have that run the same operating system as the problem server (Windows Server 2012 R2 Essentials).  The Base Filtering Engine is running on all of them, including the problem server.  That server was rebooted as part of the SEP removal process, so I can't say for sure that it was running during the SEP problem period.  I will check again after reinstalling SEP next week and let you know.