locked
no connectivity after implementing direct access error code 0x8009030e RRS feed

  • Question

  • i have implemented Direct access step by step  from microsoft recommendation , while i have used a public certificate on the IPHTTPS just to ease of troubleshoting and not thinking about the crl but still my clients cannot have the DA connectivity and when i show the logs im getting error

    0x8009030e interface status : failed to connect to HTTPS Server . waiting to reconnect


    Best Regards

    Wednesday, February 29, 2012 1:51 PM

All replies

  • That error implies a network connectivity issue - is there a firewall in front of UAG?

    From a computer that is connected to the internet, try browing to https://directaccess.company.com:443/IPHTTPS - (replace with your actual web address of course) - you should get a 403 page with NO certificate warning messages.

    Cheers

    JJ


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

    Friday, March 9, 2012 12:01 AM
  • by default the firewaøl will be disabled on the UAG

    when im browsing the IPHTTPS website i get 403 which is normal error

    please note that i published the DA using wild card third party certificate and im not sure if its certificate issue .

    im not a certificate guy :(


    Best Regards

    Monday, March 12, 2012 12:34 PM
  • Never disable the firewall service on the UAG box

    !


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

    Monday, March 12, 2012 7:28 PM
  • BenoitS is right

    UAG DA infact needs its, its one of the main components to get things moving please enable the firewall.


    Thanks and Regards Suraj Singh My blog: http://blogs.technet.com/b/sooraj-sec/

    Monday, March 12, 2012 9:54 PM
  • Disabling the firewall service also disable IPSEC. Event TMG rely on it.

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

    Monday, March 12, 2012 9:56 PM
  • i agree with you , but on the UAG the firewall asa service its started but when i check the windows firewall it shows its connected while it has the RED status

    do you mean that it should be connected on all networks and green ?


    Best Regards

    Wednesday, March 14, 2012 11:53 AM
  • Hi

    I mean that the Windows Firewall Service must be started. Internet faced interface must be associated with a pubilc profile. Internal facing interface must be associated with the domain profile.


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

    Wednesday, March 14, 2012 11:59 AM
  • this is the same as what i have now ...

    but still on connectivity happening and no IPSec quick or main mods

    is it possible that the wild card certificate if not functioninng on the IPSec authintication ?

    i have got this wild card from verysign

    *.mydomain.com


    Best Regards

    Wednesday, March 14, 2012 12:08 PM
  • The wildcard certificate is only involved in IPHTTPS protocol. From the client side, do you have client able to reach your UAG box with the teredo protocol?

    If IPSEC association fail, let's start to enable IPSEC logging on the UAGBOX : Computer configuration\Windows Settings\Security\Advanced Audit Policy Configuration\System Audit Policies\Logon

    Activate Audit IPSEC Main Mode and Quick Mode for both failure and success.


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

    Wednesday, March 14, 2012 12:15 PM
  • thanks

    ive done it already and i got client failed in authintication  ike unknow


    Best Regards

    Wednesday, March 14, 2012 12:38 PM
  • Are you sure that your client computer have an IPSEC certificate.

    In addition, could you provide a DirectAccess COnnectivity Assistant log that we could help you?


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

    Wednesday, March 14, 2012 1:33 PM
  • you mean a wild card certificate ? yes i have installed it on it and thats why im asking is it possible thats the wild card certificate doesnt applies to IPSec authintication ? does it have to be fomr specifit certificate templates ?


    Best Regards

    Wednesday, March 14, 2012 5:14 PM
  • No

    On your UAG box you show have your wildcard certificate and a computer certificate for IPSEC tunnels (Computer template). On the client side you should have a computer certificated delivered by the same CA


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

    Wednesday, March 14, 2012 6:18 PM
  • If you are successfully getting a 403 with no certificate warning messages when browsing to the IP-HTTPS site, then it appears your wildcard is doing its job for IP-HTTPS. Then once you have an IP-HTTPS tunnel, your computer and the server will negotiate IPsec tunnels inside the IP-HTTPS tunnel (or Teredo or 6to4 tunnel) by using a Machine certificate that was issued to both your client computer and the DA server by your internal CA server. If you have not issued these machine certificates (I recommend using the built-in Computer Template with Windows CA server) then this is the reason your IPsec tunnels are not establishing.
    Thursday, March 15, 2012 8:55 PM
  • ok thanks alot for the answer , however i have implemented a wild card third party certificate on the IPHTTPS just to make the troubleshooting of the senario more simple , and computer certificate is issues from CA to both the DA server and the client , when im checking the type of certificates implemented on the clients its IP security IKE intermediate , and one from server authentication , client authintication , and client authintication server authintication

    and on the trusted root certificate they have the wild card certificate

    when im checking the security audits on the DA server now im getting error FailureReason IKE authentication credentials are unacceptable so no main mode is happening


    Best Regards

    Wednesday, March 21, 2012 8:00 AM


  • DirectAccess Connectivity Assistant Logs





    RED: Corporate connectivity is not working.

    Your computer cannot connect to the DirectAccess server. If the problem
    persists, contact your administrator.






    Probes List

    FAIL - The server name resolved successfully, but failed to access PING:
    2002:d47d:e6c3::d47d:e6c3

    FAIL - HTTP: http://172.16.10.212/



    DTE List

    FAIL - PING: 2002:d47d:e6c3::d47d:e6c3

    PASS - PING: 2002:d47d:e6c2::d47d:e6c2



    ***************************************************************************

    ipconfig /all

    ***************************************************************************

    Microsoft Windows [Version 6.1.7601]

    Copyright (c) 2009 Microsoft Corporation.  All rights reserved.



    C:\Windows\system32\LogSpace\{744A0F03-3809-4F3F-83E4-7D853AFF0D69}>ipconfig
    /all



    Windows IP Configuration



       Host Name . . . . . . . . . . . . : AMI7

       Primary Dns Suffix  . . . . . . . : domain.com
       Node Type . . . . . . . . . . . . : Hybrid

       IP Routing Enabled. . . . . . . . : No

       WINS Proxy Enabled. . . . . . . . : No

       DNS Suffix Search List. . . . . . : domain.com
                                          
    lan

       System Quarantine State . . . . . : Not Restricted





    Wireless LAN adapter Wireless Network Connection:



       Media State . . . . . . . . . . . : Media
    disconnected

       Connection-specific DNS Suffix  . : lan

       Description . . . . . . . . . . . : Intel(R) Centrino(R)
    Ultimate-N 6300 AGN

       Physical Address. . . . . . . . . : 00-24-D7-B2-15-44

       DHCP Enabled. . . . . . . . . . . : Yes

       Autoconfiguration Enabled . . . . : Yes



    Ethernet adapter Local Area Connection:



       Connection-specific DNS Suffix  . : lan

       Description . . . . . . . . . . . : Intel(R) 82579LM Gigabit
    Network Connection

       Physical Address. . . . . . . . . : 5C-26-0A-51-EE-C5

       DHCP Enabled. . . . . . . . . . . : Yes

       Autoconfiguration Enabled . . . . : Yes

       Link-local IPv6 Address . . . . . :
    fe80::bdf5:55b:ca4b:b1bf%14(Preferred)

       IPv4 Address. . . . . . . . . . . : 192.168.1.62(Preferred)

       Subnet Mask . . . . . . . . . . . : 255.255.255.0

       Lease Obtained. . . . . . . . . . : Tuesday, March 20, 2012
    5:46:46 PM

       Lease Expires . . . . . . . . . . : Thursday, March 22, 2012
    8:44:49 AM

       Default Gateway . . . . . . . . . : 192.168.1.1

       DHCP Server . . . . . . . . . . . : 192.168.1.1

       DHCPv6 IAID . . . . . . . . . . . : 291251722

       DHCPv6 Client DUID. . . . . . . . :
    00-01-00-01-16-FA-18-55-5C-26-0A-51-EE-C5

       DNS Servers . . . . . . . . . . . : 192.168.1.1

       NetBIOS over Tcpip. . . . . . . . : Enabled



    Tunnel adapter isatap.lan:



       Media State . . . . . . . . . . . : Media
    disconnected

       Connection-specific DNS Suffix  . :

       Description . . . . . . . . . . . : Microsoft ISATAP Adapter #2

       Physical Address. . . . . . . . . : 00-00-00-00-00-00-00-E0

       DHCP Enabled. . . . . . . . . . . : No

       Autoconfiguration Enabled . . . . : Yes



    Tunnel adapter Teredo Tunneling Pseudo-Interface:



       Connection-specific DNS Suffix  . :

       Description . . . . . . . . . . . : Teredo Tunneling
    Pseudo-Interface

       Physical Address. . . . . . . . . : 00-00-00-00-00-00-00-E0

       DHCP Enabled. . . . . . . . . . . : No

       Autoconfiguration Enabled . . . . : Yes

       IPv6 Address. . . . . . . . . . . :
    2001:0:d47d:e6c2:bf:1dde:3e2b:999f(Preferred)

       Link-local IPv6 Address . . . . . :
    fe80::bf:1dde:3e2b:999f%18(Preferred)

       Default Gateway . . . . . . . . . :

       NetBIOS over Tcpip. . . . . . . . : Disabled



    Tunnel adapter iphttpsinterface:



       Connection-specific DNS Suffix  . :

       Description . . . . . . . . . . . : Microsoft IP-HTTPS Platform
    Adapter

       Physical Address. . . . . . . . . : 00-00-00-00-00-00-00-E0

       DHCP Enabled. . . . . . . . . . . : No

       Autoconfiguration Enabled . . . . : Yes

       IPv6 Address. . . . . . . . . . . :
    2002:d47d:e6c2:8100:7c1d:153c:3073:c3c7(Preferred)

       Temporary IPv6 Address. . . . . . :
    2002:d47d:e6c2:8100:e4bf:697:42eb:7276(Preferred)

       Link-local IPv6 Address . . . . . :
    fe80::7c1d:153c:3073:c3c7%28(Preferred)

       Default Gateway . . . . . . . . . : fe80::5132:de34:1e26:4404%28

       NetBIOS over Tcpip. . . . . . . . : Disabled



    C:\Windows\system32\LogSpace\{744A0F03-3809-4F3F-83E4-7D853AFF0D69}>



     



    C:\Windows\system32\LogSpace\{744A0F03-3809-4F3F-83E4-7D853AFF0D69}>netsh
    int teredo show state

    Teredo Parameters

    ---------------------------------------------

    Type                   
    : client

    Server
    Name             :
    212.125.155.199 (Group Policy)

    Client Refresh Interval : 30 seconds

    Client
    Port             :
    unspecified

    State                  
    : qualified

    Client
    Type             :
    teredo host-specific relay

    Network                
    : unmanaged

    NAT                    
    : symmetric (port)

    NAT Special Behaviour   : UPNP: No, PortPreserving: No

    Local Mapping           : 192.168.1.62:65057

    External NAT Mapping    : 193.212.102.96:57889





     



    netsh int httpstunnel show interfaces



    Interface IPHTTPSInterface (Group Policy)  Parameters

    ------------------------------------------------------------

    Role                      
    : client

    URL                       
    : https://DA.domain.com:443/IPHTTPS

    Last Error
    Code            : 0x0

    Interface Status           :
    IPHTTPS interface active



     


    <o:p></o:p>



    Best Regards

    Wednesday, March 21, 2012 9:03 AM
  • OK,

    Now we are sure it's an IPSEC negociation problem. Did you enabled Advanced Audit Policy configuration Parameters for IPSEC :

    Audit IPSec Main Mode

    Audit IPSec Quick mode

    What type of error messages do you have in the security log.


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

    Wednesday, March 21, 2012 9:38 AM
  • on the DA server as you recommended i have turned on the audit IPSec extended mode

    audit IPsex main mode

    and audit IPsec quick mode  all of them for success and failiur

    i have audit failiur error messeges in the DA server logs and task category is IPSec main mode

    event ID 4653


    Best Regards

    Wednesday, March 21, 2012 10:51 AM
  • Hi,

    In many cases i encontered IPSEC Main mode problems were related with certificates. Could you provide the certutil -store my section of the DAC report?


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

    Wednesday, March 21, 2012 10:55 AM


  • C:\Users\ksa>certutil /store

    CA

    ================ Certificate 0 ================

    Serial Number: 06376c00aa00648a11cfb8d4aa5c35f4

    Issuer: CN=Root Agency

     NotBefore: 5/28/1996 11:02 PM

     NotAfter: 1/1/2040 12:59 AM

    Subject: CN=Root Agency

    Signature matches Public Key

    Root Certificate: Subject matches Issuer

    Template:

    Cert Hash(sha1): fe e4 49 ee 0e 39 65 a5 24 6f 00 0e 87 fd e2 a0 65 fd 89 d4

    No key provider information

    Cannot find the certificate and private key for decryption.<o:p></o:p>



    ================ Certificate 1 ================

    Serial Number: 46fcebbab4d02f0f926098233f93078f

    Issuer: OU=Class 3 Public Primary Certification Authority, O=VeriSign, Inc., C=

    S

     NotBefore: 4/17/1997 1:00 AM

     NotAfter: 10/25/2016 12:59 AM

    Subject: OU=www.verisign.com/CPS
    Incorp.by Ref. LIABILITY LTD.(c)97 VeriSign, O

    =VeriSign International Server CA - Class 3, OU=VeriSign, Inc., O=VeriSign Trus

     Network

    Non-root Certificate

    Template:

    Cert Hash(sha1): d5 59 a5 86 66 9b 08 f4 6a 30 a1 33 f8 a9 ed 3d 03 8e 2e a8

    No key provider information

    Cannot find the certificate and private key for decryption.<o:p></o:p>



    ================ Certificate 2 ================

    Serial Number: 3bdb40b08b5b479d42d98d2eade2e3f6

    Issuer: CN=UECC Root

     NotBefore: 9/10/2010 2:02 PM

     NotAfter: 9/10/2020 2:11 PM

    Subject: CN=UECC Root

    CA Version: V0.0

    Signature matches Public Key

    Root Certificate: Subject matches Issuer

    Template:

    Cert Hash(sha1): 93 5c e7 9e ca b8 57 1a 34 38 2a 4b e2 c6 56 80 43 e2 33 f5

    No key provider information

    Cannot find the certificate and private key for decryption.<o:p></o:p>



    ================ Certificate 3 ================

    Serial Number: 25d0222b000100001278

    Issuer: CN=UECC DC45, DC=uecc, DC=com

     NotBefore: 2/27/2012 6:31 PM

     NotAfter: 2/26/2013 6:31 PM

    Subject: CN=OSLODC25.uecc.com

    Certificate Template Name (Certificate Type): Machine

    Non-root Certificate

    Template: Machine

    Cert Hash(sha1): 40 87 56 7e 26 87 cf 2c 9d 27 54 8a 43 9d 38 89 81 f0 8d ea

    No key provider information

    Cannot find the certificate and private key for decryption.<o:p></o:p>



    ================ Certificate 4 ================

    Serial Number: 198b11d13f9a8ffe69a0

    Issuer: CN=Microsoft Root Authority, OU=Microsoft Corporation, OU=Copyright (c)

    1997 Microsoft Corp.

     NotBefore: 10/1/1997 8:00 AM

     NotAfter: 12/31/2002 8:00 AM

    Subject: CN=Microsoft Windows Hardware Compatibility, OU=Microsoft Corporation,

    OU=Microsoft Windows Hardware Compatibility Intermediate CA, OU=Copyright (c) 1

    97 Microsoft Corp.

    Non-root Certificate

    Template:

    Cert Hash(sha1): 10 9f 1c ae d6 45 bb 78 b3 ea 2b 94 c0 69 7c 74 07 33 03 1c

    No key provider information

    Cannot find the certificate and private key for decryption.

    ================ CRL 0 ================

    Issuer:

        OU=VeriSign Commercial Software Publishers CA

        O=VeriSign, Inc.

        L=Internet

    CRL Hash(sha1): a3 77 d1 b1 c0 53 88 33 03 52 11 f4 08 3d 00 fe cc 41 4d ab

    CertUtil: -store command completed successfully.<o:p></o:p>



    Best Regards

    Wednesday, March 21, 2012 11:26 AM
  • According to your command your client certificate is OSLODC25.uecc.com. Are you sure that the FQDN registred in this certificate corresponding to the FQFN of the computer in your internal DNS?



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

    Wednesday, March 21, 2012 11:32 AM
  • the CA server is dc45

    this is the dc where the clients take the groupe policy from


    Best Regards

    Wednesday, March 21, 2012 11:41 AM
  • Hi

    My question was about the subject name registred in your client certificate : OSLODC25.uecc.com. Is this the FQDN of your computer in your environment?


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

    Wednesday, March 21, 2012 1:42 PM
  • yes this is the FQDN of the dc


    Best Regards

    Wednesday, March 21, 2012 2:22 PM
  • I dont understand.

    OSLODC25.uecc.com is the FQDN of your Domain controller or your DirectAccess client?


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

    Wednesday, March 21, 2012 2:39 PM
  • my domain controller


    Best Regards

    Wednesday, March 21, 2012 2:47 PM
  • So

    What is the FQDN of your DirectAccess Client ans what is the subject name registred in the DirectAccess client certificate?


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

    Wednesday, March 21, 2012 2:55 PM
  • What Benoit is saying is that your Machine certificates that are issued from your CA server must have the subject name matching the FQDN of the machine that they were issued to. So the machine certificate that was issued to your client must have a subject name that matches the FQDN of your client computer, and the machine certificate that was issued to your UAG server must have a subject name that matches the FQDN of the UAG server. None of this has anything to do with the wildcard certificate by the way (I think you realize that already, just clarifying).

    A couple of other notes: In your log file I see that the secondary IP address in the DTE list up on top is failing to ping. Is your UAG server sitting behind a firewall? Is that firewall allowing the necessary protocols to both of the IP addresses that are on the UAG server? Also I see that you have configured your DirectAccess Connectivity Assistant with a "conectivity verifier" of an IP address. That is not going to work, IPv4 addresses are not directly contactable over a DirectAccess tunnel. At some point you will want to reconfigure the optional portion of Step 1 in your wizards so that the connectivity verifier looks for a name, not an IP address.

    Wednesday, March 21, 2012 3:08 PM
  • hi again

    thanks alot for the clarification

    the way that im implementing the certificate to the user just for testing phase is that i request the certificate from the client or server side and by default it issues the certificate by the requester name so im sure that the certificate that im having on the client machine has the fqdn of the client machine

    as well the direct access server 's name is publisher

    and i have issued certificate from CA on the publisher as publisher.uecc.com

    is that wrong ?

    i dont know why the secondary DTE i failing to ping but the UAG server is not behind a firewall

    regarding the network verifier thanks for the note, i will change it however  in the configuration wizard and the microsoft technet they didnt mention this :)

     


    Best Regards

    Wednesday, March 21, 2012 3:42 PM
  • another question guyz just to simplify the senario if its just a certificate problem thruogh my internal CA i can buy a third party certificate just as work around but then i dont need to have certificate authourity server in my internal ?

    if that is possible and will sove the problem so i can get a trusted certificate ,and is the certificate needs to be form specific teomplate ?


    Best Regards

    Wednesday, March 21, 2012 3:45 PM
  • That does sound correct. If the FQDN of the UAG server is "publisher.uecc.com" then the machine certificate issued should have a subject name of "publisher.uecc.com" as well. Did you use the default (built-in) "Computer" template for these machine certificates? That is the one that I typically use. If you used a custom template, or I guess it doesn't hurt to check either way, you also want to make sure that these machine certificates serve the Intended Purpose of both Client Authentication and Server Authentication.
    Wednesday, March 21, 2012 3:48 PM
  • IPSEC certificates must be provided by your internal CA. Only Windows 8 client and Windows 8 server DirectAccess scenario allow you to deploy without certificates but in my opinion it is a bad idea as you will need certificates for smartcard or NAP.


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

    Wednesday, March 21, 2012 3:49 PM
  • For your other question, no the "machine" certificates that authenticate your IPsec tunnels need to be from your internal CA server. Only the SSL certificate for the IP-HTTPS listener should be from a public CA.
    Wednesday, March 21, 2012 3:49 PM
  • well im still getting

    An IPsec main mode negotiation failed.



    Local Endpoint:


    Local Principal Name: -


    Network Address: 2002:d47d:e6c3::d47d:e6c3


    Keying Module Port: 500



    Remote Endpoint:


    Principal Name: -


    Network Address: 2002:d47d:e6c2:8100:7de6:94f3:f6a4:5688


    Keying Module Port: 500



    Additional Information:


    Keying Module Name: AuthIP


    Authentication Method: Unknown authentication


    Role: Responder


    Impersonation State: Not enabled


    Main Mode Filter ID: 151324



    Failure Information:


    Failure Point: Remote computer


    Failure Reason: IKE authentication credentials are unacceptable



    State: Sent second (KE) payload


    Initiator Cookie: 2d5d1fd63161e546


    Responder Cookie: b3f727c4e34b90e1


    Best Regards

    Wednesday, March 21, 2012 3:56 PM
  • and im using the standard computer templates when its regarding the certificate


    Best Regards

    Wednesday, March 21, 2012 3:57 PM
  • Hi,

    are you sure that you do not have a time synchronization problem between your client and UAG server?


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

    Wednesday, March 21, 2012 4:56 PM
  • will that affect the communication ?

    well i didnt know but anyways i have checked it and there is no problem same time


    Best Regards

    Thursday, March 22, 2012 7:26 AM
  • one more thing , how can i know if my IPSec certificate is the problem ?

    now the senario that im using trusted root CA third party *.uecc.com for the IPHTTPS accessing and it is active with no problems

    while im using for the IPSec certificate authintications which i have problem with an IPSec certificate form the internal root ca from the templates IPSec is that wrong ?


    Best Regards

    Thursday, March 22, 2012 8:11 AM