Https Abfrage wird nicht durchgeleitet, aber nur von TMobile, sonst gehts!
Hallo,
ich habe meinen IIS10 Server mit einem Zertifikat versehen, die Seite https://vtpraxis.berlin ist über 1und1 mit statischer IP geschaltet und funktioniert erwartungsgemäß. Lediglich Anfragen, die ich über mein Handy mit tmobile Vertrag sende, werden abgewiesen. Alle anderen getesteten - auch mobile - Systeme zeigen die Seite an.
Der Experte von tmobile meinte, es läge am NAT Protokoll, insofern, dass tmobile IP Adressen vergibt, die vom NAT Protokoll als 'privat' eingestuft und dann entweder von 1und1 nicht weitergeleitet werden oder vom NAT Protokoll des IIS abegwiesen werden.
Im letzteren Fall müsste der Zugriff im IIS Protokoll aufgeführt sein, was aber nicht der Fall ist.
Ich kann der Argumentation nicht ganz folgen, da ich bei 1und1 Geschäftskunde bin und nach meiner Logik Privatkunden von tmobile dann generell nicht auf Geschäftsanschlüsse bei 1und1 zugreifen könnten.
Wäre toll, wenn jemand mir weiterhelfen könnte
Danke vorweg
ich habe meinen IIS10 Server mit einem Zertifikat versehen, die Seite https://vtpraxis.berlin ist über 1und1 mit statischer IP geschaltet und funktioniert erwartungsgemäß. Lediglich Anfragen, die ich über mein Handy mit tmobile Vertrag sende, werden abgewiesen. Alle anderen getesteten - auch mobile - Systeme zeigen die Seite an.
Der Experte von tmobile meinte, es läge am NAT Protokoll, insofern, dass tmobile IP Adressen vergibt, die vom NAT Protokoll als 'privat' eingestuft und dann entweder von 1und1 nicht weitergeleitet werden oder vom NAT Protokoll des IIS abegwiesen werden.
Im letzteren Fall müsste der Zugriff im IIS Protokoll aufgeführt sein, was aber nicht der Fall ist.
Ich kann der Argumentation nicht ganz folgen, da ich bei 1und1 Geschäftskunde bin und nach meiner Logik Privatkunden von tmobile dann generell nicht auf Geschäftsanschlüsse bei 1und1 zugreifen könnten.
Wäre toll, wenn jemand mir weiterhelfen könnte
Danke vorweg
Bitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 400398
Url: https://administrator.de/forum/https-abfrage-wird-nicht-durchgeleitet-aber-nur-von-tmobile-sonst-gehts-400398.html
Ausgedruckt am: 15.03.2025 um 15:03 Uhr
22 Kommentare
Neuester Kommentar
Zitat von @HansJoachm:
Der Experte von tmobile meinte, es läge am NAT Protokoll, insofern, dass tmobile IP Adressen vergibt, die vom NAT Protokoll als 'privat' eingestuft und dann entweder von 1und1 nicht weitergeleitet werden oder vom NAT Protokoll des IIS abegwiesen werden.
Der Experte von tmobile meinte, es läge am NAT Protokoll, insofern, dass tmobile IP Adressen vergibt, die vom NAT Protokoll als 'privat' eingestuft und dann entweder von 1und1 nicht weitergeleitet werden oder vom NAT Protokoll des IIS abegwiesen werden.
Das ist kein Experte, sondern ein Leute-Abwimmler. Selbst mit Carrier Grade NAT, wie es die meisten Mobilfunkanbieter betreiben, soltlest Du eine verbindung zu Deinem Webserver bekommen.
$ host vtpraxis.berlin
vtpraxis.berlin has address 90.187.98.57
vtpraxis.berlin has IPv6 address 2001:8d8:100f:f000::25a
vtpraxis.berlin mail is handled by 10 mx00.kundenserver.de.
vtpraxis.berlin mail is handled by 10 mx01.kundenserver.de.
Wie man sieht, hast Du öffentliche IP-Adressen. Was ich mir vorstellen kann, ist daß die Telekom Vodafone nicht mag (90.187.98.57 = business-90-187-98-57.pool2.vodafone-ip.de) udn daher blockiert.
lks
PS:
90.187.98.57 verwendet ein ungültiges Sicherheitszertifikat. Das Zertifikat gilt nur für folgende Namen: *.vtpraxis.berlin, vtpraxis.berlin Fehlercode: SSL_ERROR_BAD_CERT_DOMAIN
Hi
Da es bei anderen T-Mobile Kunden funktioniert würde ich nicht auf Tmoble tippen.
Hast du geprüft ob dein Handy als du es versucht hast in einem Wlan war ?
Sollte das handy in einem Wlan sein deaktiviere dieses zum test und versuche es über Lte nochmals.
PS: Das Sicherheitszertifikat könnte auch eine ursache dafür sein der Kollege Lochkartenstanzer geschrieben hat.
LG
Da es bei anderen T-Mobile Kunden funktioniert würde ich nicht auf Tmoble tippen.
Hast du geprüft ob dein Handy als du es versucht hast in einem Wlan war ?
Sollte das handy in einem Wlan sein deaktiviere dieses zum test und versuche es über Lte nochmals.
PS: Das Sicherheitszertifikat könnte auch eine ursache dafür sein der Kollege Lochkartenstanzer geschrieben hat.
LG
Zitat von @Kraemer:
Moin Hans-Joachim,
ich kann dein Problem nicht nachvollziehen - funktioniert hier einwandfrei.
Moin Hans-Joachim,
ich kann dein Problem nicht nachvollziehen - funktioniert hier einwandfrei.
bei mir nicht.
Ich bekomme nur die Meldung über das ungültige zertifikat, bzw eine SSL-Protokoll-Fehler
lks
PS. Lynx sagt:
$ lynx --dump http://vtpraxis.berlin
FRAME: [1]https://90.187.98.57
VTPraxisBerlin
[2]http://vtpraxis.berlin/
References
1. https://90.187.98.57/
2. https://90.187.98.57/
$ lynx --dump https://vtpraxis.berlin
Looking up vtpraxis.berlin
Making HTTPS connection to vtpraxis.berlin
Alert!: Unable to make secure connection to remote host.
lynx: Can't access startfile https://vtpraxis.berlin/
PPS: Prüfe mal Deinen Webserver und Deine Zeritifikate.
Zitat von @HansJoachm:
Lochstanzer, meinst Du, es könnte klappen, wenn ich die IPv6 Adresse in den AAA Record eintrage? Ich bin da aus Erfahrung vorsichtig mit Veränderungen
Lochstanzer, meinst Du, es könnte klappen, wenn ich die IPv6 Adresse in den AAA Record eintrage? Ich bin da aus Erfahrung vorsichtig mit Veränderungen
Solange Deine Zertifikate Probleme bereiten wird das nur stellenweise funktionieren.
lks
Hi,
um etwas für weitere Verwirrung zu sorgen:
Kam eben via Smartphone (FF; Telekom Businessvertrag) ohne Probleme zur nicht unbedingt schönsten HP des WWW's. (https://vtpraxis.berlin/)
P.s.: Ggf. mal Zeit für ein Remake der HP.
Gruß
Der Experte von tmobile
Sehr widersprüchlich.um etwas für weitere Verwirrung zu sorgen:
Kam eben via Smartphone (FF; Telekom Businessvertrag) ohne Probleme zur nicht unbedingt schönsten HP des WWW's. (https://vtpraxis.berlin/)
P.s.: Ggf. mal Zeit für ein Remake der HP.
Gruß
Zitat von @HansJoachm:
... genau, hieße dann aber, dass über tmobile nur Patienten mit Geschäftskundenvertrag die Seite aufrufen könnten. Das wäre ja mehr als schräg...
... genau, hieße dann aber, dass über tmobile nur Patienten mit Geschäftskundenvertrag die Seite aufrufen könnten. Das wäre ja mehr als schräg...
Wie Kommst du den darauf ??
Zitat von @HansJoachm:
das ist ein offizielles von Digizert. Hiesse dann wohl, dass tmobile speziell dieses Zertifikat blockt? Kann ich mir so nicht vorstellen. Wäre aber etwas völlig anderes als die NAT Theorie des tmobile Experten
das ist ein offizielles von Digizert. Hiesse dann wohl, dass tmobile speziell dieses Zertifikat blockt? Kann ich mir so nicht vorstellen. Wäre aber etwas völlig anderes als die NAT Theorie des tmobile Experten
Blödsinn !! Du hast ein Zertifikat für *.vtpraxis.berlin
90.187.98.57 verwendet ein ungültiges Sicherheitszertifikat. Das Zertifikat gilt nur für folgende Namen: *.vtpraxis.berlin, vtpraxis.berlin Fehlercode: SSL_ERROR_BAD_CERT_DOMAIN
Hier gefällt der name nicht. Wenn du die Seite auf www.vtpraxis.berlin legst kannst du nochmal testen.
Bitte such dir jemand der davon was versteht und lass es von ihm einrichten.
Ich führe auch keine Untersuchungen an Patienten durch.
LG
Kann es sein, dass das Problem nur bei ipv6 existiert?
https://www.ssllabs.com/ssltest/analyze.html?d=vtpraxis.berlin
ipv6 - Fehler https://www.ssllabs.com/ssltest/analyze.html?d=vtpraxis.berlin&s=200 ...
ipv4 - OK https://www.ssllabs.com/ssltest/analyze.html?d=vtpraxis.berlin&s=90. ...
https://www.ssllabs.com/ssltest/analyze.html?d=vtpraxis.berlin
ipv6 - Fehler https://www.ssllabs.com/ssltest/analyze.html?d=vtpraxis.berlin&s=200 ...
ipv4 - OK https://www.ssllabs.com/ssltest/analyze.html?d=vtpraxis.berlin&s=90. ...
nein. Bei v4 kommt gar keine Verbindung zustande (Telekom VDSL), traceroute geht aber.
Ich tippe auf ein problem beim webserver.
lks

Zitat von @HansJoachm:
... meine ich ja. Vielleicht sollte ich die IPv6 Adresse in den AAA Record eintragen ... das Problem mit der 'privaten' würde bei IPv6 wegfallen, meinte der Freundliche von der tmobile, bin nur nicht sicher, ob der Eintrag in den AAA Record das richtige ist...
Einen AAA Record gibt es nicht, wenn dann einen AAAA!... meine ich ja. Vielleicht sollte ich die IPv6 Adresse in den AAA Record eintragen ... das Problem mit der 'privaten' würde bei IPv6 wegfallen, meinte der Freundliche von der tmobile, bin nur nicht sicher, ob der Eintrag in den AAA Record das richtige ist...
Wenn der Server auch korrekt per IPv6 ansprechbar sein soll, am DNS Server der Domain auch den korrekten AAAA Record eintragen, wenn nicht, diesen entfernen, denn offensichtlich existiert schon einer, und dein Server selbst ist nicht korrekt konfiguriert. Und da Clients IPv6 bevorzugen wenn es verfügbar ist bekommst du dieses Verhalten. Wenn du den vorhandenen AAAA Record entfernst gehen die Clients automatisch auf IPv4,.
Dein IIS auch auf dem IPv6 Interface gebunden sein und lauschen und dort das Zertifikat auch gebunden sein! Scheint bei dir hier nicht der Fall zu sein wenn man die Wireshark Ausgaben auswertet.
Das dein Router IPv6 auf Port 443 zum Server durchlassen muss versteht sich hoffentlich von selbst.
Beschäftige dich mal eingehend mit IPv6. Dass wissen scheint dir hier offensichtlich noch zu fehlen.

Zitat von @HansJoachm:
... das könnte es sein. Der AAAA Eintrag entspricht bereits der SSLLabs anzeige -SSL Report: vtpraxis.berlin (2001:8d8:100f:f000:0:0:0:25a)-
Jepp, wenn du den entfernst, gehen die Clients automatisch auf IPv4, sofern der Cache die Einträge bereits vergessen hat. Wenn du es weiterhin nutzen willst s. weiter unten... das könnte es sein. Der AAAA Eintrag entspricht bereits der SSLLabs anzeige -SSL Report: vtpraxis.berlin (2001:8d8:100f:f000:0:0:0:25a)-
Sind für IPv6 weitere Ports zu öffnen? Die Durchleitung für IPv4 geht ja problemlos, insofern ist 443 schon klar...
Deine IPv6 Firewall des Routers muss den Port ebenfalls durchlassen!Wenn die Anwendung schon darauf hört dann hast du das Zertifikatt im IIS nicht an die IPv6Adresse gebunden.
... eine spezielle Möglichkeit zur Bindung von IPv6 im IIS hab ich noch nicht gefunden...
Doch, unter Bindungen muss die IPv6 bzw. für alle IPs der Interfaces * / [::]:443 das Zertifikat explizit hinterlegt sein.Mit netsh prüfen.
netsh http show sslcert

welche Ports IPv6 faktisch braucht
Ebenfalls TCP443 nur eben auf IPv6. Wenn du TCP443 in der Windows-Firewall freigibst ist dieser sowohl auf IPv4 als auch IPv6 freigegeben. Wenn nicht hast du irgendwo eine Block-Regel die davor steht. Oder irgendeine Security-Suite am laufen.Btw. einen ungehärteten IIS würde ich so nie ans Netz hängen. Besser gleich einen Reverse-Proxy davor setzen!