locked
DirectAccess with NAP (unable to reach NAP resources) RRS feed

  • Question

  • I already posted in the NAP forums (http://social.technet.microsoft.com/Forums/en/winserverNAP/threads), but thought I'd try my luck here as well.

    I'm running IPsec NAP on two indentically configured Windows 2008 R2 servers that are also standalone CAs for NAP.

    I'm in the testing phases of a Windows 2012 RC DirectAccess server that is behind a NAT. When the computer establishes a DirectAccess connection it's unable to connect to any resource that are part of NAP (only non-NAP resources, exceptions are available). napstat reveals that the client is healthly (it also has the health certificate). I currently haven't checked the "Enforce corporate compliance for DirectAcces clients with NAP" I don't have a need to check client before they connect to the intranet tunnel.

    Here's how the Connection Security Rules look on a client:


    The first four were automatically generated by the DirectAccess server, the other four are for NAP purposes (before a DA test server was introduced).

    What am I doing wrong, are additonal logs, information needed to better assist me.

    Monday, July 16, 2012 11:06 AM

All replies

  • Hi

    So you have a System Heath Authentication certificate on your client computer and your client is healthy. So you have the first IPSEC tunnel (infrastructure). You should be able to see it in the Windows Firewall console on your client or server.

    Try to enable advanced audit for IPSEC on your client computer and Windows Server 2012 to trace potential IPSEC negociations failures. At last, are you using Windows 7 clients or Windows 8 clients?


    BenoitS - Simple by Design http://danstoncloud.com/blogs/simplebydesign/default.aspx

    Saturday, August 4, 2012 4:17 PM
  • Hi, thank you very much for taking the time to assist me.

    Yes, I have a System Heath Authentication certificate and have full network access as evidenced by napstat, but I can't access (file share, ping) any computers, servers protected with NAP.

    Here's how the Connection Security Rules look on the LAN:

    And through DA:

    How can I enable advanced audit for IPSec, all I can find is: http://technet.microsoft.com/en-us/library/cc754714%28v=ws.10%29.aspx but the command doesn't work on WS2012?

    I've tested with both Windows 7 and Windows 8 clients, the result is the same.

    Monday, August 6, 2012 10:49 AM
  • And this is how it looks like. MMC cerfificates, DA Properties - for some reason I don't have the ability to Collect/View Logs (it's grayed out), napstat/NAP and ping a DC that is not under NAP:

    Monday, August 6, 2012 10:49 AM
  • Hi,

    To enable IPsec advanced logging, take the GPEDIT.MSC console and develop : Computer Configuration\Windows Settings\security Settings\Advanced Audit Policy Configuration\System Audit Policies\Logon/Logoff and enable audit options related to IPSEC.


    BenoitS - Simple by Design http://danstoncloud.com/blogs/simplebydesign/default.aspx

    Monday, August 6, 2012 12:21 PM
  • And at last. Are you sure your DirectAccess infrastructure is operational without NAP. I learned from my own experience that we should always built the diretAccess infrastructure without NAP at first for validation purpose then you activate NAP.

    BenoitS - Simple by Design http://danstoncloud.com/blogs/simplebydesign/default.aspx

    Monday, August 6, 2012 12:25 PM
  • I enabled logging and I get a ton of Event ID's 4653 IPsec Main Mode Audit Failures on the client side, no failures on the server side. Some of the failures are for external addresses, some for a remediation server, but I can easily reproduce the error if I try to connect to a resource that is under NAP. This is me trying to connect to our Exchange server (protected by NAP) C$ share:

    Log Name:      Security
    Source:        Microsoft-Windows-Security-Auditing
    Date:          6.8.2012 14:36:37
    Event ID:      4653
    Task Category: IPsec Main Mode
    Level:         Information
    Keywords:      Audit Failure
    User:          N/A
    Computer:      pc1.domain.local
    Description:
    An IPsec main mode negotiation failed.
    
    Local Endpoint:
    	Local Principal Name:	-
    	Network Address:	192.168.43.200
    	Keying Module Port:	500
    
    Remote Endpoint:
    	Principal Name:		-
    	Network Address:	10.10.0.56
    	Keying Module Port:	500
    
    Additional Information:
    	Keying Module Name:	IKEv1
    	Authentication Method:	Unknown authentication
    	Role:			Initiator
    	Impersonation State:	Not enabled
    	Main Mode Filter ID:	79541
    
    Failure Information:
    	Failure Point:		Local computer
    	Failure Reason:		Negotiation timed out
    
    	State:			Sent first (SA) payload
    	Initiator Cookie:		46d18d5995ff7108
    	Responder Cookie:	0000000000000000
    Event Xml:
    <Event xmlns="http://schemas.microsoft.com/win/2004/08/events/event">
      <System>
        <Provider Name="Microsoft-Windows-Security-Auditing" Guid="{54849625-5478-4994-A5BA-3E3B0328C30D}" />
        <EventID>4653</EventID>
        <Version>0</Version>
        <Level>0</Level>
        <Task>12547</Task>
        <Opcode>0</Opcode>
        <Keywords>0x8010000000000000</Keywords>
        <TimeCreated SystemTime="2012-08-06T12:36:37.972699700Z" />
        <EventRecordID>7794</EventRecordID>
        <Correlation />
        <Execution ProcessID="616" ThreadID="648" />
        <Channel>Security</Channel>
        <Computer>pc1.domain.local</Computer>
        <Security />
      </System>
      <EventData>
        <Data Name="LocalMMPrincipalName">-</Data>
        <Data Name="RemoteMMPrincipalName">-</Data>
        <Data Name="LocalAddress">192.168.43.200</Data>
        <Data Name="LocalKeyModPort">500</Data>
        <Data Name="RemoteAddress">10.10.0.56</Data>
        <Data Name="RemoteKeyModPort">500</Data>
        <Data Name="KeyModName">%%8222</Data>
        <Data Name="FailurePoint">%%8199</Data>
        <Data Name="FailureReason">Negotiation timed out
    </Data>
        <Data Name="MMAuthMethod">%%8194</Data>
        <Data Name="State">%%8202</Data>
        <Data Name="Role">%%8205</Data>
        <Data Name="MMImpersonationState">%%8217</Data>
        <Data Name="MMFilterID">79541</Data>
        <Data Name="InitiatorCookie">46d18d5995ff7108</Data>
        <Data Name="ResponderCookie">0000000000000000</Data>
      </EventData>
    </Event>

    As for your last question. I'm not using: "Enforce corporate compliance for DirectAcces clients with NAP". I already had a NAP IPsec implementation and want to implement DirectAccess, I don't have a need to check clients before they connect to the intranet tunnel.

    A simple test I perform is, connect through my 3G card (no WiFi, LAN to our corporate network), wait for internet access and a DirectAccess connection and I can easily ping open a share of a DC, remediation server. I try opening a share of a server that is protected by NAP and I don't have access. I move that server to a different OU where NAP is not enforced and I can easily open the share.

    Monday, August 6, 2012 1:02 PM
  • OK

    So it's much more a client-side related problem. Your User tunnel does not work, that's why you can only access to ressources accessible with the infrastructure tunnel of your machine.

    Do you have NAP enabled on your LAN too?


    BenoitS - Simple by Design http://danstoncloud.com/blogs/simplebydesign/default.aspx

    Monday, August 6, 2012 1:09 PM
  • What makes you say my User tunnel doesn't work? I can access resources on my LAN without issues, if they're not under NAP.

    NAP is enabled for all client PCs and most servers (exemptions are DCs, remediation server and a file server used for GPO installs). I haven't made any configurations with regards to DirectAccess and its NAP functionality (Enforce corporate compliance for DirectAcces clients with NAP is not enabled).

    Should I provide additional logs, configurations anything that would allow you to assist me.

    Monday, August 6, 2012 1:40 PM
  • Hi

    Error from me. So your DirectAccess clients can only connect to Non NAP enabled computers located on your LAN. These servers can be configured as infrastructure server for DirectAccess (for remote management capabilities) or not. In this situation, it is much more a problem during IPSEC tunnel negociation with your NAP enabled computers. According to your first capture. Your NAP firewall rules will not work with DirectAccess. Three of them are referencing IPv4 addresses that cant go inside IPv6 tunnel. For the last rule, have a look if you do not use IPv4 addresses inside.

    Note : You cannot have an IPSEC Connection security rule configured in tunnel mode to pass throught another IPSEC tunnel. Your NAP firewall rule should be in transport mode, so based on an isolation mode.


    BenoitS - Simple by Design http://danstoncloud.com/blogs/simplebydesign/default.aspx

    Monday, August 6, 2012 9:57 PM
  • Hi BenoitS, that is correct. When a DirectAccess client connects through Workplace connection/DirectAccess it's unable to reach any NAP enabled computers. When on the LAN it can reach everything as normal (which probably makes sense, there's only one IPsec to deal with).

    My client NAP rules are as follows:

    - three Exception rules (I don't think these are the problem):

    • Exception SSL-INT - we currently use a SSL VPN appliance and the users are provided with a range of IPs: 10.10.201.0/24, for which I made exceptions. In this case two IPsec connections were not supported (similar to the issue here):

    Source IP

    Destination IP

    Source port

    Destination port

    Authentication

    10.10.201.0/24

    10.10.0.0/24

    10.10.1.0/24

    Any

    Any

    Do not authenticate

    • Exception TCP – common TCP ports where we don't require NAP authentication:

    Source IP

    Destination IP

    Source port

    Destination port TCP

    Authentication

    Any

    Any

    Any

    21, 25, 53, 80, 443, 3389, 27150

    Do no authenticate

    Source IP

    Destination IP

    Source port

    Destination port (UDP)

    Authentication

    Any

    Any

    Any

    53, 1812

    Do not authenticate

    - and one rule that requires authentication is the IPsec NAP Secure Rule (is this the problem?):

    Tunneling is not used, it is in transport mode:

    The DirectAccess Clients Settings are very basic and can be seen at the beginning of the post.

    Are my NAP settings and the DirectAccess ones incompatible? If so, what exactly do I need to do to resolve this? How is this implemented in other environments where NAP on the LAN is needed, but DirectAccess is also being used?

    Tuesday, August 7, 2012 6:57 AM
  • Hi


    According to your informations, your transport IPSEC tunnels seems to establish well from the client to your secured server but not in the other way. Some network traces on the secure server side, will confirm this hypotesis. Does your secured servers have an ISATAP address or simply a NAT64 generated address?


    BenoitS - Simple by Design http://danstoncloud.com/blogs/simplebydesign/default.aspx

    Tuesday, August 7, 2012 9:26 AM
  • BenoitS, I was certain I replied to this and was actually waiting on your reply.

    Anyhow, could you please elaborate what makes you think this and would you be so kind to assist me in providing you with all the required information. I can upload configurations... anything that is needed.

    Going over my servers it appears only the DirectAccess server has an ISATAP address, I haven't made any changes as far as this, thinking Windows Server 2012 should handle this without issue.

    Thank you very much for your assistance, I'm puzzled as to how I'm the only one with this issue. Have you ever had a case like this, is there an implementation where NAP on the LAN was needed, but DirectAccess was being used, that you were a part of?

    Friday, August 17, 2012 5:10 AM
  • Hi

    ISATAP is not mandatory for DirectAccess, you're right. When you protect ressources with NAP, this means that you created a transport rule on your secured resource that requires a System Health Certificate to be provided by the client. Your DirectAccess client also have an IPSEC transport rule. This transport rule will work if your secured NAP resource have an ISATAP address. Your tunnel cannot start in IPv6 and finish in IPv4. We must be sure that NAP protected ressources are able to initialize an isatap interface. For this :

    -Be sure that all your DNS servers does not block ISATAP (DNSCMD.EXE /CONFIG /QueryBlockLIST WPAD

    -Be sure that you have an ISATAP record in your DNS that point to the internal interface of your DA server

    -be sure you have ICMPv4 and IP41 network flow open between your NAP protected ressources and your DA Server.


    BenoitS - Simple by Design http://danstoncloud.com/blogs/simplebydesign/default.aspx

    Friday, August 17, 2012 4:13 PM
  • It's actually not a good idea to enable ISATAP globally like this (sorry Benoit, I'm not trying to be hard on you) :)

    If you need ISATAP for whatever the reason, enable it selectively. Jason Jones wrote a great article on doing this: http://blog.msedge.org.uk/2011/11/limiting-isatap-services-to-uag.html

    If you enable ISATAP globally, it might be fine. However, it might not. As soon as you enable the word "ISATAP" in DNS, every ISATAP-capable host will grab an ISATAP address and start routing with it, and it can cause major problems on some networks for all of this to happen at once, and it can be difficult to recover from it.

    Friday, August 17, 2012 6:03 PM
  • No problem Jordan. Your right. I do not have enought time theses days.

    So Jordan remark is good. ISATAP is required (Your IPSEC transport start in IPv6 and must end with IPv6) but limited ISATAP. So Let-s change my recommandation :

    -Do not remove ISATAP from the DNSQueryBlockList

    -Be sure to configure each NAP protected ressources with an ISATAP interface (manually or by GPO

    -Be sure you open the required network flow for ISATAP clients.

    Generalization of ISATAP is not a good recommandation today. In your situation (DirectAccess with NAP) will require ISATAP but only for NAP protected ressources.

    Sorry for my quick answer.

    Thank you for you help Jordan.


    BenoitS - Simple by Design http://danstoncloud.com/blogs/simplebydesign/default.aspx

    Friday, August 17, 2012 6:16 PM
  • Thank you both, as I'm sure you noticed by now, I'm a bit of a novice when it comes to DirectAccess/IPv6, but am definitely learning as I go, with your help I might add.

    I'm currently working from home for a week or so and don't have access to a DirectAccess client to test, but would like to be clear about everything before making any changes to my production environment.

    Since I'm using DA with a single NIC (NATed), everything goes through IPHTTPS, does Protocol 41 matter in this case, it usually gets mentioned with regards to 6to4? I'm having a hard time finding the appropriate firewall rule(s) to open on my Windows 2008/2012 servers for Protocol 41, which are the correct ones?

    Regarding ISATAP, a few articles (http://blogs.technet.com/b/tomshinder/archive/2011/02/14/use-a-hosts-file-entry-to-control-isatap-host-configuration.aspx, http://blogs.technet.com/b/tomshinder/archive/2010/10/01/is-isatap-required-for-uag-directaccess.aspx, http://blogs.technet.com/b/tomshinder/archive/2011/02/21/clearing-the-air-on-isatap.aspx, ) that mention it usually refer to manage-out scenario (not my issue) and actually recommend avoiding it if possible (go with IPv6 instead).

    For testing, could I not just provide one of my NAP protected servers running Windows Server 2008 R2 with a IPv6 address (they already have link local addresses, but not statically provided; IPv6 is not disabled on any servers that support it) and/or perhaps create a AAAA DNS record? Or is there a difference since I am using NAP.

    Thank you again for your patience/guidance.

    Saturday, August 18, 2012 5:08 AM
  • Hi

    IPHTTPS is IPV6 in HTTPS. So it is 443. 6to4 is used when your DirectAccess clients are connected to internet with a public IPv4 address (so at home with a brand new Internet box without NAT enabled).

    ISATAP is required for manage-out scenario (internal computer connecting to a DirectAccess client). But in your situation, you also need it for NAP because your Connection Security Rules start on Internet in IPv6 and must end in IPv6 too (DNS64/NAT64 wont help).

    For testing purpose, you can put an ISATAP record in the host file of one of your NAP protected ressources and ensure that IP41 and IMCPV4 are open to your DA Box. Your compyter should be able to initialize an ISATAP interface (restarting the IPHLPSVC service might be helpfull). There is no need for additional DNS records. Once ISATAP interface is initialized, dynamic DNS registration will handle that.


    BenoitS - Simple by Design http://danstoncloud.com/blogs/simplebydesign/default.aspx

    Saturday, August 18, 2012 9:04 AM
  • BenoitS, thank you so much, I'll test as soon as I get a chance and report back.
    Saturday, August 18, 2012 10:12 AM
  • Also, you are correct that if you create a native IPv6 connection for these servers, you do not need ISATAP. ISATAP is a stepping stone between IPv4 and IPv6. If you have the capability to implement true IPv6 inside your network for these NAP servers (the DirectAccess box needs to be tied into the v6 network as well), then you do not need ISATAP.
    Tuesday, August 21, 2012 2:16 PM
  • Jordan, thank you for your reply.

    Since I'm stil working from home and will be for a week or two, I have time to consider my options. The more I have the better chance of success I have when testing it all out.

    All servers 2008 R2 have IPv6 enabled, link local addresses exist on all, could you perhaps provide a link or two as to what needs to be done to implement true IPv6 inside the network. What am I missing, where to start.

    Tuesday, August 21, 2012 5:26 PM
  • You'll probably want to start by making sure any routers or infrastructure you have on the network is capable of handling IPv6 traffic. As long as it is, you can find a lot of information by searching for "implement IPv6" and similar phrases on the internet. Joe Davies also recently released a book that will probably help quite a bit, "Understanding IPv6, Third Edition". Really you need to consider the same things as with your IPv4 network - Setup DHCPv6 for handing out IP addresses, how are you going to handle routing, things like that.
    Tuesday, August 21, 2012 6:20 PM
  • Thank you Jordan, I'll probably go down the ISATAP route for now, but have had my eye on Understanding IPv6, Third Edition for some time...maybe it's time for a buy.
    Wednesday, August 22, 2012 5:52 AM
  • Sure Native IPv6 networks are the future but it's a long path. Except for some large organization having problem to manage their networks moving to IPv6 we all need to investigate more about this migration. Builging an IPv6 lab in your networks should be a good starting point for application compatibility testing.

    BenoitS - Simple by Design http://danstoncloud.com/blogs/simplebydesign/default.aspx

    Wednesday, August 22, 2012 7:33 AM
  • I finally got around to testing this (my appologies for the late reply, but I had some medical issues). I created a new GPO to enable ISATAP as per: http://blog.msedge.org.uk/2011/11/limiting-isatap-services-to-uag.html added a few servers to the group and while they all have ISATAP interfaces enabled I'm still unable to access NAP resources from my DA connected clients (apart from my DA server) and vice-versa I can't access the DA connected clients from my NAP servers (apart from my DA server).

    If I enable the exemption of ICMP from IPsec I can ping the servers from my DA clients without problems, but that's it.

    IP41 and ICMPv4 & v6 are open to the DA server.

    Things I noticed and am not sure if they're OK:

    - DA connected clients register their ISATAP AAAA records in DNS, but that doesn't happen for NAP protected servers (should they?) on the LAN that have had the ISATAP GPO applied.

    - the ISATAP interface for DA connected clients changes from the GPO configured one (isatap.domain.com) while on the LAN to a isatap.some_GUID while connected through DA. The DA server always has the isatap.some_GUID one even though that GPO also applies to it.

    Tuesday, November 13, 2012 2:39 PM
  • Hi Miha,

    A bit late to the party, but a few thoughts to consider for what they are worth...

    I know the issue is not specifically DirectAccess NAP related, but have you tried seeing what happens if you actually enforce NAP for the DirectAccess configuration? From what I can tell, you have everything in place to achieve this, so it shouldn't be difficult to test.

    Although you haven't mentioned SDI, this sounds like a similar problem to me, so it may be worth looking at the following guideance on using DirectAcccess alongside SDI as discussed here:

    http://technet.microsoft.com/en-us/library/ee382288(v=ws.10).aspx

    http://technet.microsoft.com/en-us/library/ee809063.aspx

    These may not solve the problem, but may give you an understanding of how you can get the connections security rules to work together to acheive what you need. My gut feeling is that you have some form of connection rule overlap/conflict from trying to combine the technology/solutions.

    Let us know how you get on!

    Cheers

    JJ


    Jason Jones | Microsoft MVP | Silversands Ltd | My Blogs: http://blog.msedge.org.uk and http://blog.msfirewall.org.uk

    Thursday, November 15, 2012 9:39 AM
  • Hi,

    OK. So we have ICMPv6 connectivity from a DirectAccess client connected on Internet and a NAP Protected ressources only if you allow ICMP exception on tunnel configuration on both sides and NAP protected ressources have an ISATAP address. This look like a problem i had while writing a recent blog post : http://danstoncloud.com/blogs/simplebydesign/archive/2012/08/01/directaccess-challenge-series.aspx. It was performed on UAG 2010 but can be applied on Server 2012 because the is no DirectAccess configuration change. This post describe how to establish a secure communication between a DirectAccess client connected on Internet and a a protected ressources (Not NAP enabled). Protection rely on isolation rule. So it's an IPSEC transport, not an IPSEC tunnel. But it's the same as my IPSEC transport require certificate authentication. Can you check if my scenario would solve your problem?

    Don't forget to have a look at links provided by Jason. IPSEC tunnels created for DirectAccess use a specially configured IPSEC negociation configuration. Remember that these parameters are global and not only apply to DirectAccess IPSEc tunnels but also on your IPSEC tunnels.

    From my knowledge, it is not possible to establish an IPSEC tunnel throught a DirectAccess because Exempt IPSEC protected connection is not enabled. I know that if we enable this parameter in both DirectAccess client and UAG, this solved my Tunnel in tunnel (Inception ?). But this means changing DirectAccess configuration, so unsupported scenario. Thats why i did not document it.

    Best regards.


    BenoitS - Simple by Design http://danstoncloud.com/blogs/simplebydesign/default.aspx

    Friday, November 16, 2012 4:21 PM
  • I am trying to get SDI and DA work togheter but I have no luck..

    The URL to the blog above does not work, is it moved somewhere ?

    Regards Jonas

    Wednesday, August 7, 2013 11:43 AM
  • Hi

    My blog suffer from hosting provider problems. Will be back in a few days.


    BenoitS - Simple by Design http://danstoncloud.com/blogs/simplebydesign/default.aspx

    Wednesday, August 7, 2013 4:08 PM
  • Thanks!

    I have read your blog several times but I can't make it work.

    If i connect to internal machine from DA client and then do a netstat -an on internal machine the Established Connection for that port is an IPv4 adress (DA server ipv4 internal ip).

    That should be an IPv6 adress right ?

    I am running windows 2012 on my DA server and some things have changed from UAG but I can't figure it out.


    /Jonas

    Friday, August 23, 2013 1:05 PM
  • isatap was disabled on internal host. Now, when I ping DA server from internal host it use isatap and not IPv4.

    But when I ping internal host from DA server it lookups IPv4 adress and ping that, should't DA server ping internal hosts with isatap ?

    DA client still connects to internal host with IPv4 (DA internal IP) and I think it is the ipv6 to ipv4 traversel that happens in DA that cause the isolation to fail.


    /Jonas

    Friday, August 23, 2013 3:23 PM
  • In DirectAccess 2012, when using ISATAP, you need to enable AAAA queries for DNS64 with the PowerShell cmdlet, Set-NetDnsTransitionConfiguration -OnlySendAQuery $false

    This may be the cause of your problems...

    P.S. This is documented in section 1.1.2 here: http://technet.microsoft.com/en-us/library/jj134148.aspx


    Jason Jones | Security Consultant | Microsoft Consultant Services (MCS)


    Friday, August 23, 2013 3:54 PM
  • After I changed to false my DA client failes to connect to Corporate network.

    If i change back everything works as normal again (except isolation).


    /Jonas


    • Edited by J_augustine Friday, August 23, 2013 4:10 PM
    Friday, August 23, 2013 4:09 PM
  • The change should simply affect DNS64 and the results returned when AAAA records exist in DNS...I wouldn't expect that to break core DA

    Jason Jones | Security Consultant | Microsoft Consultant Services (MCS)

    Friday, August 23, 2013 4:12 PM
  • Hi

    Now we have an ISATAP connectivity of computers that requires isolation. With your NAP infrastructure already deployed, you should already have IPSEC transport rules that apply apply only when firewall is in domain mode.

    With DirectAccess even if you have access to corporate connectivity your client firewall mode is private or public not domain. So you need a specific set of transport rules that apply to these firewall profiles (more easy to debug rather than a singlet set of transport rule for both scenarios). These new set of transport rules will requires the System Health Certificate to establish communication with your NAP protected servers. Thèses servers must be identified with ISATAP or native IPv6 rather tha IPv4.


    BenoitS - Simple by Design http://danstoncloud.com/blogs/simplebydesign/default.aspx

    Sunday, August 25, 2013 8:44 PM
  • Today after your suggested command, Set-NetDnsTransitionConfiguration -OnlySendAQuery $false and DA server restart I finaly got SDI ipsec traffic through DA Ipsec tunnel.

    Now I just have to make the correct isolationrules for both internal ipv4 hosts and external (ipv6) host.

    I also need a ISATAP gpo for just my internal hosts that shall be reachable from DA-clients.

    Thanks for your help!

     


    /Jonas

    Monday, August 26, 2013 7:38 AM
  • Happy for you it start working.

    BenoitS - Simple by Design http://danstoncloud.com/blogs/simplebydesign/default.aspx

    Monday, August 26, 2013 8:18 AM
  • Thanks to all I also made some progress. I built a new DA server and most of my issues are resolved, it appears the missing piece was Set-NetDnsTransitionConfiguration -OnlySendAQuery $false as outlined by Jason.

    I'm currently testing without DA NAP Enforcement mode and everything seems fine (manage out, access to all resources), although I'm puzzled why I still have access to resources even if the client is unhealthy.

    If I turn on (my prefered option) DA NAP Enforcement I get "Action Required" same as another person here: http://social.technet.microsoft.com/Forums/windowsserver/en-US/d9b02077-502d-4e0e-96a5-87002ecf4d4c/nap-on-2008-r2-with-directaccess-2012-rc. I'm only currently testing with Win8, Win7 is to follow shortly.

    Monday, September 2, 2013 11:29 AM
  • Hi

    When NAP enforcement mode is disabled health certificate is not required during user IPSEC tunnel negociation. Do you use isolation rules or tunnel rules for your internal NAP. If it's Tunnel mode, we need to reconfigure some additional parameters to exempt IPSEC connections. Inception does not apply to IPSEC tunnels. We cant establish IPSEC tunnel Inside IPSEC tunnels.


    BenoitS - Simple by Design http://danstoncloud.com/blogs/simplebydesign/default.aspx

    Monday, September 2, 2013 12:23 PM