none
IPSec Audit Failures when using Forefront UAG DirectAccess RRS feed

  • Question

  • I've installed Forefront UAG DirectAcess and I'm not getting it to work properly. I read the planning and deployment guides and believe I have configured everything according to those. I'm not using IPv6 on our intranet. I'm able to ping all servers but that's it. I have no other access to them.

    On the clients I'm getting the following two Audit Failures in the Security log:

    An IPsec main mode negotiation failed.
    
    Local Endpoint:
    	Local Principal Name:	-
    	Network Address:	2002:d5b0:91a5:8100:19a1:7094:9919:3984
    	Keying Module Port:	500
    
    Remote Endpoint:
    	Principal Name:		-
    	Network Address:	2002:d5b0:91a5::d5b0:91a5
    	Keying Module Port:	500
    
    Additional Information:
    	Keying Module Name:	IKEv1
    	Authentication Method:	Unknown authentication
    	Role:			Initiator
    	Impersonation State:	Not enabled
    	Main Mode Filter ID:	0
    
    Failure Information:
    	Failure Point:		Local computer
    	Failure Reason:		No policy configured
    
    	State:			No state
    	Initiator Cookie:		f88b2ecea742155c
    	Responder Cookie:	0000000000000000
    An IPsec extended mode negotiation failed. The corresponding main mode security association has been deleted.
    
    Local Endpoint:
    	Principal Name:		ANNATA\nori
    	Network Address:	2002:d5b0:91a5:8100:19a1:7094:9919:3984
    	Keying Module Port:	500
    
    Remote Endpoint:
    	Principal Name:		host/zanzan.annata.is
    	Network Address:	2002:d5b0:91a5::d5b0:91a5
    	Keying Module Port:	500
    
    Additional Information:
    	Keying Module Name:	AuthIP
    	Authentication Method:	Kerberos
    	Role:			Initiator
    	Impersonation State:	Enabled
    	Quick Mode Filter ID:	67673
    
    Failure Information:
    	Failure Point:		Local computer
    	Failure Reason:		IKE authentication credentials are unacceptable
    
    	State:			Sent second (SSPI) payload
    I've looked at the certificates and as far I can tell they are configured according to the prerequisites. There are two configured CRL distribution points. One LDAP and one publicly accessible.

    Has anyone seen this behavior?

    Kveðja,
    Nóri
    Tuesday, November 10, 2009 10:50 PM

Answers

  • Ok, we may you to collect tracing for further debugging.

    Can you please run the command: netsh wfp capture start
    on both the DA server and client at the same time.

    Try to repro the problem by accessing the same server you were trying before.
    When this fails run: netsh wfp capture stop
    to stop the traces.

    Please send us the etl files inside the .cab that were created.

    Thanks
    • Marked as answer by Erez Benari Monday, November 16, 2009 5:51 PM
    Sunday, November 15, 2009 4:20 PM
  • I tried a few reboots, but that didn't help.  What I did to fix it was to remove the domain controller IPv4 addresses I had hard coded in the hosts file on that particluar UAG server and do an ipconfig /flushdns.  I put those entries in the hosts file when I noticed one server always had trouble talking to IPv6 enabled resources and had to fall back to IPv4.  I thought maybe that was causing other issuses, but maybe putting those entries in the hosts file made it worse.

    Thanks,
    Ken

    Sunday, August 8, 2010 11:55 AM

All replies

  • Is ANNATA the name of your domain or the computer name?
    Make sure you:
     * log in using domain credentials
     * all IP addresses of all Domain Controllers in the domain were added to the management servers page
     * It doesn't seem like a certificate problem, but make sure the client and server have certificates that are chained to the root certificate selected in the UAG DirectAccess authentication options page
    Wednesday, November 11, 2009 1:58 PM
  • Thanks for the reply.

    That's the domain name. I'm using domain credentials and the two DCs were added to the management servers page. The root and intermediate certificate are installed on the DA server and on the clients. I'm using auto-enrollment for the machine certificate. Both the Root CA and Intermediate CA are running Windows Server 2003.

    Wednesday, November 11, 2009 3:38 PM
  • Can you please send me the output of ipconfig and "route print" on the client computer
    Wednesday, November 11, 2009 4:59 PM

  • Windows IP Configuration

       Host Name . . . . . . . . . . . . : nori-laptop
       Primary Dns Suffix  . . . . . . . : annata.is
       Node Type . . . . . . . . . . . . : Hybrid
       IP Routing Enabled. . . . . . . . : No
       WINS Proxy Enabled. . . . . . . . : No
       DNS Suffix Search List. . . . . . : annata.is
                                           vodafone

    Wireless LAN adapter Wireless Network Connection:

       Media State . . . . . . . . . . . : Media disconnected
       Connection-specific DNS Suffix  . :
       Description . . . . . . . . . . . : Intel(R) PRO/Wireless 2200BG Network Connection
       Physical Address. . . . . . . . . : 00-12-F0-B4-7D-52
       DHCP Enabled. . . . . . . . . . . : Yes
       Autoconfiguration Enabled . . . . : Yes

    Ethernet adapter Local Area Connection:

       Connection-specific DNS Suffix  . : vodafone
       Description . . . . . . . . . . . : Broadcom NetXtreme Gigabit Ethernet
       Physical Address. . . . . . . . . : 00-0F-B0-76-08-15
       DHCP Enabled. . . . . . . . . . . : Yes
       Autoconfiguration Enabled . . . . : Yes
       Link-local IPv6 Address . . . . . : fe80::acc0:faad:73e5:3f50%11(Preferred)
       IPv4 Address. . . . . . . . . . . : 192.168.1.34(Preferred)
       Subnet Mask . . . . . . . . . . . : 255.255.255.0
       Lease Obtained. . . . . . . . . . : 10. n¢vember 2009 18:34:14
       Lease Expires . . . . . . . . . . : 14. n¢vember 2009 00:53:01
       Default Gateway . . . . . . . . . : 192.168.1.1
       DHCP Server . . . . . . . . . . . : 192.168.1.1
       DHCPv6 IAID . . . . . . . . . . . : 234885040
       DHCPv6 Client DUID. . . . . . . . : 00-01-00-01-12-83-F4-E1-00-0F-B0-76-08-15
       DNS Servers . . . . . . . . . . . : 192.168.1.1
       NetBIOS over Tcpip. . . . . . . . : Enabled

    Tunnel adapter isatap.vodafone:

       Media State . . . . . . . . . . . : Media disconnected
       Connection-specific DNS Suffix  . : vodafone
       Description . . . . . . . . . . . : Microsoft ISATAP Adapter
       Physical Address. . . . . . . . . : 00-00-00-00-00-00-00-E0
       DHCP Enabled. . . . . . . . . . . : No
       Autoconfiguration Enabled . . . . : Yes

    Tunnel adapter isatap.{18DDC8C4-4D9D-4149-B535-459AB95D5595}:

       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:d5b0:91a5:fb:b9e0:3d6f:23fa(Preferred)
       Link-local IPv6 Address . . . . . : fe80::fb:b9e0:3d6f:23fa%19(Preferred)
       Default Gateway . . . . . . . . . : ::
       NetBIOS over Tcpip. . . . . . . . : Disabled

    Tunnel adapter iphttpsinterface:

       Media State . . . . . . . . . . . : Media disconnected
       Connection-specific DNS Suffix  . :
       Description . . . . . . . . . . . : iphttpsinterface
       Physical Address. . . . . . . . . : 00-00-00-00-00-00-00-E0
       DHCP Enabled. . . . . . . . . . . : No
       Autoconfiguration Enabled . . . . : Yes


    --------

    ===========================================================================
    Interface List
     14...00 12 f0 b4 7d 52 ......Intel(R) PRO/Wireless 2200BG Network Connection
     11...00 0f b0 76 08 15 ......Broadcom NetXtreme Gigabit Ethernet
      1...........................Software Loopback Interface 1
     13...00 00 00 00 00 00 00 e0 Microsoft ISATAP Adapter
     16...00 00 00 00 00 00 00 e0 Microsoft ISATAP Adapter #2
     19...00 00 00 00 00 00 00 e0 Teredo Tunneling Pseudo-Interface
     18...00 00 00 00 00 00 00 e0 iphttpsinterface
    ===========================================================================

    IPv4 Route Table
    ===========================================================================
    Active Routes:
    Network Destination        Netmask          Gateway       Interface  Metric
              0.0.0.0          0.0.0.0      192.168.1.1     192.168.1.34     20
            127.0.0.0        255.0.0.0         On-link         127.0.0.1    306
            127.0.0.1  255.255.255.255         On-link         127.0.0.1    306
      127.255.255.255  255.255.255.255         On-link         127.0.0.1    306
          192.168.1.0    255.255.255.0         On-link      192.168.1.34    276
         192.168.1.34  255.255.255.255         On-link      192.168.1.34    276
        192.168.1.255  255.255.255.255         On-link      192.168.1.34    276
            224.0.0.0        240.0.0.0         On-link         127.0.0.1    306
            224.0.0.0        240.0.0.0         On-link      192.168.1.34    276
      255.255.255.255  255.255.255.255         On-link         127.0.0.1    306
      255.255.255.255  255.255.255.255         On-link      192.168.1.34    276
    ===========================================================================
    Persistent Routes:
      None

    IPv6 Route Table
    ===========================================================================
    Active Routes:
     If Metric Network Destination      Gateway
     19     58 ::/0                     On-link
      1    306 ::1/128                  On-link
     19     58 2001::/32                On-link
     19    306 2001:0:d5b0:91a5:fb:b9e0:3d6f:23fa/128
                                        On-link
     11    276 fe80::/64                On-link
     19    306 fe80::/64                On-link
     19    306 fe80::fb:b9e0:3d6f:23fa/128
                                        On-link
     11    276 fe80::acc0:faad:73e5:3f50/128
                                        On-link
      1    306 ff00::/8                 On-link
     19    306 ff00::/8                 On-link
     11    276 ff00::/8                 On-link
    ===========================================================================
    Persistent Routes:
      None

    Wednesday, November 11, 2009 5:26 PM
  • It seems that the 2nd tunnel that's used to access corp resources is not being established successfully because of log-on failure.
    I would like to make sure you are able to access the domain controllers using the 1st tunnel.

    From the client computer while connected to the internet, can you please access a share on one of the DCs. (\\dc1\SysVol for example)
    If this doesn't succeed please press "Diagnose" and send the troubleshooting output.
    Please also try to run the command "nltest /dsgetdc:" and send the output

    Thanks
    • Marked as answer by Erez Benari Thursday, November 12, 2009 8:26 PM
    • Unmarked as answer by Nóri Friday, November 13, 2009 12:56 PM
    Thursday, November 12, 2009 9:00 AM
  • C:\>nltest /dsgetdc:
               DC: \\nebbi.annata.is
          Address: \\192.168.54.10
         Dom Guid: b1ddfaab-c505-4d36-b7ad-de7665dafd0c
         Dom Name: annata.is
      Forest Name: annata.is
     Dc Site Name: IS
    Our Site Name: IS
            Flags: GC DS LDAP KDC TIMESERV WRITABLE DNS_DC DNS_DOMAIN DNS_FOREST CLOSE_SITE FULL_SECRET
    The command completed successfully
    I get the following output from Network Diagnostics:

    file and print sharing resource (nebbi) is online but isn't responding to connection attempts.
    
    The remote computer isn’t responding to connections on port 445, possibly due to firewall or security 
    policy settings, or because it might be temporarily unavailable.
    Windows couldn’t find any problems with the firewall on your computer.
    Friday, November 13, 2009 12:56 PM
  • Ok, we may you to collect tracing for further debugging.

    Can you please run the command: netsh wfp capture start
    on both the DA server and client at the same time.

    Try to repro the problem by accessing the same server you were trying before.
    When this fails run: netsh wfp capture stop
    to stop the traces.

    Please send us the etl files inside the .cab that were created.

    Thanks
    • Marked as answer by Erez Benari Monday, November 16, 2009 5:51 PM
    Sunday, November 15, 2009 4:20 PM
  • Hello,

    were you able to resolve the specific problem? I have the same problem with DirectAccess and the same events.
    I'll be glad if you can tell me how to solve this problem.

    Thanks

    Wednesday, January 27, 2010 12:49 PM
  • Hi,
    Can you ping resources by name?
    Can you access a file share on the domain controller?

    Thanks

    Wednesday, January 27, 2010 5:33 PM
  • Hi,

    DNS lookup is working. I can ping all my servers by name but i cannot access file shares on the domain controller.

    Thanks
    Thursday, January 28, 2010 9:56 AM
  • Hi AI,

    It's clear that your intranet tunnel isn't coming up. If you open the Windows Firewall with Advanced Security, and expand the monitoring section, you'll see in the "Main Mode" node that there are no Kerberos authenticated connections.

    Are all the services on the UAG server started?
    Is are the IPv6 addresses of the DC and DNS server registered in DNS?

    Thanks!
    Tom
    MS ISDUA Anywhere Access Team
    Friday, January 29, 2010 5:37 PM
    Moderator
  • Hi,

    I've opened a Microsoft call. The infrastructure tunnel is working, but my client can't reach the DC. Thats why I don't get a Kerberos ticket. All services on the UAG are running.
    IPv6 addresses of the DC and DNS (one server) are registerd in DNS.

    At the moment Microsoft support is analyzing the log files - UAG seems to be configured correctly.

    Thanks,
    Martin
    Saturday, January 30, 2010 10:40 AM
  • Hi AI,

    It's good that you opened a support call about this.
    We have encountered this issue with a number of customers where they aren't able to access the DC even though it's configured in the 1st tunnel.
    We are currently working to investigate the issue and understand what triggers this.

    Thanks
    Sunday, January 31, 2010 12:56 PM
  • I have some news.

    After enabling the IPv6 protocol on the DC without any configuration, I was able to access the DC over the infrastructure tunnel. But only with iphttps, not with teredo.
    But no other ressources. We keep on working on this issue.

    Tuesday, February 2, 2010 9:47 AM
  • I have some news.

    After enabling the IPv6 protocol on the DC without any configuration, I was able to access the DC over the infrastructure tunnel. But only with iphttps, not with teredo.
    But no other ressources. We keep on working on this issue.


    I'm curious as to what you did to enable the IPv6 protocol on the DC. Are you referring to the ISATAP tunnel adapter?

    Thanks!
    Tom
    MS ISDUA Anywhere Access Team
    Friday, February 5, 2010 4:26 PM
    Moderator
  • Hi,

    I'm experiencing a similar situation:

    * I can ping the DC by hostname.
    * I can't access any Intranet resources via the browser or using net view
    * If I shutoff teredo my IPHTTPS interface fails to start with the error:

    Interface IPHTTPSInterface (Group Policy)  Parameters
    ------------------------------------------------------------
    Role                       : client
    URL                        : https://uag-srv.siammandalay.com:443/IPHTTPS
    Last Error Code            : 0x80092013
    Interface Status           : failed to connect to the IPHTTPS server. Waiting to reconnect

    The nltest /dsgetdc: command generates
    Getting DC name failed: Status = 1355 0x54b ERROR_NO_SUCH_DOMAIN

    Oddly enough, last night I *was* able to access Intrenet resources via IPHTTPS if I turned off teredo; today, however, it stopped working, and I'm not sure what caused this.

    Thanks in advance for any help.

    Regards,

    Kim
    Sunday, February 21, 2010 9:53 AM
  • Hi Kim,
    did you try to access the DC? try net view to the DC itself.
    Also make sure you have IPv6 enabled on our physical external network adapter (ncpa.cpl, open properties on the external NIC. make sure IPv6 is checked)

    The problem with your IP-HTTPS is that the client is unable to reach the CRL.
    here's a list of all IP-HTTPS error codes: http://msdn.microsoft.com/en-us/library/dd542646(VS.85).aspx

    Look at the Revocation server for the IP-HTTPS certificate and make sure it's reachable from the internet.

    Thanks,
    Yaniv
    Sunday, February 21, 2010 12:05 PM
  • Hi Yaniv,

    The revocation list is on the DC, which is internal and not published externally.

    It is reachable fromthe DA machine.

    Oddly, this (IP-HTTPS) was working yesterday, but somehow it stopped working.

    Regards,

    Kim
    Sunday, February 21, 2010 3:09 PM
  • When the CRL isn't published externally the behavior isn't exactly consistent. Sometimes it works, probably due to some caching of the CRL.
    but when this cache expires, the client is no longer able to validate the IP-HTTPS certificate
    Sunday, February 21, 2010 5:42 PM
  • Yaniv,

    In another thread you mention turning CRL checking off, referring to the lab step-by-step.  In a production environment, I assume that we wouldn't do this; therefore, are you saying that publishing the CRL externally is the only way to get this working?

    Also, i'm assuming this is only for IP-HTTPS.  If teredo was working for me, I wouldn't need to fall back on IP-HTTPS.  It seems that for the home subnet, that teredo is the way for clients to connect.  So I hope to get that working eventually.

    Thanks,

    Kim
    Monday, February 22, 2010 2:51 AM
  • Yaniv,

    I've just read this regarding UAG pre-requisites (http://technet.microsoft.com/en-us/library/dd857262.aspx):

    A certificate revocation list (CRL) distribution point that is reachable from a publicly resolvable fully qualified domain name (FQDN).

    Now to figure out how to do it when my CA is on my private network...

    Thanks,

    Kim
    Monday, February 22, 2010 8:37 AM
  • I found this article (http://blogs.technet.com/configmgrteam/archive/2009/05/01/how-to-publish-the-crl-on-a-separate-web-server.aspx) to be extermely helpful in publishing my CRL on the public Internet.

    Hopefully, I did it right and this will work when I get home.
    Monday, February 22, 2010 10:00 AM
  • Publishing the CRL has fixed my issue with connecting over IP-HTTPS.  Now, however, I still cannot connect to any Intranet resources except by ping on both teredo and IP-HHTPS.  I can ping, but that's it.

    Monday, February 22, 2010 12:54 PM
  • I'm now getting errors similar to the above thread:

    Error 1 - Event ID 4984

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

    Local Endpoint:

    Principal Name: CNX\Kim

    Network Address: 2002:ca08:4f18:8100:bc9e:91d9:2077:e994

    Keying Module Port: 500

    Remote Endpoint:

    Principal Name: host/UAG-SRV.SiamMandalay.com

    Network Address: 2002:ca08:xxxx::xxxx:xxx

    Keying Module Port: 500

    Additional Information:

    Keying Module Name: AuthIP

    Authentication Method: Kerberos

    Role: Initiator

    Impersonation State: Enabled

    Quick Mode Filter ID: 161633

    Failure Information:

    Failure Point: Local computer

    Failure Reason: IKE authentication credentials are unacceptable

    State: Sent second (SSPI) payload

    Error 2 - Event ID 4673


    A privileged service was called.

    Subject:

    Security ID: NETWORK SERVICE

    Account Name: LCNXKIMF$

    Account Domain: CNX

    Logon ID: 0x3e4

    Service:

    Server: Security

    Service Name: -

    Process:

    Process ID: 0x4ec

    Process Name: C:\Windows\System32\svchost.exe

    Service Request Information:

    Privileges: SeTcbPrivilege

     

    Monday, February 22, 2010 5:53 PM
  • Hi Kim,
    Is your domain name CNX, SiamMandalay or both?
    I see the remote principal name is:
    CNX\Kim, and I'm wondering whether this is a local computer account or a domain user.

    Did you add all of the domains to the Management Servers page?
    Monday, February 22, 2010 7:38 PM
  • Yaniv,

    In another thread you mention turning CRL checking off, referring to the lab step-by-step.  In a production environment, I assume that we wouldn't do this; therefore, are you saying that publishing the CRL externally is the only way to get this working?

    Also, i'm assuming this is only for IP-HTTPS.  If teredo was working for me, I wouldn't need to fall back on IP-HTTPS.  It seems that for the home subnet, that teredo is the way for clients to connect.  So I hope to get that working eventually.

    Thanks,

    Kim

    Hi Kim,
    Our assumption is that most enterprises will be using a commercial certificate on the IP-HTTPS listener. In that case, the CRL will be globally available. However, if you choose to use a private certifciate from your own PKI, you will need to publish the CRL.

    HTH,
    Tom
    MS ISDUA Anywhere Access Team
    Monday, February 22, 2010 7:54 PM
    Moderator
  • Hi Yaniv,

    The netbios domain is CNX and the dns domain is SiamMandalay.com, so it's both.  I inherited that.

    I'm logged into the client machine with the domain account not the local account.

    Regarding the managed servers page, I'm assuming you mean in the UAG DA setup, and yes, I'm seeing SiamMandalay.

    Remember at some point IP-HTTPS was working, which means that at some point IPSEC was working, right?

    Now, though I've fixed IP-HTTPS from failing by publishing the CRL, both teredo and IP-HTTPS can't connect.  IPSEC isn't working.

    I'm going to re-gen the web cert for the DA server and see if that helps, but I'm hopeful that the above errors can give a clue to the error.

    Regards,

    Kim
    Tuesday, February 23, 2010 3:05 AM
  • Hi Tom,

    Thanks for confirming this.  In your other thread you mention I don't need to do this with UAG.  Regardless, it's done and that fixed the issue with the httpstunnel interface error.

    Still looking for clues into why IPSEC doesn't work now.

    Thanks,

    Kim
    Tuesday, February 23, 2010 3:07 AM
  • Yaniv/Tom,

    I've done a wfp trace.  Where/how can I post my files.

    Thanks,

    Kim
    Tuesday, February 23, 2010 2:36 PM
  • How did you assign machine certificates to the DA server and DA client?

    Thanks!
    Tom
    MS ISDUA Anywhere Access Team
    Tuesday, February 23, 2010 5:06 PM
    Moderator
  • Hi Tom,

    Both certs were retrieved from our internal CA.

    The client erolled with a computer cert, and the DA with a web server cert.  Both of these trust the CA.

    I read and followed information here:  http://blogs.technet.com/edgeaccessblog/archive/2009/10/27/deep-dive-into-uag-directaccess-certificates.aspx.

    The error I'm still trying to figure out is event 4984, where I'm seeing:

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

    I found some dated information in the Server and Domain Isolation Using IPsec and Group Polcy:  http://www.microsoft.com/downloads/details.aspx?FamilyId=404FB62F-7CF7-48B5-A820-B881F63BC005&displaylang=en where it says:

    IKE security attributes are unacceptable. This event should not happen on properly configured systems. Complete the steps in the "Verifying the Correct IPsec Policy" section to investigate., but I'm having a hard time figuring out how to "properly configure" my system. :^)

    I appreciate your help.

    Thanks,

    Kim

    Tuesday, February 23, 2010 5:33 PM
  • Tom,

    By the way, aren't you the guy behind http://www.isaserver.org/ or were?

    I recognize your picture.  Great site, I've learned a lot from there over the years.

    Regards,

    Kim
    Tuesday, February 23, 2010 5:38 PM
  • You can send the wfp capture to our customer support and they'll be glad to help.

    Do you see the 4984 event on the UAG server or on the client?
    Can you please copy the exact events (Main Mode & Exteded Mode failures) you see on the UAG server.

    Thanks

    Tuesday, February 23, 2010 8:30 PM
  • Hi guys.

    Sorry for not replying earlier. I finally had some time to look at this and after some troubleshooting I believe I found the solution. At least DirectAccess is working for me now. I did three things:

    1. Disabled a Firewall GPO I already had configured for clients.
    2. Restored the default firewall settings on the client.
    3. Restored the default firewall settings on the UAG DirectAccess server.

    I then tested on two different clients. On the second client I skipped 1 and 2 so I'm guessing that restoring the default firewall settings on the UAG DA server did the trick.

    Hopefully this will work for others experiencing this behavior.

    Kveðja,
    Nóri

    Wednesday, February 24, 2010 2:39 AM
  • Nori & Co,

    I've read several threads that mention the same troubles and in the end re-installing UAG fixed the issue for a few people.  I'm wondering if that has the same effect as #3 above...

    I'm gonna try this.

    Thanks,

    Kim
    Wednesday, February 24, 2010 2:58 AM
  • *PROGRESS*

    Re-installing UAG on the DA server has "fixed" my teredo woes!

    Status now is:

    I can access internal resources via a browser and explorer using teredo from a home subnet.
    I cannot access internal resources via net view \\servername
    I cannot access intranet resources via IP-HTTPS with anything except ICMP.

    The net view problem, I'm baffled on since I can use explorer; however I see two errors related to IP-HTTPS in the security log:

    Event ID - 4957

    Windows Firewall did not apply the following rule:
    Rule Information:
    ID: CoreNet-IPHTTPS-In
    Name: Core Networking - IPHTTPS (TCP-In)

    Error Information:
    Reason: Local Port resolved to an empty set.

    Also

    Windows Firewall did not apply the following rule:

    Rule Information:
    ID: CoreNet-Teredo-In
    Name: Core Networking - Teredo (UDP-In)

    Error Information:
    Reason: Local Port resolved to an empty set.

    These only seem to show up with teredo disabled.

    Wednesday, February 24, 2010 3:46 AM
  • small clarification with regards to net view:

    I can do a net view with teredo using "net view \\dc, for example; however, I cannot do a net view on \\dc\sysvol.

    I can open both in explorer...

    No luck with IP-HTTPS still
    Wednesday, February 24, 2010 3:54 AM
  • Hi Kim.

    Both Teredo and IP-HTTPS are working for me. Are you still getting the IPSec errors in the event viewer?

    Kveðja,
    Nóri
    Thursday, February 25, 2010 5:49 PM
  • Hi Nori,

    Thanks for your interest.  I've taken a break from this project for a bit to clear my head and will hit it next week.

    Regards,

    Kim
    Friday, February 26, 2010 5:39 PM
  • Hi Kim

    Did you ever manage to get this resolved? I am facing similar issues :)

    Gavin

     

    Wednesday, May 5, 2010 12:30 PM
  • Hi Gavin,

    How does your setup diverge from the configuration in the UAG DA step by step lab?

    Thanks!

    Tom


    MS ISDUA/UAG DA Anywhere Access Team
    Wednesday, May 5, 2010 3:15 PM
    Moderator
  • I get a similar error.  We have a two server NLB array.  Usually I can reboot one of the servers and things will work OK for a few days and then the error will show up again.  The client can ping internal resources (it is an IP-HTTPS client) but it cannot get to infrastructure resources like DCs when it is in this state.  We also use smart cards for logins, altough when the client behaves like this we never get the smart card prompt and it doesn't help to login wtih the smart card.

    This is a section of that log from the client PC.

    Additional Information:

    Keying Module Name: AuthIP

    Authentication Method: Kerberos

    Role: Initiator

    Impersonation State: Enabled

    Quick Mode Filter ID: 229070

    Failure Information:

    Failure Point: Local computer

    Failure Reason: IKE authentication credentials are unacceptable

    State: Sent second (SSPI) payload

    Wednesday, July 21, 2010 8:45 PM
  • Hi Ken,

    This indicates a user account authentication failure for the second tunnel.

    Can you do a nltest /dsgetdc: /force and confirm connectivity?

    Thanks!

    Tom


    MS ISDUA/UAG DA Anywhere Access Team
    Thursday, July 22, 2010 11:46 AM
    Moderator
  • Tom,

    Thanks.  I will give that a try next time it fails.  I'm not sure if this is related or not, but what I see when both array members are up is that one of them always has trouble accessing IPv6 enabled resources like our Windows 2008 R2 domain controllers.  What happens is that the ISATAP traffic is sent from one array member, server 2 for example, but the return traffic ends up at server 1's ISATAP interface.  Then it gets dropped by TMG.  Does that make any sense?

    Thanks,
    Ken

    Thursday, July 22, 2010 11:20 PM
  • Hi Ken,

    Did you install the NLB fix on the array members before enabling NLB?

    KB977342

    Thanks!

    Tom


    MS ISDUA/UAG DA Anywhere Access Team
    Friday, July 23, 2010 11:44 AM
    Moderator
  • Yes, I made sure that one was installed.

    Thanks,
    Ken

    Friday, July 23, 2010 1:56 PM
  • I have another update on this.  Both array members were fine for about two weeks, but yesterday they rebooted for the out of band patch.  After the reboot users who go through server 2 now always get the IKE credentials error.  This is what the nltest command showed on my machine:

    C:\Windows\system32>nltest /dsgetdc: /force
    Getting DC name failed: Status = 1355 0x54b ERROR_NO_SUCH_DOMAIN

    I'm not saying the patch caused the issue, but the reboot seems to have some role in it.

    Thanks,
    Ken

    Friday, August 6, 2010 3:59 PM
  • Can you try rebooting the server again and see if it helps?
    Sunday, August 8, 2010 9:51 AM
  • I tried a few reboots, but that didn't help.  What I did to fix it was to remove the domain controller IPv4 addresses I had hard coded in the hosts file on that particluar UAG server and do an ipconfig /flushdns.  I put those entries in the hosts file when I noticed one server always had trouble talking to IPv6 enabled resources and had to fall back to IPv4.  I thought maybe that was causing other issuses, but maybe putting those entries in the hosts file made it worse.

    Thanks,
    Ken

    Sunday, August 8, 2010 11:55 AM
  • Hi,

     

    Happy ti see that i'm not alone. I experiment the same issue. To be precise EventID 4984 is generated when a user try to access ressources. The event is recorded on both UAG array member and the client.

     

    BenoîtS


    BenoitS - Simple by Design http://danstoncloud.com/blogs/simplebydesign/default.aspx
    Tuesday, August 10, 2010 8:52 PM
  • Hi BenoîtS,

    can you please open a new thread and paste your Event Log message

    Friday, August 13, 2010 12:40 PM