locked
UAG DirectAccess works... sort of... RRS feed

  • Question

  • I think I have UAG setup correctly, but it only works intermittently on the first try. Sometimes when my laptop boots up everything looks good with the httpstunnel and teredo but I get no connectivity to any resources except ping.

    I have to run these commands to get it to work:

    Netsh int teredo set state disabled
    Netsh int teredo set state enterprise client

    Everything works fine after that.

    Sometimes on boot up everything works ok, other times I can only ping. I'm not sure where to troubleshoot this.

    Thanks,
    B

    Friday, July 2, 2010 9:48 PM

Answers

  • OK, it looks like the intranet tunnel is failing authentication - if that's true, you can access resources through the infrastructure tunnel, is that right?

    If the UAG DA server a member of the same domain as the computer accounts and the user accounts?

    Thanks!

    Tom


    MS ISDUA/UAG DA Anywhere Access Team
    • Marked as answer by Erez Benari Monday, July 26, 2010 11:04 PM
    Monday, July 26, 2010 12:47 PM

All replies

  • This sounds like something related to IPsec. If pings always work, then there's no problem with teredo or IP-HTTPS.

    IPsec is protecting the connectivity to all corp resources (except ping), so you should really troubleshoot your IPsec authentication.

    If you can resolve DNS names, it means the 1st tunnel is established. Please try to access a file share on one of your domain controllers (make sure this DC is configured in the management servers list of UAG DA).

    If this works, then there's a problem with the 2nd tunnel (did you configure NAP or SmartCard?)

    If this doesn't work, then you need to check whether IPv6 stack is enabled on the external interface of the UAG server.

    Anyway, update us with the test results.

    Thanks, Yaniv.

    Wednesday, July 7, 2010 8:13 AM
  • In addition to Yaniv's and Jason's good advice, I'd like to add a bit of explanation.

    When pings work, it indicates that the IPv6 transition technologies are working but does not indicate that IPsec is working correctly. The reason for this is that ICMP is exempt from IPsec protection by default (you can force IPsec encryption on ICMP, but you will lose Teredo connectivity). If ICMP works and non-ICMP protocols don't work, then that's a good indicatation of an IPsec negotiation failure.

    You can open the wf.msc console to check this. Look for Main Mode and Quick Mode Security Associations. Also, look for NTLMv2 and Kerberos authenticated Main Mode connections. The NTLMv2 will indicate that the first (infrastructure) tunnel came up. The Kerberos will indicate that the second (intranet) tunnel came up.

    Enable IPsec logging on the UAG server and repeat your connectivity steps at the client - then check the Security Log file on the UAG server.

    If you would like to review a step by step troubleshooting lab guide I've put together for UAG DA, send me a note at tomsh@microsoft.com

    HTH,

    Tom


    MS ISDUA/UAG DA Anywhere Access Team
    Friday, July 9, 2010 1:39 PM
  • I had a chance to go through Tom's troubleshooting guide, which is great btw, it looks like it is trouble with IPsec negotiation. I'm not sure exactly why it isn't negotiating properly when the computer first boots up, but it negotiates properly if i disable and enable the teredo interface after.

    From the event log:

    Audit Success:

    IPsec main mode and extended mode security associations were established.

    Local Endpoint:
     Principal Name:  QS-UAG-1.Quercus.local
     Network Address: 2002:408d:3138::408d:3138
     Keying Module Port: 500

    Local Certificate:
     SHA Thumbprint: 709643aca84df902a3a642f456356f64c743917f
     Issuing CA:  Quercus-QS-DC-1-CA
     Root CA:  DC=local, DC=Quercus, CN=Quercus-QS-DC-1-CA

    Remote Endpoint:
     Principal Name:  QS-WKS-03.Quercus.local
     Network Address: 2001:0:408d:3137:8f1:22d7:9fcb:7f56
     Keying Module Port: 500

    Remote Certificate:
     SHA Thumbprint: 0a60b31edd8a0c6f416862caadfb895eef182b0d
     Issuing CA:  Quercus-QS-DC-1-CA
     Root CA:  DC=local, DC=Quercus, CN=Quercus-QS-DC-1-CA

    Cryptographic Information:
     Cipher Algorithm: AES-128
     Integrity Algorithm: SHA 256
     Diffie-Hellman Group: None

    Security Association Information:
     Lifetime (minutes): 60
     Quick Mode Limit: 0
     Main Mode SA ID: 154

    Additional Information:
     Keying Module Name: AuthIP
     Authentication Method: SSL
     Role:   Responder
     Impersonation State: Not enabled
     Main Mode Filter ID: 82811
     
    Extended Mode Information:
     Local Principal Name: host/QS-UAG-1.Quercus.local
     Remote Principal Name: QUERCUS\QS-WKS-03$
     Authentication Method: NTLM V2
     Impersonation State: Enabled
     Quick Mode Filter ID: 82835

    Audit Failure:

    An IPsec extended mode negotiation failed. The corresponding main mode security association has been deleted.

    Local Endpoint:
     Principal Name:  host/QS-UAG-1.Quercus.local
     Network Address: 2002:408d:3137::408d:3137
     Keying Module Port: 500

    Remote Endpoint:
     Principal Name:  -
     Network Address: 2001:0:408d:3137:8f1:22d7:9fcb:7f56
     Keying Module Port: 500

    Additional Information:
     Keying Module Name: AuthIP
     Authentication Method: Kerberos
     Role:   Responder
     Impersonation State: Enabled
     Quick Mode Filter ID: 82879

    Failure Information:
     Failure Point:  Remote computer
     Failure Reason:  IKE authentication credentials are unacceptable

     State:   Sent second (SSPI) payload

    Audit Success:

    IPsec main mode and extended mode security associations were established.

    Local Endpoint:
     Principal Name:  QS-UAG-1.Quercus.local
     Network Address: 2002:408d:3138::408d:3138
     Keying Module Port: 500

    Local Certificate:
     SHA Thumbprint: 709643aca84df902a3a642f456356f64c743917f
     Issuing CA:  Quercus-QS-DC-1-CA
     Root CA:  DC=local, DC=Quercus, CN=Quercus-QS-DC-1-CA

    Remote Endpoint:
     Principal Name:  QS-WKS-03.Quercus.local
     Network Address: 2002:408d:3137:8100:790f:b6bb:9604:3a6b
     Keying Module Port: 500

    Remote Certificate:
     SHA Thumbprint: 0a60b31edd8a0c6f416862caadfb895eef182b0d
     Issuing CA:  Quercus-QS-DC-1-CA
     Root CA:  DC=local, DC=Quercus, CN=Quercus-QS-DC-1-CA

    Cryptographic Information:
     Cipher Algorithm: AES-128
     Integrity Algorithm: SHA 256
     Diffie-Hellman Group: None

    Security Association Information:
     Lifetime (minutes): 60
     Quick Mode Limit: 0
     Main Mode SA ID: 156

    Additional Information:
     Keying Module Name: AuthIP
     Authentication Method: SSL
     Role:   Responder
     Impersonation State: Not enabled
     Main Mode Filter ID: 82840
     
    Extended Mode Information:
     Local Principal Name: host/QS-UAG-1.Quercus.local
     Remote Principal Name: QUERCUS\QS-WKS-03$
     Authentication Method: NTLM V2
     Impersonation State: Enabled
     Quick Mode Filter ID: 82864

    Audit Failure: (this one repeats alot in the event log after)

    An IPsec extended mode negotiation failed. The corresponding main mode security association has been deleted.

    Local Endpoint:
     Principal Name:  host/QS-UAG-1.Quercus.local
     Network Address: 2002:408d:3137::408d:3137
     Keying Module Port: 500

    Remote Endpoint:
     Principal Name:  -
     Network Address: 2001:0:408d:3137:8f1:22d7:9fcb:7f56
     Keying Module Port: 500

    Additional Information:
     Keying Module Name: AuthIP
     Authentication Method: Kerberos
     Role:   Responder
     Impersonation State: Enabled
     Quick Mode Filter ID: 82888

    Failure Information:
     Failure Point:  Remote computer
     Failure Reason:  IKE authentication credentials are unacceptable

     State:   Sent second (SSPI) payload

     

    Tuesday, July 13, 2010 6:06 PM
  • It seems as if your client is unable to reach the DC for kerberos authentication.

    I'm puzzled as to why this gets fixed when teredo is restarted.

    Can you try accessing \\Quercus.local\SysVol from the client while connecting from the outside the corp network?

    let us know if this is successful

    Tuesday, July 13, 2010 10:39 PM
  • Hi guys,

    I have exactly the same problem. I have spent days working on this, rebuilding, wondering what I am doing wrong.

    I have been following the technet library article ee861159 exactly.

    Running these two commands got my client connected from behind a NAT when numerous reboots failed.

    Netsh int teredo set state disabled
    Netsh int teredo set state enterprise client

    I too would welcome insight into what mistake I am making.

    Thanks,

    john

    Wednesday, July 14, 2010 10:53 AM
  • A Further Update from John after more testing;

    1. With Teredo, before I issue the commands;

    Netsh int teredo set state disabled
    Netsh int teredo set state enterprise client

    I cant ping dc1, app1, app3, uag1

    2. After successfully testing teredo & then issuing the command 'Netsh int teredo set state disabled'

    testing IP-Https web pages & mapped files fails sometimes. When it does, there is no Kerberos V5 listed in Main Mode


    John

     

     

    Wednesday, July 14, 2010 11:53 AM
  • Hi DownUnderBoy,

    Are you testing from behind NAT1 or when CLIENT1 is on the Internet subnet?

    Thanks!

    Tom


    MS ISDUA/UAG DA Anywhere Access Team
    Wednesday, July 14, 2010 2:30 PM
  • Hi Yaniv,

    I cannot access \\quercus.local\sysvol when outside the corp network.

    After disabling Teredo and enabling, I can access it.

    Thanks,

    B

    Wednesday, July 14, 2010 4:26 PM
  • It sounds from your descriptions that the problem happens only when IP-HTTPS is used. Is this assumption correct?

    Can you check whether IP-HTTPS is active while the problem occurs?

    It doesn't matter if teredo is up or not, as the traffic always goes through the IP-HTTPS interface when it's active.

    Thursday, July 15, 2010 12:59 PM
  • Tom,

    Thank you for taking the time to reply.

    I am testing from behind a NAT. My NAT is connected to the 'real' internet' not the test internet as per the LAB (Inet1).

    Further, my UAG1 is connected to the 'real' internet via a different ADSL link with 2 IP addresses; 219.90.198.225/6.

    Other than that variance, I have followed the LAB with DC1, App1 & 3, UAG1 & Client1.

    John

    Thursday, July 15, 2010 1:03 PM
  • Just to eliminate a known issue.

    Can you please check that IPv6 is enabled on the physical external network adapter.

    Open npca.cpl, right click the external adapter and open Properties. make sure that Internet Protocol Version 6 is checked.

    Thursday, July 15, 2010 1:18 PM
  • Tom,

    Thank you for taking the time to reply.

    I am testing from behind a NAT. My NAT is connected to the 'real' internet' not the test internet as per the LAB (Inet1).

    Further, my UAG1 is connected to the 'real' internet via a different ADSL link with 2 IP addresses; 219.90.198.225/6.

    Other than that variance, I have followed the LAB with DC1, App1 & 3, UAG1 & Client1.

    John


    Hi John,

    So IP-HTTPS when up seems to work sometimes and not other times?

    Is it that you can reach resources through the Infrastructure tunnel but not the intranet tunnel (which is suggested when you say that you don't see any Kerberos authenticated SAs)

    Thanks!

    Tom


    MS ISDUA/UAG DA Anywhere Access Team
    Thursday, July 15, 2010 3:14 PM
  • Hi Yaniv,

    I disabled Teredo to use just the IP-HTTPS tunnel:

    Interface IPHTTPSInterface (Group Policy)  Parameters
    ------------------------------------------------------------
    Role                       : client
    URL                        : https://uag.xxxxx.com:443/IPHTTPS
    Last Error Code            : 0x0
    Interface Status           : IPHTTPS interface active

    I can ping all resources including Quercus.local

    I cannot remote desktop or browse to any resources which resolve to this address format:
    2002:408d:3137:8000:0:5efe:192.168.0.20

    I can remote desktop or browse any resources which resolve to this address format:
    2002:408d:3137:8001::c0a8:16

    Thursday, July 15, 2010 3:24 PM
  • Tom,

    Correct. I can ping DC1, App1 & 3, UAG1 but not get access to the web sites nor map to the files.

    John

    Friday, July 16, 2010 1:59 AM
  • Hi John,

    OK, that's an important finding.

    When you can ping a resource, it means that you have IPv6 transition technology access to the resource - in this case it sounds like IP-HTTPS.

    However, the reason why you can ping and not use other protocols is that ICMP is exempted from IPsec protection.

    So I think the attention at this point should be focused on IPsec issues.

    Check out my article on this subject over at:

    http://blogs.technet.com/b/tomshinder/archive/2010/07/14/considerations-when-using-ping-to-troubleshoot-directaccess-connectivity-issues.aspx

    HTH,

    Tom


    MS ISDUA/UAG DA Anywhere Access Team
    Friday, July 16, 2010 12:46 PM
  • QS-Bavin, did you try restarting the UAG server?
    Sunday, July 18, 2010 7:52 AM
  • Hi Yaniv,

    I have rebooted it many times now... no luck..

     

    Tuesday, July 20, 2010 3:12 PM
  • and did you check that IPv6 is enabled?

    Open npca.cpl, right click the external adapter and open Properties. make sure that Internet Protocol Version 6 is checked.

    also, do you have a firewall between your UAG server and the internal network?

    Wednesday, July 21, 2010 8:37 AM
  • Hi Yaniv,

    I have rebooted it many times now... no luck..

     


    Did you check the wf.msc console to see if there are Main Mode security associations?

    Thanks!

    Tom


    MS ISDUA/UAG DA Anywhere Access Team
    Wednesday, July 21, 2010 6:12 PM
  • Hi Tom,

    I went through the document you sent me, and there are Main Mode security associations. However on the UAG server there is audit failures in the security log which I mentioned above. Even though it says on the UAG server that the association is deleted, it still shows on the client. I'm not sure how to troubleshoot the IPsec negotiation.

    Bhavin

    Wednesday, July 21, 2010 6:46 PM
  • Have you enabled IPsec Main Mode and Extended Mode logging?

    Thanks!

    Tom


    MS ISDUA/UAG DA Anywhere Access Team
    Friday, July 23, 2010 11:49 AM
  • Yes, they are enabled. They results are above on my July 13 reply.
    Friday, July 23, 2010 2:49 PM
  • OK, it looks like the intranet tunnel is failing authentication - if that's true, you can access resources through the infrastructure tunnel, is that right?

    If the UAG DA server a member of the same domain as the computer accounts and the user accounts?

    Thanks!

    Tom


    MS ISDUA/UAG DA Anywhere Access Team
    • Marked as answer by Erez Benari Monday, July 26, 2010 11:04 PM
    Monday, July 26, 2010 12:47 PM
  • Are you using an Appliance such as Celestix or a Windows Server 2008 R2 PC?
    Tuesday, July 27, 2010 8:09 AM
  • It is a Windows Server 2008 R2...

    Tom: I can't access any resources at all...  only after disabling and enabling Teredo...

    THe UAG DA server is a member of the same domain as the user and computer accounts. I've gpupdate /force the group policies, and checked with RSOP that they were applied.

    I think I'm at the point where I may try to reinstall everything.

    Tuesday, July 27, 2010 3:20 PM
  • The need to disable and then enable Teredo is puzzling.

    Yes - rebuild and let's see if things work better. I've found that rebuilding gives me a lot of insight into all the moving parts, and makes me more aware of all the things that need to go right and careful of those that might go wrong.

    Let us know how it works out!

    Thanks!

    Tom


    MS ISDUA/UAG DA Anywhere Access Team
    Thursday, July 29, 2010 12:46 AM