Benutzer mit den meisten Antworten
failed to connect to the IPHTTPS server. Waiting to reconnect

Frage
-
Hi,
ich habe 2 UAGs im Array fuer DA laufen.
Die GPOs wurden erstellt und applied.
Ein oeffentliches Zertifikat wurde als IPHTTPS Zertifikat gewaehlt. Die Clients vertrauen Thawte....
Leider kommt kein Connect per IPHTTPS zustande.
netsh int httpstunnel show interfaces
Interface IPHTTPSInterface (Group Policy) Parameters
------------------------------------------------------------
Role : client
URL : https://da1.firma.de:443/IPHTTPS
Last Error Code : 0x274c
Interface Status : failed to connect to the IPHTTPS server. Waiting to reconnectAuf dem Servern sieht es folgendermassen aus:
Role : server
URL : https://da1.firma.de:443/IPHTTPS
Client authentication mode: certificates
Last Error Code : 0x0
Interface Status : IPHTTPS interface activeWenn ich mit einem Browser auf dem Server mich auf die externe DIP connecte erhalte ich ein Default Web Site Zertifikat welches bis 01.01.3999 gueltig ist.
Wenn ich mit einem Browser auf dem Server mich auf die externe VIP conencte erhalte ich das da1.firma.de.Wenn ich mit einem Browser auf dem Client mich auf die externe VIP connecte erhalte ich garnichts.
Nachdem ich mit dem Network Monitor auf dem Server nachgesehen hab ob hier HTTPS Pakete von der Clientip ankommen weiss ich nun nicht mehr weiter.
Pakete kommen an, der Server schickt jedoch so wie es aussieht nichts raus.
SYN, SYN ACK fehlt mir leider...
Wenn ich im UAG Management unter Network Load Balancing nachsehe so hab ich hier eine VIP auf dem internen Interface sowie 2 aufeinanderfolgende IPs fuer das externe Interface. Alle 3 sind in Use.
NLB mode: Unicast
Wenn ich ICMP (Ping) fuer den Client welcher im Internet steht aktiviere (System Policy) und den UAG pinge, so bekomme ich auch etwas zurueck.
Vielen Dank vorab!
VG
- Bearbeitet teccy Montag, 19. September 2011 13:58
Montag, 19. September 2011 13:30
Antworten
-
Hi,
Fehler gefunden... und er war wirklich daemlich... das NLB wurde nicht aktiviert... Wer lesen kann ist klar im Vorteil...
Witzigerweise war es bis ca. 2min nach dem Reboot up bevor es wieder in den stopped state gebracht wurde.
Das hatte mich sehr verwundert.
Java sei dank und auf START klicken hilft ungemein...
Danke fuer die Tipps.
Das mit dem MACs habe ich nicht gebraucht.
- Als Antwort markiert teccy Dienstag, 20. September 2011 12:11
Dienstag, 20. September 2011 12:11
Alle Antworten
-
moin teccy,
hast du vor dem uag-array noch eine firewall stehen, die dir vlt. 443 blockt? läuft das nlb sauber - stichwort zusammenspiel mit den switchen - was meint der nlbmgr - dort alles im grünen?
gruss, jens mander aka karsten hentrup - www.aixperts.de - www.forefront-tmg.de - www.hentrup.net |<-|Montag, 19. September 2011 16:43 -
Hi,
was passiert, wenn Du versuchst Dich mit dem Browser eines nicht DA Clients mit der VIP-FQDN des UAG Array zu verbinden? Den Ping hast Du auf die VIP gemacht?
regards Marc Grote aka Jens Baier - www.it-training-grote.de - www.forefront-tmg.de - www.nt-faq.deMontag, 19. September 2011 18:13 -
Hi,
ja, vor dem Array steht noch eine FW. und auch dahinter... Ports wurden analog Technet freigegeben. Wie gesagt, Pakete kommen auf der VIP auch an.
der NLBMGR sagt dass er Probleme hat da er von einem Host ausgefuehrt wird der Teil des NLBs ist... dort sehe ich auch nur den lokalen Host, Eintraege sind hier rot. Ich probiere mich morgen mal Remote darauf zu connecten.
Zum Stichwort Switche: Die 2 UAGs laufen auf 2 Hyper-V Hosts die nichts anderes machen. MAC Spoofing wurde fuer beide VMs erlaubt.
@ Marc: Wenn ich dies Versuche so sehe ich Pakete auf die VIP am UAG ankommen (SYN) jedoch geht nichts zurueck an den Client. Den Ping hatte ich auf die beiden DIPs sowie VIP gemacht.
Danke vorab.
Montag, 19. September 2011 19:39 -
Hi,
die Meldung vom NLB Manager ist normal, wenn Du die NLB Manager Konsol direkt auf dem NLB Knoten im Unicast Modus ausfuehrst. Remote sollte dann zumindest diese "Fehlermeldung" verschwunden sein.
Wegen Unicast und Hyper-V kannst Du mal probieren die NLB VIP MAC statisch auf die Hyper-V VNIC Adapter zu legen:
http://www.shudnow.net/2008/09/12/exchange-2007-unicast-nlb-issue-on-hyper-v/
Im Unicast NLB Modus erhalten alle Netzwerkadapter des NLB Array die gleiche MAC Adresse.
regards Marc Grote aka Jens Baier - www.it-training-grote.de - www.forefront-tmg.de - www.nt-faq.deMontag, 19. September 2011 19:58 -
Hi,
Fehler gefunden... und er war wirklich daemlich... das NLB wurde nicht aktiviert... Wer lesen kann ist klar im Vorteil...
Witzigerweise war es bis ca. 2min nach dem Reboot up bevor es wieder in den stopped state gebracht wurde.
Das hatte mich sehr verwundert.
Java sei dank und auf START klicken hilft ungemein...
Danke fuer die Tipps.
Das mit dem MACs habe ich nicht gebraucht.
- Als Antwort markiert teccy Dienstag, 20. September 2011 12:11
Dienstag, 20. September 2011 12:11