I'm currently implementing a DirectAccess 2012 R2 for a customer using VSE 8.8 to protect their servers.
I'm facing a strange issue as, when VSE 8.8 (with Patch4) is installed on the DirectAccess Server, the client computers are unable to connect to the Corporate Network .
Deeper diagnotic shows that, when VSE is installed on the server, UDP 500 packets required for IPsec tunnels are dropped by the Windows Firewall.
When I remove VSE, everything is working.
The only workaround I've found to use VSE on the server is to create a Inbound rule in the Windows Firewall allowing UDP 500 on the Public profile.
Why is VSE 8.8 acting like this?
>UDP500 packets required for IPsec tunnels are dropped by the Windows Firewall
>Why is VSE 8.8 acting like this?
You've confused where this question should be directed.
3rd party product behaviors that change simply because our product is installed is not something we can answer, as we cannot debug other people's code.
And with all our efforts spent in analyzing data for what our product _is_ doing when the Windows Firewall drops said packets, we see our product is behaving normally. It's a futile path for us to investigate why the Windows Firewall is doing something abnormal due to normal behavior from our product. We can accept being a catalyst based on the observation but the cause is still unknown.
What 3rd party product? It's DirectAccess - Part of Windows Server 2012. Actually, DirectAccess has been around for a while from Microsoft.
What he's describing is VirusScan BREAKING DirectAccess... which it seems to be good at doing. McAfee KB KB79622 talks about it breaking an older version of DirectAccess, and a number of people, myself included see it breaking Windows 8.1 DirectAccess clients.
I'm opening a support ticket on this, as McAfee seems very quiet on this item. Frankly, as DirectAccess is a key piece of our remote access solution, if McAfee doesn't fix this, this won't help them when we do an evaluation of endpoint security solutions later this year (We've been a McAfee customer for almost 15 years now).
Hallelujah! Thank you for posting your UDP 500 firewall change. This has allowed IPSEC to work on a system that is required to run McAfee Enterprise.
Through extensive testing I have discovered that McAfee VirusScan 8.8 Enterprise Patch 3 and Patch 4 both do not play nicely with Windows Firewall in both Windows 7 and Windows 8. Windows Firewall is REQUIRED for Microsoft DirectAccess.
The symptoms I've seen are:
Win7/Win8.1: Windows Advanced Firewall logging is disabled
Win8.1: Windows Advanced Firewall Inbound rules with an IPv6 address specified as a remote IP in the Scope property with Allow traffic do not work.
I have enabled ISATAP (IPv6 tunneling over IPv4) on the corporate Intranet and am attempting to provide "Manage Out" functionality to the DirectAccess remote clients. Windows 7 seems to work, but Windows 8.1 fails.
The KB79622 describes problems when McAfee is installed on the DirectAccess server. I am not running McAfee on our server, only on the clients. Our symptoms are all on client symptoms. Therefore it appears I will need to open a new issue with support to see if McAfee has workarounds or agrees this is a bug/incompatibility with DirectAccess.
What I determined (with help from McAfee escallation to tier 2 gold support) was that the packaging of VSE 8.8 Patches 2-3-4 caused our problem noticed on Windows 8.1 and DirectAccess. When we installed the full installation at Patch 2 level and updated directly to Patch 4 with a delta-only update, the problems noted with DirectAccess went a way. I was told by tier 2 that this issue will be addressed in Patch 5. I am assuming the an error in packaging of updates in Patch 3 or 4 caused the issue.
Glad you got it sorted.
I am assuming the an error in packaging of updates in Patch 3 or 4 caused the issue.
I would that it could be that simple. The issue is due to how our WFP driver registers with the WFP framework, that a full install of 8.8 P4 seeks "highest" weight within that framework whereas in P2 it sought "automatic" or none. When obtaining that highest assignment we inadvertently break IPSec. It is solvable though, just not for Patch 4 unless you do an install of 8.8 P2 and upgrade to 4 (which preserves the prior weight assignment of none).
What patch 5 does is register the driver's callouts with the WFP framework to have "highest" where appropriate and "automatic" where IPSec is concerned.
Does the VSE on client side issue only cause a problem when DA is using Toredo or 6to4 connections? We've been running Win8 & Win8.1 with VSE8.8p4 (bundled, not upgrade) and not had any issues that we are aware of.
We don't have VSE running on the DA servers; and all clients connect via IPHTTPS only (as servers are Load Balanced & Nat'd).