Endpoint Protection

Scenario:

The HyperV hosts and hosted VM's all have AV + NTP installed, the firewall policy for the hosts only have rules necessary for the hosts themselves, not the hosted VM's (they have their own FW policies).  We have just upgraded to 12.1 RU6 MP7 from 12.1 RU5, now NTP on the host is blocking traffic destined for its VM.

In the host's NTP traffic log, the VM's MAC and IP address are shown in the local host details. 

I can work around this by creating a rule to allow all traffic to the VM's MAC address, however why do I now need to create these rules?

I have a case raised - 13921775, however Symantec support have been fairly poor, with the advice given of 'uninstalling NTP' and that this is fixed in MP8 (different issue): FIX 4074754 https://support.symantec.com/en_US/article.INFO4367.html

I have found the following threads, but none have a solution:

https://www.symantec.com/connect/forums/endpoint-protection-firewall-blocking-hyperv-vm

https://www.symantec.com/connect/forums/sep-windows-81-hyper-v-host-ntp-blocking-guest-vm

Any help appreciated!

Anybody?

So this worked as expected without needing allow rules prior to upgrading? 

If so, I'd suggest you get your case escalated to back line/dev for further analysis. Seems something changed within the actual code.

Hi Brian, yes, this worked just fine without any allow rules necessary for the hosted VMs.  If I roll the client back to 12.1.5 the issue disappears.  

I have an update on my previous statement that I can workaround the issue - rather than create a rule for each VM's MAC (we have a lot!), I have added the HyperV hosts' MAC addresses as local hosts in the block rules, therefore theoretically allowing any traffic not destined for the host to pass through to the VM - this does not work either.

Firewall policy only has rules for the HyperV hosts; the VMs have their own firewall policies.  Any traffic destined specifically for a VM is dropped at the HyperV hosts e.g. DNS destined for a DC – dropped, LDAP destined for a DC – dropped, SEP communication traffic destined for the SEPM – dropped.  None of this traffic is marked as dropped in the HyperV host traffic log, but does not reach the VM.

I have tried the following:

• 1 x brand new firewall policy created and applied to the HyperV hosts to rule out corruption of the original firewall policy – same issue exists
• SEP client upgraded to 12.1.6 MP9 (12.1.7384.6902) – same issue exists
• Firewall policy withdrawn – issue disappears

Seems to be a code change of some sort in this newer version - whether it's a bug or intended I don't know. Seems your case should be escalated.

I've asked, I will update when I have some more info.

@bungers

Please see the topic I created almost 2 years ago:

https://www.symantec.com/connect/forums/issue-hyper-v-host-after-upgrade-1216-mp4

This sounds very similar to what you are experiencing.  At the time I created a case and I was told the problem would be fixed on future releases.  I seem to recall the problem went away on 12.1.6 MP6 but reappeared on subsequent releases.  I am now on 14.0 RU1 MP1 and the issue is still there.  If I disable the firewall rule I created long ago, the VM Host blocks all communication to the VM client.  In my case the VM client is the SEPM so communication is lost with all other SEP Clients trying to reach the SEPM.  When I turn my rule back on, communication to the VM client is restored.

It would be great if Symantec would state a specific position on this behavior.  For now I think your only solution is to use the rule you created.  Hope this helps.

Thanks CG, looks to be the same issue we are experiencing then.  What rule did you add, a specific TCP 8014 rule to the host MAC address as I presume you already had a TCP 8014 rule to allow comms on the VM firewall?  The strange thing is that there are no blocked entries for the VM in the host NTP traffic log, when I only block traffic destined to the host MAC.

Can I ask if you have upgraded from the earlier 12.x releases through to the latest 14 release, or started fresh?  I ask as if we now migrate to SEP 14, we will have migrated through 2 major versions; I think this carries through issues from older versions.

@bungers

I added a rule to allow all port 8014 communication from a range of private ip addresses (our internal network) access to the static ip of the SEPM VM client.  I used ip instead of MAC but the principle should be the same.  Once I added the rule, the VM Host's firewall allowed traffic from the other sep clients on our network access to the VM client.

We upgraded from 12.x to 14.x rather than starting fresh.  We probably have 20+ generations of upgrades as we moved from 11.x to 12.x to 14.x over the years.

@Bungers

Could you please collect WPP logging while reproducing the issue.  Note the times of issue reproduction as well. 

Make sure to always set the Max file size to 500 and the Trace Level to Verbose.  Please follow the steps in this document to enable the logging: https://support.symantec.com/en_US/article.TECH207795.html

I will take over your case and review the logs once they are available.

Thanks!

John Owens

https://support.symantec.com/en_US/article.TECH239844.html

Issue was confirmed to match https://support.symantec.com/en_US/article.TECH239844.html.

The firewall will block VM traffic by default if it cannot get its application name/process info.  For example, if A.exe opens and lists TCP port 5555, the firewall will know incoming traffic belonging to TCP port 5555 is A.exe.  This mechanism does not work in VMs sometimes. When FW/Symnets cannot find the applications process info it will block that traffic by default.

Workaround:

Change the default firewall rule "Allow all Application" from "*" to "Any"