Feb 04, 2019

1869

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

Please also mark the comments that contributed to the solution of the article

Content-Key: 400398

Url: https://administrator.de/contentid/400398

Printed on: April 16, 2024 at 10:04 o'clock

22 Comments

Latest comment

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.

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

Moin Hans-Joachim,

ich kann dein Problem nicht nachvollziehen - funktioniert hier einwandfrei.

Gruß

PS: Dir ist bewusst, dass man deine Seite heutzutage ausschließlich mit vielen negativen Wörtern beschreibt? Da passt ja überhaupt nichts...

Zitat von @Kraemer:

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.

hi, vielleicht ein Missverständnis - ich wüsste nicht, dass es bei anderen t-mobile Kunden funktioniert. Wie kommst Du darauf? Hast Du einen T-mobile Anschluss?

Ich war sicher nicht im WLan, im WLan funktionert es problemlos, so wie von anderen mobile Anbietern auch...

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

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

Solange Deine Zertifikate Probleme bereiten wird das nur stellenweise funktionieren.

lks

Hi,

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ß

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

... 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... entspäche aber der Auskunft. Wäre m.E. ein Fall für die Presse, wenns überhaupt jemanden interessiert.

Klar ist ein remake fällig, aber ich muss da aus Zeitgründen Prioritäten setzen. Aber der Kenner schätzt auch die handprogrammierte Wikipedia

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...

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

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

Wenn der Name deines Sicherheitszertifikats nicht passt wird dir ein neuerstellen der homepage nichts bringen.
Aber totzdem viel Spass dabei.

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. ...

Zitat von @Kraemer:

Kann es sein, dass das Problem nur bei ipv6 existiert?

nein. Bei v4 kommt gar keine Verbindung zustande (Telekom VDSL), traceroute geht aber.

Ich tippe auf ein problem beim webserver.

lks

Zitat von @Kraemer:

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. ...

... 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...

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!
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 @138721:

Einen AAA Record gibt es nicht, wenn dann einen AAAA!
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.
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.

... 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...

http://www.ipv6scanner.com/cgi-bin/main.py gib folgende Auskunft :

Your IP address is 90.187.98.57

vtpraxis.berlin

Ports: I am authorized to initiate this port scan.
Host name: vtpraxis.berlin
IPV6: 2001:8d8:100f:f000::25a
IPV4: 90.187.98.57
OPEN An application is listening for connections on that port
CLOSED No application listening on that port
FILTERED The port is blocked by firewall or other network obstacle
TCP Port IPV4 State IPV6 State Service
21 FILTERED CLOSED ftp
22 FILTERED CLOSED ssh
23 FILTERED CLOSED telnet
25 FILTERED CLOSED smtp
53 FILTERED CLOSED domain
80 FILTERED OPEN http
110 FILTERED CLOSED pop3
137 FILTERED CLOSED netbios-ns
138 FILTERED CLOSED netbios-dgm
139 FILTERED CLOSED netbios-ssn
443 OPEN OPEN https
445 FILTERED CLOSED microsoft-ds
587 FILTERED CLOSED submission
993 FILTERED CLOSED imaps
995 FILTERED CLOSED pop3s
1080 CLOSED CLOSED socks
1433 FILTERED CLOSED ms-sql-s
1701 FILTERED CLOSED l2f
1723 FILTERED CLOSED pptp
3306 FILTERED CLOSED mysql
5432 FILTERED CLOSED postgresql
8000 FILTERED CLOSED http-alt
8080 FILTERED CLOSED http-proxy
11211 FILTERED CLOSED unknown

... eine spezielle Möglichkeit zur Bindung von IPv6 im IIS hab ich noch nicht gefunden... Wenn ich die IPv6 Adresse unter Bindung/IP eintrage, geht nichts mehr...

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

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

... famos. Wenn ich den Windows Firewall ausschalte, funktioniert der Zugriff. Jetzt müsste ich nur noch herausfinden, welche Ports IPv6 faktisch braucht. Aber vielen Dank, Laserjet, das war sehr hilfreich und konstruktiv.

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!

. das erste bullshit, hatte ich wohl auf einen Zwischenspeicher zugegriffen

Ich muss also an einen speziellen IPv6 Firewall ran, der hinter eine KabelBox im Bridgemodus und einer Fritzbox mit Portweiterleitung hängt. Mache ich morgen weiter, aber erstmal herzlichen Dank an alle

German solved Question Server Internet