locked
Symantec Endpoint Protection blocking DA RRS feed

  • Question

  • This is driving me crazy.  DirectAccess works great with SEP disabled.  With SEP enabled, we are not able to create a tunnel.  We have double and triple checked the suggested configuration from Symantec and it is correct.  However, we do not connect.  The issue seems to be with failure on IPSec authentication, we can see the connection to the UAG server and we can see IPv6 addresses assigned to the Teredo interface and the httpstunnel interface, but the UAG server does not report the creation of a tunnel.  The command 'netsh advfirewall monitor show consec' returns "No SAs match the specified criteria."  Running the same command with SEP disabled returns OK and reports on the tunnels.  I am guessing that there is a bug in our current version of SEP which 12.1.1000.157 RU1.  Has anyone else run into this?

    The early bird gets the worm. The second mouse gets the cheese.

    Monday, September 24, 2012 10:27 PM

Answers

  • We finally figured it out, in addition to the standard exclusions for IPv6, and IPSec, we had to add an exclusion for Ethernet Protocol 0x1111 and Ethernet Protocol 0x1112 (where 1111 and 1112 are last four digits of the public facing IPv6 addresses for the DA Server).  Apparently, when negotiating IPSec, the client negotiates its high ports based on the decimal conversion of the hex.  In my example here, the ports would be 4369 and 4370.  As you can imagine we had to dive pretty far into SEP to figure exactly what was going on.  Anyway, I hope this helps somebody figure this out more quickly that we did.

    The early bird gets the worm. The second mouse gets the cheese.

    • Marked as answer by David K Welch Wednesday, October 10, 2012 8:14 PM
    Wednesday, October 10, 2012 8:14 PM

All replies

  • Hi David

    I think the low tech solution could be that if you have the firewall part of SEP activated i think you need to disable that and rely on the built in Windows Firewall instead.

    /Alex

    Tuesday, September 25, 2012 12:43 PM
  • That would be my choice as well, to scrap SEP and move to FEP, but that is not my reality.

    The early bird gets the worm. The second mouse gets the cheese.

    Tuesday, September 25, 2012 12:46 PM
  • I have found two different rules in SEP's Network Threat Protection and either one blocks Directaccess. The first is a pretty clear "disable Teredo" rule that I have found put into place by default on some clients. And the other is a "disable IPv6" rule which also kills it.

    Some of the companies I have worked with have just disabled Network Threat Protection (in my experience it doesn't do a whole lot of good anyway), or if you check for and disable those rules, hopefully that will get you up and running.

    Wednesday, September 26, 2012 12:36 PM
  • Jordan, thanks for the reply, but those rules are not in effect.  I make connections and get IPv6 addresses on the interfaces.  It is just not negotiating the IPSec authentication required for the secure tunnel.   We have involved Symantec, if they come up with something, I will post it here.

    The early bird gets the worm. The second mouse gets the cheese.

    Wednesday, September 26, 2012 1:20 PM
  • We finally figured it out, in addition to the standard exclusions for IPv6, and IPSec, we had to add an exclusion for Ethernet Protocol 0x1111 and Ethernet Protocol 0x1112 (where 1111 and 1112 are last four digits of the public facing IPv6 addresses for the DA Server).  Apparently, when negotiating IPSec, the client negotiates its high ports based on the decimal conversion of the hex.  In my example here, the ports would be 4369 and 4370.  As you can imagine we had to dive pretty far into SEP to figure exactly what was going on.  Anyway, I hope this helps somebody figure this out more quickly that we did.

    The early bird gets the worm. The second mouse gets the cheese.

    • Marked as answer by David K Welch Wednesday, October 10, 2012 8:14 PM
    Wednesday, October 10, 2012 8:14 PM