none
IPHTTPS Error 0x800b0109 suddenly RRS feed

  • Question

  • Hi!

     

    2 days ago everything was working. now i get the "0x800b0109" error on the iphttps interface

     

    we use a valid godaddy cert....

     

    any idea whats going on ?

     

    thats

     

    (TMG/UAG) latest patches

    Monday, October 17, 2011 7:37 AM

All replies

  • Hi Marco,

    Start with verifying that all crl's are reachable for the IPHTTPS certificate.
    Could be as simple as your clients temporarily not beeing able to verify the CRL.
    (certutil.exe -url <url of crl>)

     

    Would also be interesting (and probably a quick test) to see if the following has an impact on one of your clients?

    http://social.technet.microsoft.com/Forums/en-US/forefrontedgeiag/thread/73c49a26-322c-4d28-b246-22b632e31f1c/

    Best wishes,
    Jonas Blom

    Monday, October 17, 2011 9:17 AM
  • well crl works from client and from server.....

     

    i am a bit lost now.

     

    the second link i think doesnt fit

    Monday, October 17, 2011 11:12 AM
  • Parameter für die Schnittstelle IPHTTPSInterface (Group Policy)
    ------------------------------------------------------------
    Rolle                       : client
    URL                        : https://:443/IPHTTPS
    Letzter Fehlercode            : 0x800b0109
    Schnittstellenstatus           : Die Verbindung mit dem IP-HTTPS-Server wurde ni
    cht hergestellt. Es wird auf das Herstellen einer neuen Verbindung gewartet.
    Monday, October 17, 2011 11:12 AM
  • actually i worked for a second.. ping went through now its broken again
    Monday, October 17, 2011 11:15 AM
  • (i removed the url)
    Monday, October 17, 2011 11:16 AM
  • Hi again,

    Try enabling the CAPI2 log on a client and check if there is an error or warning listed there that relates to the IPHTTPS certificate.

    (Eventviewer -> Applications and Services Logs -> Microsoft -> Windows -> CAPI2)

     

    Best wishes,
    Jonas Blom

     

    Monday, October 17, 2011 12:17 PM
  • well thanks i just reinstalled the uag server

     

    its works fine now... except i cannot reach the dns (ping to ipv6 isatap is working though)

     

    well this worked before...

     

    arghhhh

     

    the uag is in an dmz.. any idea how i can trouble hsoot this?

     

     

    Monday, October 17, 2011 4:25 PM
  • Hi again,

    Regarding the DNS issue in your new setup, are we talking about the DNS64 feature on your UAG host?
    If so, verify that the DNS64 service is running.

    Otherwise it of course depends on where your DNS server is located.
    A simple initial test is to use nslookup and specify the IPv6 address of the DNS server and verify if/that DNS queries reaches it?

     

    Best wishes,
    Jonas Blom

     

    Monday, October 17, 2011 6:23 PM
  • yes dns64 on uag....

     

    service is running

     

    i see no

     

    netsh advfirewall monitor show mmsa 

     

    on the client.. its empty

     

     

    hmmm

    RED: Corporate connectivity is not working.
    Your computer cannot connect to some corporate resources. If the problem persists, contact your administrator.
    16/10/2011 20:3:41 (UTC)


    Probes List
    PASS - PING: 2002:57e1:fd9e::57e1:fd9e
    FAIL - FILE: \\spk14-berlin\netlogon\login.bat

    DTE List
    PASS - PING: 2002:57e1:fd9e::57e1:fd9e
    PASS - PING: 2002:57e1:fd9d::57e1:fd9d

    Monday, October 17, 2011 6:31 PM
  • The DCA error is probably because of the DNS errors.
    Can you query the internal DNS servers from your UAG server?

    Most likely this is related to the IPSec tunnels not beeing established, enable IPSec debugging to start troubleshooting this.

    To test DNS64 lookup from your client: (in a cmd.exe)

    nslookup
    set server 2002:57e1:fd9d::57e1:fd9d
    spk14-berlin

     

    (This is a simple way to generate traffic that is supposed to go through the IPSec tunnels from your client to your UAG server)

     

    Best wishes,
    Jonas Blom

     

    Monday, October 17, 2011 6:42 PM
  • thanks

     i think dns is working from the uag server correctly.

     

    > set server 2002:57e1:fd9d::57e1:fd9d

    Unrecognized command: set server 2002:57e1:fd9d::57e1:fd9d

    > spk14-berlin

    Server:  alicebox

    Address:  192.168.1.1

     

    *** spk14-berlin wurde von alicebox nicht gefunden: Non-existent domain

    > server 2002:57e1:fd9d::57e1:fd9d

    Standardserver:  [2002:57e1:fd9d::57e1:fd9d]

    Address:  2002:57e1:fd9d::57e1:fd9d

     

    > heise.de

    Server:  [2002:57e1:fd9d::57e1:fd9d]

    Address:  2002:57e1:fd9d::57e1:fd9d

     

    DNS request timed out.

        timeout was 2 seconds.

    DNS request timed out.

        timeout was 2 seconds.

    DNS request timed out.

        timeout was 2 seconds.

    DNS request timed out.

        timeout was 2 seconds.

    *** Zeitüberschreitung bei Anforderung an [2002:57e1:fd9d::57e1:fd9d].

    > spk14-berlin

    Server:  [2002:57e1:fd9d::57e1:fd9d]

    Address:  2002:57e1:fd9d::57e1:fd9d

     

    DNS request timed out.

        timeout was 2 seconds.

    DNS request timed out.

        timeout was 2 seconds.

    *** Zeitüberschreitung bei Anforderung an [2002:57e1:fd9d::57e1:fd9d].

    >

    so no dns from the CLIENT
    ping works though
    Ping wird ausgeführt für 2002:57e1:fd9d::57e1:fd9d mit 32 Bytes Daten:
    Antwort von 2002:57e1:fd9d::57e1:fd9d: Zeit=28ms
    Antwort von 2002:57e1:fd9d::57e1:fd9d: Zeit=29ms
    Ping-Statistik für 2002:57e1:fd9d::57e1:fd9d:
        Pakete: Gesendet = 2, Empfangen = 2, Verloren = 0
        (0% Verlust),
    Ca. Zeitangaben in Millisek.:
        Minimum = 28ms, Maximum = 29ms, Mittelwert = 28ms

     

     


    maybe the dns64 are not processed somehow? how can i debug this on the uag server?

     

    Thanks!

    Tuesday, October 18, 2011 5:35 AM
  • from the client:

     

    1 07:44:37 18.10.2011 1.8141082 NetmonFilter NetmonFilter:Updated Capture Filter: None

    2 07:44:37 18.10.2011 1.8141082 NetworkInfoEx NetworkInfoEx:Network info for , Network Adapter Count = 12

    3 07:44:37 18.10.2011 1.8141082 2002:57E1:FD9D:8100:BCBD:ED46:D722:495F 2002:57E1:FD9D:0:0:0:57E1:FD9D DNS DNS:QueryId = 0xB, QUERY (Standard query), Query  for heise.de.pkberlin.local of type Host Addr on class Internet {DNS:3, UDP:2, IPv6:1}

    4 07:44:37 18.10.2011 2.2217429 FE80:0:0:0:A990:C998:9F93:B048 FE80:0:0:0:4CA7:50C7:FA85:2EB9 ICMPv6 ICMPv6:Neighbor Solicitation, Target = FE80:0:0:0:4CA7:50C7:FA85:2EB9 {IPv6:4}

    5 07:44:37 18.10.2011 2.2218353 FE80:0:0:0:4CA7:50C7:FA85:2EB9 FE80:0:0:0:A990:C998:9F93:B048 ICMPv6 ICMPv6:Neighbor Advertisement, Target = FE80:0:0:0:4CA7:50C7:FA85:2EB9 {IPv6:4}

    6 07:44:39 18.10.2011 3.8174393 2002:57E1:FD9D:8100:BCBD:ED46:D722:495F 2002:57E1:FD9D:0:0:0:57E1:FD9D DNS DNS:QueryId = 0xC, QUERY (Standard query), Query  for heise.de.pkberlin.local of type AAAA on class Internet {DNS:6, UDP:5, IPv6:1}

    7 07:44:40 18.10.2011 5.3319542 2002:57E1:FD9D:8100:BCBD:ED46:D722:495F 2002:57E1:FD9E:0:0:0:57E1:FD9E ICMPv6 ICMPv6:Echo request, ID = 0x1, Seq = 0x297 {ICMPv6:8, IPv6:7}

    8 07:44:40 18.10.2011 5.3325223 2002:57E1:FD9D:8100:BCBD:ED46:D722:495F 2002:57E1:FD9E:0:0:0:57E1:FD9E ICMPv6 ICMPv6:Echo request, ID = 0x1, Seq = 0x298 {ICMPv6:8, IPv6:7}

    9 07:44:40 18.10.2011 5.3330397 2002:57E1:FD9D:8100:BCBD:ED46:D722:495F 2002:57E1:FD9D:0:0:0:57E1:FD9D ICMPv6 ICMPv6:Echo request, ID = 0x1, Seq = 0x299 {ICMPv6:9, IPv6:1}

    10 07:44:40 18.10.2011 5.3585510 2002:57E1:FD9E:0:0:0:57E1:FD9E 2002:57E1:FD9D:8100:BCBD:ED46:D722:495F ICMPv6 ICMPv6:Echo reply, ID = 0x1, Seq = 0x297 {ICMPv6:8, IPv6:7}

    11 07:44:40 18.10.2011 5.3589552 2002:57E1:FD9E:0:0:0:57E1:FD9E 2002:57E1:FD9D:8100:BCBD:ED46:D722:495F ICMPv6 ICMPv6:Echo reply, ID = 0x1, Seq = 0x298 {ICMPv6:8, IPv6:7}

    12 07:44:40 18.10.2011 5.3610378 2002:57E1:FD9D:0:0:0:57E1:FD9D 2002:57E1:FD9D:8100:BCBD:ED46:D722:495F ICMPv6 ICMPv6:Echo reply, ID = 0x1, Seq = 0x299 {ICMPv6:9, IPv6:1}

    13 07:44:41 18.10.2011 5.8178865 2002:57E1:FD9D:8100:BCBD:ED46:D722:495F 2002:57E1:FD9D:0:0:0:57E1:FD9D DNS DNS:QueryId = 0xD, QUERY (Standard query), Query  for heise.de of type Host Addr on class Internet {DNS:11, UDP:10, IPv6:1}

    14 07:44:43 18.10.2011 7.8294359 2002:57E1:FD9D:8100:BCBD:ED46:D722:495F 2002:57E1:FD9D:0:0:0:57E1:FD9D DNS DNS:QueryId = 0xE, QUERY (Standard query), Query  for heise.de of type AAAA on class Internet {DNS:13, UDP:12, IPv6:1}

    15 07:44:45 18.10.2011 10.1345376 2002:57E1:FD9D:8100:A990:C998:9F93:B048 2002:57E1:FD9D:8100:BCBD:ED46:D722:495F ICMPv6 ICMPv6:Neighbor Solicitation, Target = 2002:57E1:FD9D:8100:BCBD:ED46:D722:495F {IPv6:14}

    16 07:44:45 18.10.2011 10.1346528 2002:57E1:FD9D:8100:BCBD:ED46:D722:495F 2002:57E1:FD9D:8100:A990:C998:9F93:B048 ICMPv6 ICMPv6:Neighbor Advertisement, Target = 2002:57E1:FD9D:8100:BCBD:ED46:D722:495F {IPv6:14}

    Tuesday, October 18, 2011 5:45 AM
  • Hi,

     

    It's most likely an IPSec problem.

    The DNS queries goes through the ipsec tunnels, so when ping to the uag works but not DNS you can almost always link it to the ipsec tunnels.

     

    Did you get any ipsec errors when you tried the above?

    (always good to enable ipsec debugging on both the testclient and the uag server if you didn't do it yesterday)

     

    Try running nslookup locally on the UAG against itself if you want to doublecheck that the dns64 service works as it should.

     

    //Jonas

     

     

    Tuesday, October 18, 2011 5:58 AM
  • well on the uag i get timeouts!

     

    > server 2002:57e1:fd9d::57e1:fd9d
    DNS request timed out.
        timeout was 2 seconds.
    Standardserver:  [2002:57e1:fd9d::57e1:fd9d]
    Address:  2002:57e1:fd9d::57e1:fd9d

    > heise.de
    Server:  [2002:57e1:fd9d::57e1:fd9d]
    Address:  2002:57e1:fd9d::57e1:fd9d

    *** heise.de wurde von [2002:57e1:fd9d::57e1:fd9d] nicht gefunden: No response f
    rom server.
    > yahoo.de
    Server:  [2002:57e1:fd9d::57e1:fd9d]
    Address:  2002:57e1:fd9d::57e1:fd9d

    *** yahoo.de wurde von [2002:57e1:fd9d::57e1:fd9d] nicht gefunden: No response f
    rom server.
    > www.yahoo.de
    Server:  [2002:57e1:fd9d::57e1:fd9d]
    Address:  2002:57e1:fd9d::57e1:fd9d

    *** www.yahoo.de wurde von [2002:57e1:fd9d::57e1:fd9d] nicht gefunden: No respon
    se from server.
    >

     

    can it be a firewall problem somewhere?

     

    (INTERNET) - (UAG SERVER IN DMZ) - (ROUTER) - (LAN WITH ipv4 DNS)

     

    actually i allowed everything on the router from an to... its right that the request goes to the ipv4 address of the ipv4 dns server?

     

    where can i inspect those ipsec logs on the clients?

     

    thanks!

     

     

     

    Tuesday, October 18, 2011 6:38 AM
  • currports says that the dns server ist listening on the ipv6 address 2002:...fd9e (udp and tcp 53)

     

    so it seems to run

    Tuesday, October 18, 2011 6:51 AM
  • Two things.

    Try against your secondary 6to4 IP instead (The same one that is listed as DirectAccess DNS server if you run "netsh namesspace show policy")

    I just tested locally on a UAG server, a DNS service is listening on the primary 6to4 address but it refuses all my questions so just ignore testing locally.
    (On the secondary the connection is blocked completed)

     

    About IPSec,
    To enable, run the following commandline in an elevated cmd.exe
    auditpol.exe /set /subcategory:"IPsec Main Mode","IPsec Quick Mode","IPsec Extended Mode"  /success:enable /failure:enable

    You will then find the log entries in Eventviewer in the Security log

    Tuesday, October 18, 2011 6:54 AM
  • Thanks!

     

    1.  No reponse from the secondary ip also

    C:\Windows\system32>nslookup
    Standardserver:  spk14-berlin.pkberlin.local
    Address:  10.0.149.230

    > server 2002:57e1:fd9d::57e1:fd9e
    Standardserver:  [2002:57e1:fd9d::57e1:fd9e]
    Address:  2002:57e1:fd9d::57e1:fd9e

    > www.heise.de
    Server:  [2002:57e1:fd9d::57e1:fd9e]
    Address:  2002:57e1:fd9d::57e1:fd9e

    *** www.heise.de wurde von [2002:57e1:fd9d::57e1:fd9e] nicht gefunden: No respon
    se from server.
    > www.google.de
    Server:  [2002:57e1:fd9d::57e1:fd9e]
    Address:  2002:57e1:fd9d::57e1:fd9e

    *** www.google.de wurde von [2002:57e1:fd9d::57e1:fd9e] nicht gefunden: No respo
    nse from server.
    > spk14-berlin
    Server:  [2002:57e1:fd9d::57e1:fd9e]
    Address:  2002:57e1:fd9d::57e1:fd9e

    *** spk14-berlin wurde von [2002:57e1:fd9d::57e1:fd9e] nicht gefunden: No respon
    se from server.
    >

    2. i always get an error 0x00000057 wrong parameters

     

    thanks!

     

     

    Tuesday, October 18, 2011 7:42 AM
  • 2. its because of german windows ;-)

     

    C:\Windows>auditpol.exe /set /subcategory:"IPsec-Hauptmodus","IPsec-Schnellmodus

    ","IPsec-Erweiterungsmodus"  /success:enable /failure:enable

    Tuesday, October 18, 2011 7:56 AM
  • ok i get an ipsec error on the client: ipsec-main mode negotiation

    Fehler bei einer IPsec-Hauptmodusaushandlung.

     

    Lokaler Endpunkt:

    Lokaler Prinzipalname: -

    Netzwerkadresse: 2002:57e1:fd9d:8100:5531:11e1:a103:2466

    Port des Schlüsselerstellungsmoduls: 500

     

    Remoteendpunkt:

    Prinzipalname: -

    Netzwerkadresse: 2002:57e1:fd9e::57e1:fd9e

    Port des Schlüsselerstellungsmoduls: 500

     

    Zusätzliche Informationen:

    Schlüsselerstellungsmodulname: IKEv1

    Authentifizierungsmethode: Unbekannte Authentifizierung.

    Rolle: Initiator

    Identitätswechselstatus: Nicht aktiviert

    Hauptmodus-Filter-ID: 0

     

    Fehlerinformationen:

    Fehlerpunkt: Lokaler Computer

    Fehlerursache: Keine Richtlinie konfiguriert.

     

    Status: Kein Status

    Initiatorcookie: d945561ded205688

    Antwortdienstcookie: 0000000000000000

    Tuesday, October 18, 2011 8:02 AM
  • it was working once.. now it stopped (dns resolution)
    Tuesday, October 18, 2011 9:15 AM
  • Now i get this error:

     

    Fehler bei einer IPsec-Hauptmodusaushandlung.

     

    Lokaler Endpunkt:

    Lokaler Prinzipalname: -

    Netzwerkadresse: 2002:57e1:fd9d:8100:99b:deaf:6cdf:e74b

    Port des Schlüsselerstellungsmoduls: 500

     

    Remoteendpunkt:

    Prinzipalname: -

    Netzwerkadresse: 2002:57e1:fd9e::57e1:fd9e

    Port des Schlüsselerstellungsmoduls: 500

     

    Zusätzliche Informationen:

    Schlüsselerstellungsmodulname: AuthIP

    Authentifizierungsmethode: Unbekannte Authentifizierung.

    Rolle: Initiator

    Identitätswechselstatus: Nicht aktiviert

    Hauptmodus-Filter-ID: 77711

     

    Fehlerinformationen:

    Fehlerpunkt: Lokaler Computer

    Fehlerursache: IKE-Authentifizierung-Anmeldeinformationen sind nicht akzeptabel.

     

    Status: Gesendete zweite (KE-) Nutzlast

    Initiatorcookie: 1bd1bd22b4732177

    Antwortdienstcookie: c2e969da55437f7c

    Tuesday, October 18, 2011 11:12 AM
  • Hi again,

    When it worked, did you generate a DCA logfile?
    It would be interesting to compare it to one where it doesn't work.

    I would almost say that you need to go through the GPO's beeing applied on your client and look for something that could disturb either the Windows Firewall or IPSec rules.

     

    Wednesday, October 19, 2011 7:39 AM
  • Gleichen Fehler habe ich hier auch! Hast Du eine Lösung?

    Same problem! Did you successfuly solved it?

    Friday, November 4, 2011 1:57 PM