locked
UAG SP1 DirectAccess Teredo Problem RRS feed

  • Question

  • I'm just in the middle of deploying UAG DirectAccess having proven the setup in a very simple lab.

    Connectivity to corporate resources from the Internet works OK, but only over IPHTTPS. The Teredo interface just doesn't seem to come up on the DA clients.

    I've had the network team logging access to the corporate firewall and have seen a single packet sent from a DA client to UDP 3544 and a single packet returned. I've been through the 'Cannot Reach the DirectAccess Server with Teredo' article at http://technet.microsoft.com/en-us/library/ee844188(WS.10).aspx and everything seems to check out.

    I'm running out of ideas. Can anyone suggest anything else to check?

    Steve G

    Thursday, May 26, 2011 8:22 PM

Answers

  • I can now put this one to bed as I have solved both my problems, though as you will see, I should be given the 'Muppet of the Year Award' for not spotting the main culprit sooner!

    Originally I had a problem with getting the Teredo connection established. The answer to this one, alluded to earlier in the thread, was a firewall running an old firmware version. This was updated today and the Teredo tunnel came up without a problem.

    While Teredo wasn't working, I was having problems with IPHTTPS. The answer to this was proxy settings on the DA client, getting in the way of accessing the CDP.

    When I sorted out the proxy issue, the IPHTTPS tunnel came up, but I was still unable to access any intranet resources. All the debugging described on TechNet suggested a problem establishing the infrastructure tunnel. Even though I could see main mode SAs and quick mode SAs being established, I couldn't see any User (Kerberos v5) SAs indicating I had intranet access. The Security log highlighted the fact that SAs were being established, but were being disconnected and the message 'IKE authentication credentials are unacceptable' was recorded.

    The really annoying thing about the whole experience was that I have a working environment on my laptop and couldn't spot what was different to the production environment, until I started to compare the policies applied to my test client and the client in production. While the test client had three connection security rules showing in wf.msc under the Connection Security Rules node, the production client only had two. The missing rule was 'UAG DirectAccess Client - Clients Corp Tunnel'. Then the penny dropped. Late one evening I had, in an act of desparation, re-installed UAG and reconfigured DirectAccess. In my haste when going through the DirectAccess wizard, I had selected 'Enable remote management of DirectAccess clients only' rather than 'Allow DirectAccess clients to connect to internal networks...' and it is for this that I submit my nomination for 'Muppet of the Year'!

    Once I had rectified this setting and pushed the policies out to the clients, surprisingly everything worked.

    All I have to do now is configure 2FA using SecurID and my work will be done.

    Many thanks to all who submitted ideas, but in the end I was just a victim of my own stupidity!

    Steve G

    Tuesday, June 7, 2011 7:54 PM

All replies

  • What IP addresses are your DA client using in the test lab?


    Jason Jones | Forefront MVP | Silversands Ltd | My Blogs: http://blog.msedge.org.uk and http://blog.msfirewall.org.uk
    Friday, May 27, 2011 12:28 AM
  • Jason,

     

    The lab works OK. It is the production environment where there are issues. The two are completely separate.

    The clients are just connected to a BT wireless broadband service, but I've also tried with a 3 Network MiFi router with the same results.

    Steve G


    Friday, May 27, 2011 7:24 AM
  • Hi Steve,

    What do you get from the following:

    netsh int teredo show state

    Are you aware that teredo needs ICMPv6 access to intranet resources? Could something be blocking this? http://technet.microsoft.com/en-us/library/ee382272(WS.10).aspx

    Cheers

    JJ


    Jason Jones | Forefront MVP | Silversands Ltd | My Blogs: http://blog.msedge.org.uk and http://blog.msfirewall.org.uk
    Friday, May 27, 2011 8:43 AM
  • Hello,

    Did you check the following articles:

    • Solving the Mystery of the Dead Teredo Interface: http://blogs.technet.com/b/tomshinder/archive/2010/12/21/solving-the-mystery-of-the-dead-teredo-interface.aspx
    • DirectAccess and Teredo Adapter Behavior: http://blogs.technet.com/b/tomshinder/archive/2010/05/27/directaccess-and-teredo-adapter-behavior.aspx

    Follow me on Twitter http://www.twitter.com/liontux | My Blog (French/English) : http://security.sakuranohana.fr/
    Friday, May 27, 2011 9:13 AM
  • Jason,

    Running the command you indicated shows the teredo interface as offline. The accompanying error message is 'secondary teredo server unreachable over UDP'.

    This message is puzzling as the network team has identified traffic being sent between the DA client and the UAG server on UDP 5344.

    Pinging of intranet resources from the UAG server is successful.

    I now have another issue!

    IPHTTPS was previously kicking in when Teredo failed. I'm now not even getting IPHTTPS up and running on the DA client. I believe the problem is expired delta CRLs on the client (as evidenced from running certutil -v -urlcache CRL, which shows the cached CRL has expired). I've cleared the memory and disk CRL cache, but the DA client seems unwilling to go and retrieve the latest CRLs from the external CDP. The external CDP has been verified as being accessible by accessing the external URL (pki.companyname.com) through IE. I've also done URL retrieval on the DA client's computer certificate using certutil -url certfile.cer and both the AIA and CDP URLs can be verified.

    Manually installing the latest delta CRLs makes the problem go away and the DA client connects over IPHTTPS. Running WireShark on the client as the wireless connection is enabled shows no evidence of the client talking to the external CDP.

    Without the delta CRLs installed, running netsh interface httpstunnel show state, indicates an error 0x80092013, which is a revocation check problem (which ties in with what I'm experiencing, unfortunately!). So I'm convinced it is a CRL related problem.

    Any further guidance would be appreciated.

    Lionel: I checked the two URLs you sent, but nothing seemed to indicate the source of my current problems.

     

    Steve G

    Friday, May 27, 2011 12:31 PM
  • Have your network guys opened the necessary protocols for both DA public IP addresses? http://technet.microsoft.com/en-us/library/ee809062.aspx You are testing ping with IPv6, yes?

    I would recommend you use a public CA certificate for the IP-HTTPS listener, rather than a private CA. If you still want to use your private CA, you will need to publish your CRLs using UAG as discussed here: http://blogs.technet.com/b/tomshinder/archive/2010/08/03/how-to-configure-uag-to-publish-your-private-certificate-revocation-list.aspx

    Cheers

    JJ


    Jason Jones | Forefront MVP | Silversands Ltd | My Blogs: http://blog.msedge.org.uk and http://blog.msfirewall.org.uk
    Friday, May 27, 2011 12:43 PM
  • Jason,

    I've confirmed that the necessary protocols are open for both DA addresses (in fact it is open for the entire subnet).

    With regards to ping, I think I may have made progress. The main firewall does not support IPv6! It is a Cisco Pix running version 5.x of the software. I've been advised that an upgrade to v7.0 will allow IPv6 support. There is now a move to perform the upgrade, but I think it will be a day or two before it happens.

    So I'm left degugging the IPHTTPS problem. Can you advise why the CRLs need to be published by UAG in this way? The lab configuration didn't seem to need this step. With certutil, the DA client can verify the AIA and CDP URLs without problem. I'd just like to know why it needs to be done via UAG rather than with a regular, externally available web site.

    Many thanks for your help so far.

    Steve G

    Friday, May 27, 2011 12:59 PM
  • It doesn't have to be done with UAG, that was just a suggestion if you had no alternative ;)

    I stand by my recommendation to use a public SSL certificate...it sounds like your CRLs are good, but you probably need to troubleshoot that more...try looks at problems with SSTP and CRLs as IP-HTTPS is very similar to SSTP and there is more information available on that...

    Cheers

    JJ


    Jason Jones | Forefront MVP | Silversands Ltd | My Blogs: http://blog.msedge.org.uk and http://blog.msfirewall.org.uk
    Friday, May 27, 2011 1:18 PM
  • Hey Steven, with regards to Teredo you mentioned UDP port 5344 above, I just wanted to make sure that was a typo and you meant 3544, because that is the actual port Teredo will be using. I would also make sure you aren't running an antivirus or firewall program on the client machines that could be blocking this traffic. I have seen Symantec Endpoint Protection with Network Threat Protection enabled block UDP traffic by default before, and simply allowing Teredo (UDP 3544) within Symantec cleared up the issue. Typically though, that would indicate that the "primary tunnel is unavailable over UDP"...when it lists the secondary as being unavailable it indicates that the primary is actually contactable, but the secondary is not for some reason. So I would have to recommend again also triple-checking the firewall settings for the second external IP address and make sure it's open.

    For the CRL, you do not NEED to publish it through UAG, but you can. If you already have externally facing highly available CRL for your PKI published, it should work just fine. "Should" being the operative word in that sentence. I have had at least two occasions where a customer used their own certificate from their own CA server, and we checked everything with the PKI environment, everything looked to be setup completley correctly, external CRLs available just like they should be, and yet it would not work. In both cases, as soon as the certificate for IP-HTTPS was replaced with a public purchased certificate (from Godaddy, Verisign, whomever), it started working. I honestly can't say why it wouldn't work with their own cert, but it just wouldn't. And since certificates are cheap and it was working, we did not re-visit the "why" after the issue was resolved.

    Friday, May 27, 2011 1:24 PM
  • Whoops, sorry Jason - I should have refreshed my page before I clicked "Submit" :)
    Friday, May 27, 2011 1:26 PM
  • Whoops, sorry Jason - I should have refreshed my page before I clicked "Submit" :)

    No problem, nice to see we agree ;)
    Jason Jones | Forefront MVP | Silversands Ltd | My Blogs: http://blog.msedge.org.uk and http://blog.msfirewall.org.uk
    Friday, May 27, 2011 1:27 PM
  • Jordan,

    Yes, it was a typo on my behalf! I did mean 3544 and not 5344!

    Interesting about the external CDP. It is odd that I've had IPHTTPS working up until when the delta CRL expired. If I don't get any further, I may head down the public certificate route. Thanks for the benefit of your experience.

    Steve G

    Friday, May 27, 2011 1:27 PM
  • I've just tried the publication of the internal CDP via UAG as previously suggested, but without success. There is definitely something amiss with the DA client picking up CRLs from the external CDP. Installing the CRLs of the issuing CA manually on the client works, but is obviously impractical. If I can't find a solution, I may try the external certificate route suggested by  Jordan.

    Steve G

    Friday, May 27, 2011 2:50 PM
  • I now have the CDP working correctly. It was a problem with the proxy settings on the client.

    I now have a new problem.

    The IPHTTPS connection comes up, but I'm unable to access any internal resources. I've been through the TLG for Troubleshooting and the articles on TechNet for specific failure scenarios.

    Looking in wf.msc, I can see a main mode connection created with Computer Certificate as the 1st AuthN method and User (NTLMv2) as 2nd AuthN method. What I can't see is one for User (Kerberos v5) as the 2nd AuthN method, resulting from an attempt to net view an internal resource.

    Can anyone suggest any further troubleshooting I can undertake?

    Many thanks,

    Steve G


    Monday, June 6, 2011 3:38 PM
  • Hi Steve,

    i was just reading your post because i also have that "primary teredo server unreachable over UDP" error.

     

    Regarding your problem (infratstructure tunnel coming up, intranet tunnel not):

    I had exactly the same issue - our problem was that our root domain was a single label domain:

    We have *.company as root domain, not *.company.com (for example)

    -> switching 2nd tunnel authentication to NTLM solved the problem,

    OR

    -> creating direct trusts between the UAGs domain and the clients domain.

     

    Hope i could help you out - i was struggeling with that problem for several weeks....

     

    Do you have any new hints about the "primary teredo server unreachable over UDP" problem ?

     

    Have a good time.

    Matthias

    Tuesday, June 7, 2011 12:19 PM
  • I can now put this one to bed as I have solved both my problems, though as you will see, I should be given the 'Muppet of the Year Award' for not spotting the main culprit sooner!

    Originally I had a problem with getting the Teredo connection established. The answer to this one, alluded to earlier in the thread, was a firewall running an old firmware version. This was updated today and the Teredo tunnel came up without a problem.

    While Teredo wasn't working, I was having problems with IPHTTPS. The answer to this was proxy settings on the DA client, getting in the way of accessing the CDP.

    When I sorted out the proxy issue, the IPHTTPS tunnel came up, but I was still unable to access any intranet resources. All the debugging described on TechNet suggested a problem establishing the infrastructure tunnel. Even though I could see main mode SAs and quick mode SAs being established, I couldn't see any User (Kerberos v5) SAs indicating I had intranet access. The Security log highlighted the fact that SAs were being established, but were being disconnected and the message 'IKE authentication credentials are unacceptable' was recorded.

    The really annoying thing about the whole experience was that I have a working environment on my laptop and couldn't spot what was different to the production environment, until I started to compare the policies applied to my test client and the client in production. While the test client had three connection security rules showing in wf.msc under the Connection Security Rules node, the production client only had two. The missing rule was 'UAG DirectAccess Client - Clients Corp Tunnel'. Then the penny dropped. Late one evening I had, in an act of desparation, re-installed UAG and reconfigured DirectAccess. In my haste when going through the DirectAccess wizard, I had selected 'Enable remote management of DirectAccess clients only' rather than 'Allow DirectAccess clients to connect to internal networks...' and it is for this that I submit my nomination for 'Muppet of the Year'!

    Once I had rectified this setting and pushed the policies out to the clients, surprisingly everything worked.

    All I have to do now is configure 2FA using SecurID and my work will be done.

    Many thanks to all who submitted ideas, but in the end I was just a victim of my own stupidity!

    Steve G

    Tuesday, June 7, 2011 7:54 PM