Eigenes Heimnetz nicht erreichbar

[Captn]

Hallo Leute,

ich habe ein kleines Problem mit der Erreichbarkeit meines Webservers von außen.
Dies äußerst sich, indem ich aus meinem eigenen Heimnetz nicht über meine FQDN auf meinen Webserver zugreifen kann.
Wenn ich allerdings über einen VPN gehe - mir also eine andere IP zulege als die, über die mein Webserver erreichbar ist - dann funktioniert der Zugriff.
Dies war nicht immer so, aber ich kann auch nicht eingrenzen, an welcher Komponente dies liegen kann.

Mein Aufbau:

Modem: TC4400 (neu)
Router: UDMP
DynDNS: Strato
Server: Synology
DNS: Pihole -> 1.1.1.1

Das einzige, was sich geändert hat, ist, dass ich ein anderes Modem verwende. Vorher hatte ich eine FB6591 dran, welche ich durch das TC4400 ersetzt habe.
Ansonsten ist alles soweit gleich geblieben.

Ich habe es auch schon direkt über Cloudflare als DNS versucht um zu sehen, ob das Pihole irgend einen Loop unterdrückt. Aber das hat nichts gebracht.
Merkwürdiger weise, ist mein Smartphone das einzige Gerät in meinem Netz, welches den Server auch aus dem Heimnetz erreichen kann. Alle anderen Geräte (auch andere Smartphones) können dies eben nicht.

Hat mir jmd vllt einen Tip was ich machen kann oder was ich noch prüfen kann?

Vielen Dank an euch schon einmal!

 

[Bigdog71]

Hätte die Fritzbox 6591 einen Bridge Mode eingeschaltet vor der UDMP?

Dyndns über die UDMP eingerichtet und geprüft das es funktioniert?

Hat die Synology eine feste IP bzw. irgendwelche Sicherheitseinstellungen die Filtern?

 

[tq1199]

Mein Aufbau:

Modem: TC4400 (neu)
Router: UDMP
DynDNS: Strato
Server: Synology
DNS: Pihole -> 1.1.1.1

Das einzige, was sich geändert hat, ist, dass ich ein anderes Modem verwende. Vorher hatte ich eine FB6591 dran, welche ich durch das TC4400 ersetzt habe.
Ansonsten ist alles soweit gleich geblieben.

Wenn die FB6591 im RIP-Modus war, dann war sie auch das gateway für den Router (UDMP), ... was beim TC440 nicht so sein wird. Die FB6591 war in der Konstellation, keine transparentes Modem, so wie es das TV440 ist.
Wie ist mit der FB6591 dem UDMP (als border device), die öffentliche IPv4-Adresse zugewiesen worden und wie wird mit dem TC4400, dem UDMP (als border device), die öffentliche IPv4-Adresse zugewiesen?

 

[Captn]

Hätte die Fritzbox 6591 einen Bridge Mode eingeschaltet vor der UDMP?

Dyndns über die UDMP eingerichtet und geprüft das es funktioniert?

Hat die Synology eine feste IP bzw. irgendwelche Sicherheitseinstellungen die Filtern?

HalloBigdog,

nein, die FB vorher hatte keinen Bridgemode. Es war meine eigene und daher war dies nicht möglich. Somit hatte ich quasi doppeltes NAT, welches ich mit dem TC4400 abgeschafft habe.
Das dyndns funktioniert einwandfrei. Ich kann ja von außerhalb meines Netzwerks auf mein NAS zugreifen. Auch funktioniert der VPN Tunnel der UDMP.
An den Einstellungen der Synology habe ich nichts geändert. Es gibt dort auch keine Filterung wie zB Länderfilter o.ä.

Grüße!

 

[Captn]

Wenn die FB6591 im RIP-Modus war, dann war sie auch das gateway für den Router (UDMP), ... was beim TC440 nicht so sein wird. Die FB6591 war in der Konstellation, keine transparentes Modem, so wie es das TV440 ist.
Wie ist mit der FB6591 dem UDMP (als border device), die öffentliche IPv4-Adresse zugewiesen worden und wie wird mit dem TC4400, dem UDMP (als border device), die öffentliche IPv4-Adresse zugewiesen?

Hi tq,

das kann ich dir gar nicht sagen, in welchem Modus meine FB6591 sich befand. Ich kann es auch nicht mehr nachvollziehen, da ich sie nicht mehr habe.
Es war so:
Die FB bekam ganz normal die öffentliche IP zugewiesen. Die UDMP war als Client im normal Netz der FB (192.168.178.x) an der FB angeschlossen. Die UDMP hatte dann eben jene Adresse (192.168.178.x) als WAN erkannt und hat dann ganz normal mit 192.168.1.x weiter gearbeitet.

Heute liegt am WAN der UDMP natürlich direkt meine öffentliche IP an, welche auch innerhalb der UDMP als WAN erkannt wird. Der Rest ist gleich.

Güße!

 

[tq1199]

Das dyndns funktioniert einwandfrei. Ich kann ja von außerhalb meines Netzwerks ...

Kann der UDMP NAT-Loopback (Hairpinning) bzw. kannst Du evtl. im UDMP dns-rebind-Schutz konfigurieren oder ist das dort per default so eingestellt?

 

[Captn]

Hallo tq,

hmm, da bin ich nicht so tief drin um das zu beantworten.

Habe aber auf die Schnelle einen tcpdump Versuche gemacht.
Versuchsaufbau:
1a. Erreichen meines Webservers aus meinem Heimnetz mit meinem PC (mit gleicher externer IP)
1b. Erreichen meines Webservers aus meinem Heimnetz mit meinem Smartphone (mit gleicher externer IP)
2. Erreichen meines Webservers über einen VPN (mit anderer externer IP)

zu 1a:
Keine Verbindung möglich. Kein Hinweis im tcpdump auf eine erfolgte Kommunikation

zu 1b:
Verbindung möglich. Kein Hinweis im tcpdump auf eine erfolgte Kommunikation

zu 2:
Verbindung möglich. Verbindung wird im tcpdump angezeigt

Grüße!

 

[tq1199]

1a. Erreichen meines Webservers aus meinem Heimnetz mit meinem PC (mit gleicher externer IP)
1b. Erreichen meines Webservers aus meinem Heimnetz mit meinem Smartphone (mit gleicher externer IP)
zu 1a:
Keine Verbindung möglich. Kein Hinweis im tcpdump auf eine erfolgte Kommunikation
zu 1b:
Verbindung möglich. Kein Hinweis im tcpdump auf eine erfolgte Kommunikation

Das kann fast nicht sein, denn 1a und 1b sind identisch.
Wo hast Du den tcpdump gestartet und wie (welchen Filter)?
Poste mal die Zeile mit tcpdump.

 

[Captn]

Das kann fast nicht sein, denn 1a und 1b sind identisch.
Wo hast Du den tcpdump gestartet und wie (welchen Filter)?
Poste mal die Zeile mit tcpdump.

Genau das denke ich ja auch. Es ist sehr komisch.


tcpdump -n -i eth8 tcp port 443

Direkt per SSH in der UDMP

 

[tq1199]

tcpdump -n -i eth8 tcp port 443

Direkt per SSH in der UDMP

Dann wird m. E. "eth8" das Interface sein, über das nur das VPN geht. Für den Zugriff ohne VPN, wird in der UDMP evtl. ein anderes Interface zuständig sein.
Evtl. den Filter von tcpdump optimieren, mit z. B.:

tcpdump -c 50 -vvveni any dst host <IP-Adresse-Webserver> and tcp port 443

Welches OS hast Du auf deinem Webserver? Kannst Du nicht auf dem Webserver, tcpdump starten.

 

[Captn]

Dann wird m. E. "eth8" das Interface sein, über das nur das VPN geht. Für den Zugriff ohne VPN, wird in der UDMP evtl. ein anderes Interface zuständig sein.
Evtl. den Filter von tcpdump optimieren, mit z. B.:

tcpdump -c 50 -vvveni any dst host <IP-Adresse-Webserver> and tcp port 443

Welches OS hast Du auf deinem Webserver? Kannst Du nicht auf dem Webserver, tcpdump starten.

Gute Idee!
Habe mich per SSH auf die Synology geschaltet und dort den tcpdump generiert.
Ergbnis ist ziemlich überaschend. Wie zuvor habe ich im Browser einfach meine Domain aufgerufen und mitgeschnitten.

1. Erreichen meines Webservers aus meinem Heimnetz mit meinem Smartphone (mit gleicher externer IP)
2. Erreichen meines Webservers über einen VPN (mit anderer externer IP)

zu 1: Webserver wird direkt über das Intranet Gateway angesprochen 192.168.10.1 (VLAN 10, auf denen alle Geräte hängen)

zu 2: Webserver wird von entsprechend externer IP angesprochen, so wie es sein sollte.


Wie also kommt die Route zustande, wenn ich meine URL per Smartphone aus meinem Heimnetz öffne? Ich habe nirgends eine solche Route hinterlegt.
Wer also sorgt dafür, dass die Verbindung "Smartphone <=> Webserver" über das Intranet geht, obwohl ich eine URL aufrufe? Und warum funktioniert das nicht auch mit anderen Geräten im gleichen Subnetz?

 

[tq1199]

1. Erreichen meines Webservers aus meinem Heimnetz mit meinem Smartphone (mit gleicher externer IP)
2. Erreichen meines Webservers über einen VPN (mit anderer externer IP)

zu 1: Webserver wird direkt über das Intranet Gateway angesprochen 192.168.10.1 (VLAN 10, auf denen alle Geräte hängen)

zu 2: Webserver wird von entsprechend externer IP angesprochen, so wie es sein sollte.

Aus deinem Beitrag verstehe ich nur Bahnhof. Kannst Du mal das VPN weglassen (denn das haben wir schon verstanden) und nur mit deinem PC und Smartphone (aus deinem W/LAN) testen und hier genau berichten bzw. posten.

BTW: Hast Du in deinem Smartphone auch sichergestellt, dass dieses _nur_ in deinem W/LAN ist und dort auch bleibt?

 

[Bigdog71]

Kann der UDMP NAT-Loopback (Hairpinning) bzw. kannst Du evtl. im UDMP dns-rebind-Schutz konfigurieren oder ist das dort per default so eingestellt?

Das wird es sein. Ich habe auch rumgespielt mit vom internen Netzwerk nach draußen und das Block die UDM(P).

Da @Captn ja einen Pihole hat, trage doch da die lokale IP für die Domain ein und gut.

Ich habe ein ähnliches Setup (nur noch mit unbound als Resolver dahinter) und löse interne Server dort auf.

Es macht ja auch gar kein Sinn von innen nach außen und wieder zurück. Da muss das Gateway ja über den WAN Port an sich selbst Routen.

Ich habe etwas gebraucht um es zu verstehen.

Wahrscheinlich hat es mit Fritzbox und Doppel NAT funktioniert bei der UDMP da die externe IP bei der Fritzbox lag und wenn du da die UDMP als exposed Host eingetragen hat, greift der Rebind Schutz der Fritzbox wahrscheinlich nicht.

 

[Captn]

Aus deinem Beitrag verstehe ich nur Bahnhof. Kannst Du mal das VPN weglassen (denn das haben wir schon verstanden) und nur mit deinem PC und Smartphone (aus deinem W/LAN) testen und hier genau berichten bzw. posten.

BTW: Hast Du in deinem Smartphone auch sichergestellt, dass dieses _nur_ in deinem W/LAN ist und dort auch bleibt?

Das VPN dient lediglich dazu, mir eine andere externe IP zu vergeben und zu schauen, ob es von außen möglich ist. Es ist nicht mein eigener VPN Zugang! Wie sonst soll ich meinem PC eine andere öffentliche IP geben um das zu prüfen.
Wie bereits beschrieben, komme ich von meinem PC, aus meinem Heimnetz, nicht auf meinen Webserver. Es wird überhaupt nichts vermittelt. Wenn ich meinem PC eine andere öffentliche IP vergebe, dann funktioniert es.
Mit meinem Smartphone gelange ich aber auf den Webserver, was aber nicht über WAN geschieht, sonder direkt über LAN, obwohl ich eine URL aufrufe.

Ja, mein Smartphone ist nur über WLAN verbunden, was auch mit ifconfig betätigt wird.

 

[Captn]

Das wird es sein. Ich habe auch rumgespielt mit vom internen Netzwerk nach draußen und das Block die UDM(P).

Da @Captn ja einen Pihole hat, trage doch da die lokale IP für die Domain ein und gut.

Ich habe ein ähnliches Setup (nur noch mit unbound als Resolver dahinter) und löse interne Server dort auf.

Es macht ja auch gar kein Sinn von innen nach außen und wieder zurück. Da muss das Gateway ja über den WAN Port an sich selbst Routen.

Ich habe etwas gebraucht um es zu verstehen.

Wahrscheinlich hat es mit Fritzbox und Doppel NAT funktioniert bei der UDMP da die externe IP bei der Fritzbox lag und wenn du da die UDMP als exposed Host eingetragen hat, greift der Rebind Schutz der Fritzbox wahrscheinlich nicht.

Hi Bigdog,

unbound hatte ich auch anfangs laufen, bis er den Geist aufgegeben hat. Seitdem löse ich wieder über Cloudflare auf.
Sicherlich ergibt es wenig Sinn zunächst aus dem LAN ins WAN zu gehen, um aus dem WAN dann wieder ins LAN zu gelangen. Aber um zu testen, ob der Webserver läuft, habe ich dies natürich gemacht und dabei mein Problem offenlegen können.

"Da muss das Gateway ja über den WAN Port an sich selbst Routen." - Genau das ist hier der Fall.

"Wahrscheinlich hat es mit Fritzbox und Doppel NAT funktioniert bei der UDMP da die externe IP bei der Fritzbox lag und wenn du da die UDMP als exposed Host eingetragen hat, greift der Rebind Schutz der Fritzbox wahrscheinlich nicht." - Genau so hatte ich es eingerichtet.

Hast du mir vllt ein howto, wie ich das Pihole aufsetzen muss?

Grüße!

 

[Captn]

Aus Wikipedia:

NAT hairpinning, also known as NAT loopback or NAT reflection,[21] is a feature in many consumer routers[22] that permits the access of a service via the public IP address from inside the local network. This eliminates the need for using separate domain name resolution for hosts inside the network than for the public network for a website.[clarification needed]

The following describes an example network:

• Public address: 203.0.113.1. This is the address of the WAN interface on the router.
• Internal address of router: 192.168.1.1
• Address of the server: 192.168.1.2
• Address of a local computer: 192.168.1.100

If a packet is sent to the public address by a computer at 192.168.1.100, the packet would normally be routed to the default gateway (the router), unless an explicit route is set in the computer's routing tables. A router with the NAT loopback feature detects that 203.0.113.1 is the address of its WAN interface, and treats the packet as if coming from that interface. It determines the destination for that packet, based on DNAT (port forwarding) rules for the destination. If the data were sent to port 80 and a DNAT rule exists for port 80 directed to 192.168.1.2, then the host at that address receives the packet.

If no applicable DNAT rule is available, the router drops the packet. An ICMP Destination Unreachable reply may be sent. If any DNAT rules were present, address translation is still in effect; the router still rewrites the source IP address in the packet. The local computer (192.168.1.100) sends the packet as coming from 192.168.1.100, but the server (192.168.1.2) receives it as coming from 203.0.113.1. When the server replies, the process is identical as for an external sender. Thus, two-way communication is possible between hosts inside the LAN network via the public IP address.

Das beschreibt es eigentlich sehr gut.
Ein Portforwarding ist natürlich eingerichtet. Ich weiß derzeit nicht, wie man die UDMP dahingehend bewegt, DNAT zu verwenden um dies zu testen

 

[tq1199]

Mit meinem Smartphone gelange ich aber auf den Webserver, was aber nicht über WAN geschieht, sonder direkt über LAN, obwohl ich eine URL aufrufe.

Ja, mein Smartphone ist nur über WLAN verbunden, was auch mit ifconfig betätigt wird.

Und genau das (... wie bzw. warum es mit dem Smartphone funktioniert und mit dem PC nicht, wenn sich beide im W/LAN der UDMP befinden ) wollen bzw. können wir mit der Ausgabe von tcpdump, sehen.
Warum hast Du ein Problem damit, die Ausgaben von tcpdump hier zu posten. Brauchbar anonymisieren, musst Du nur evtl. angezeigt externe/öffentliche IP-Adressen. Alles andere kannst Du hier zeigen.

EDIT:

Welches OS hast Du auf deinem PC (mit dem es z. Zt. nicht funktioniert)?

Poste mal von deinem Smartphone (wenn dieses nur im WLAN ist) die Namensauflösung für die URL, mit z. B. nslookup (oder gleichwertig).

 

[Captn]

Und genau das (... wie bzw. warum es mit dem Smartphone funktioniert und mit dem PC nicht, wenn sich beide im W/LAN der UDMP befinden ) wollen bzw. können wir mit der Ausgabe von tcpdump, sehen.
Warum hast Du ein Problem damit, die Ausgaben von tcpdump hier zu posten. Brauchbar anonymisieren, musst Du nur evtl. angezeigt externe/öffentliche IP-Adressen. Alles andere kannst Du hier zeigen.

EDIT:

Welches OS hast Du auf deinem PC (mit dem es z. Zt. nicht funktioniert)?

Poste mal von deinem Smartphone (wenn dieses nur im WLAN ist) die Namensauflösung für die URL, mit z. B. nslookup (oder gleichwertig).

Habe dich dann wohl falsch verstanden. Ich habe kein Problem damit meinen tcpdump zu posten, dachte nur, ich hätte es ausreichend beschrieben.

Nachfolgend der tcpdump aus meiner Synology.

1. Verbindung: Smartphone (im Heimnetz) <=> Webserver (URL)

tcpdump -n -i eth0 tcp port 443
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on eth0, link-type EN10MB (Ethernet), capture size 262144 bytes
14:34:45.967503 IP 192.168.10.1.38972 > 192.168.10.5.443: Flags [P.], seq 4153834942:4153835004, ack 356485870, win 1550, options [nop,nop,TS val 31123438 ecr 778670263], length 62
14:34:45.968178 IP 192.168.10.1.38972 > 192.168.10.5.443: Flags [P.], seq 62:108, ack 1, win 1550, options [nop,nop,TS val 31123439 ecr 778670263], length 46
14:34:45.969368 IP 192.168.10.5.443 > 192.168.10.1.38972: Flags [.], ack 108, win 253, options [nop,nop,TS val 778675511 ecr 31123438], length 0
14:34:45.969491 IP 192.168.10.5.443 > 192.168.10.1.38972: Flags [P.], seq 1:47, ack 108, win 253, options [nop,nop,TS val 778675511 ecr 31123438], length 46
14:34:45.969652 IP 192.168.10.5.443 > 192.168.10.1.38972: Flags [P.], seq 47:407, ack 108, win 253, options [nop,nop,TS val 778675511 ecr 31123438], length 360
14:34:45.969818 IP 192.168.10.5.443 > 192.168.10.1.38972: Flags [P.], seq 407:445, ack 108, win 253, options [nop,nop,TS val 778675511 ecr 31123438], length 38
14:34:45.971094 IP 192.168.10.1.38972 > 192.168.10.5.443: Flags [.], ack 407, win 1595, options [nop,nop,TS val 31123440 ecr 778675511], length 0
14:34:46.011257 IP 192.168.10.1.38972 > 192.168.10.5.443: Flags [.], ack 445, win 1595, options [nop,nop,TS val 31123450 ecr 778675511], length 0

2. Verbindung: Smartphone (mobile Daten) <=> Webserver (URL)

tcpdump -n -i eth0 tcp port 443
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on eth0, link-type EN10MB (Ethernet), capture size 262144 bytes
14:39:07.459386 IP 46.114.151.193.22432 > 192.168.10.5.443: Flags [S], seq 4218825308, win 65535, options [mss 1360,sackOK,TS val 31188803 ecr 0,nop,wscale 6], length 0
14:39:07.459481 IP 192.168.10.5.443 > 46.114.151.193.22432: Flags [S.], seq 505764000, ack 4218825309, win 5844, options [mss 1960,sackOK,TS val 778740883 ecr 31188803,nop,wscale 5], length 0
14:39:07.531191 IP 46.114.151.193.22432 > 192.168.10.5.443: Flags [.], ack 1, win 1369, options [nop,nop,TS val 31188817 ecr 778740883], length 0
14:39:07.532152 IP 46.114.151.193.22432 > 192.168.10.5.443: Flags [P.], seq 1:518, ack 1, win 1369, options [nop,nop,TS val 31188818 ecr 778740883], length 517
14:39:07.532201 IP 192.168.10.5.443 > 46.114.151.193.22432: Flags [.], ack 518, win 217, options [nop,nop,TS val 778740902 ecr 31188818], length 0
14:39:07.532865 IP 192.168.10.5.443 > 46.114.151.193.22432: Flags [P.], seq 1:147, ack 518, win 217, options [nop,nop,TS val 778740902 ecr 31188818], length 146
14:39:07.597466 IP 46.114.151.193.22432 > 192.168.10.5.443: Flags [.], ack 147, win 1386, options [nop,nop,TS val 31188837 ecr 778740902], length 0
14:39:07.614050 IP 46.114.151.193.22432 > 192.168.10.5.443: Flags [P.], seq 518:569, ack 147, win 1386, options [nop,nop,TS val 31188837 ecr 778740902], length 51
14:39:07.614107 IP 46.114.151.193.22432 > 192.168.10.5.443: Flags [P.], seq 569:668, ack 147, win 1386, options [nop,nop,TS val 31188837 ecr 778740902], length 99
14:39:07.614172 IP 192.168.10.5.443 > 46.114.151.193.22432: Flags [.], ack 668, win 217, options [nop,nop,TS val 778740922 ecr 31188837], length 0
14:39:07.614190 IP 46.114.151.193.22432 > 192.168.10.5.443: Flags [P.], seq 668:1243, ack 147, win 1386, options [nop,nop,TS val 31188838 ecr 778740902], length 575
14:39:07.614966 IP 192.168.10.5.443 > 46.114.151.193.22432: Flags [P.], seq 147:225, ack 1243, win 253, options [nop,nop,TS val 778740922 ecr 31188838], length 78
14:39:07.616351 IP 192.168.10.5.443 > 46.114.151.193.22432: Flags [P.], seq 225:586, ack 1243, win 253, options [nop,nop,TS val 778740923 ecr 31188838], length 361
14:39:07.616486 IP 192.168.10.5.443 > 46.114.151.193.22432: Flags [P.], seq 586:624, ack 1243, win 253, options [nop,nop,TS val 778740923 ecr 31188838], length 38
14:39:07.676324 IP 46.114.151.193.22432 > 192.168.10.5.443: Flags [.], ack 624, win 1403, options [nop,nop,TS val 31188857 ecr 778740922], length 0
14:39:07.684752 IP 46.114.151.193.22432 > 192.168.10.5.443: Flags [P.], seq 1243:1281, ack 624, win 1403, options [nop,nop,TS val 31188859 ecr 778740922], length 38
14:39:07.723967 IP 192.168.10.5.443 > 46.114.151.193.22432: Flags [.], ack 1281, win 253, options [nop,nop,TS val 778740950 ecr 31188859], length 0

3. Verbindung: PC (öffentliche IP, nicht meine eigene) <=> Webserver (URL)

tcpdump -n -i eth0 tcp port 443
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on eth0, link-type EN10MB (Ethernet), capture size 262144 bytes
14:40:48.277670 IP 154.28.188.47.50431 > 192.168.10.5.443: Flags [S], seq 1500593980, win 65520, options [mss 1260,nop,wscale 8,nop,nop,sackOK], length 0
14:40:48.277749 IP 192.168.10.5.443 > 154.28.188.47.50431: Flags [S.], seq 2082588823, ack 1500593981, win 5880, options [mss 1960,nop,nop,sackOK,nop,wscale 5], length 0
14:40:48.304225 IP 154.28.188.47.50431 > 192.168.10.5.443: Flags [.], ack 1, win 1028, length 0
14:40:48.310913 IP 154.28.188.47.50431 > 192.168.10.5.443: Flags [P.], seq 1:518, ack 1, win 1028, length 517
14:40:48.310946 IP 192.168.10.5.443 > 154.28.188.47.50431: Flags [.], ack 518, win 218, length 0
14:40:48.363396 IP 192.168.10.5.443 > 154.28.188.47.50431: Flags [.], seq 1:3781, ack 518, win 218, length 3780
14:40:48.405091 IP 154.28.188.47.50431 > 192.168.10.5.443: Flags [.], ack 2521, win 1028, length 0
14:40:48.405154 IP 192.168.10.5.443 > 154.28.188.47.50431: Flags [P.], seq 3781:4480, ack 518, win 218, length 699
14:40:48.431283 IP 154.28.188.47.50431 > 192.168.10.5.443: Flags [.], ack 4480, win 1028, length 0
14:40:48.439888 IP 154.28.188.47.50431 > 192.168.10.5.443: Flags [P.], seq 518:644, ack 4480, win 1028, length 126
14:40:48.440030 IP 192.168.10.5.443 > 154.28.188.47.50431: Flags [.], ack 644, win 218, length 0
14:40:48.449355 IP 192.168.10.5.443 > 154.28.188.47.50431: Flags [P.], seq 4480:4531, ack 644, win 218, length 51
14:40:48.449562 IP 192.168.10.5.443 > 154.28.188.47.50431: Flags [P.], seq 4531:4600, ack 644, win 218, length 69
14:40:48.482165 IP 154.28.188.47.50431 > 192.168.10.5.443: Flags [P.], seq 644:821, ack 4531, win 1028, length 177
14:40:48.482356 IP 192.168.10.5.443 > 154.28.188.47.50431: Flags [P.], seq 4600:4638, ack 821, win 251, length 38
14:40:48.488996 IP 154.28.188.47.50431 > 192.168.10.5.443: Flags [P.], seq 821:1224, ack 4531, win 1028, length 403
14:40:48.490737 IP 192.168.10.5.443 > 154.28.188.47.50431: Flags [P.], seq 4638:4999, ack 1224, win 285, length 361
14:40:48.490950 IP 192.168.10.5.443 > 154.28.188.47.50431: Flags [P.], seq 4999:5037, ack 1224, win 285, length 38
14:40:48.495671 IP 154.28.188.47.50431 > 192.168.10.5.443: Flags [P.], seq 1224:1262, ack 4600, win 1028, length 38
14:40:48.526957 IP 154.28.188.47.50431 > 192.168.10.5.443: Flags [.], ack 4999, win 1026, length 0
14:40:48.527012 IP 192.168.10.5.443 > 154.28.188.47.50431: Flags [.], ack 1262, win 285, length 0
14:40:48.579411 IP 154.28.188.47.50431 > 192.168.10.5.443: Flags [.], ack 5037, win 1026, length 0

Eine Verbindung von meinem PC mit meiner eigenen öffentlichen IP zu meinem Webserver wird nicht aufgebaut, daher kein tcpdump.

Ich nutze Win10 auf meinem PC

Die Namensauflösung über nslookup meiner Webserver-URL von meinem Smartphone über WLAN gibt meine öffentlichen IP Adressen (IPv4+IPv6) wieder.

Grüße!

EDIT: nslookup auf meinem PC gibt exakt die gleiche Info wieder, wie von meinem Smartphone

 

[tq1199]

Eine Verbindung von meinem PC zu meinem Webserver wird nicht aufgebaut, daher kein tcpdump.

Sagt wer? tcpdump oder deine Beobachtung?

Wie ist dein PC (mit WIN 10) mit dem Router verbunden, per Kabel oder per WLAN? Welche interne IPv4-Adresse im Subnetz des Routers, hat dein PC? Welche interne IPv4-Adresse hat dein Router?
Poste mal von deinem PC (Win 10) aus der power-shell, die Ausgaben von:

arp -a
ping 192.168.10.5

Funktioniert auf deinem PC die Namensauflösung für die Webserver-URL auch so, wie auf dem Smartphone?

EDIT:

Es könnte auch sein, dass die VPN-Software die Du auf deinem PC (mit Win10) benutzt, den Zugriff aus dem W/LAN via URL, verhindert bzw. nicht ermöglicht. Und das auch dann, wenn die VPN-Verbindung gerade nicht aktiv ist. Wenn Du es genau wissen willst, müsstest Du diese VPN-Software (VPN-Client?) deinstallieren.
Oder Du schaust dir das Routing (mit und ohne VPN) in der power-shell von Win10 an.
BTW: Benutzt die VPN-Software auf deinem Win10, irgendwelche Firewall-Einstellungen? Hast Du die Möglichkeit mit deinem PC, eine Linux-Live-CD/DVD (oder einen USB-Linux-Live-Stick) zu benutzen?

 

[Captn]

Sagt wer? tcpdump oder deine Beobachtung?

Wie ist dein PC (mit WIN 10) mit dem Router verbunden, per Kabel oder per WLAN? Welche interne IPv4-Adresse im Subnetz des Routers, hat dein PC? Welche interne IPv4-Adresse hat dein Router?
Poste mal von deinem PC (Win 10) aus der power-shell, die Ausgaben von:

arp -a
ping 192.168.10.5

Funktioniert auf deinem PC die Namensauflösung für die Webserver-URL auch so, wie auf dem Smartphone?

Hi,

sagt der tcpdump
nslookup auf meinem PC gibt exakt die gleiche Info wieder, wie von meinem Smartphone

PC ist mit Kabel verbunden und hat die IP 192.168.10.50.
Das Smartphone hat die IP 192.168.10.15.
Der Webserver hat die IP 192.168.10.5

Hier der arp request:

arp -a
>> ping 192.168.10.5
Schnittstelle: 192.168.10.50 --- 0xd Internetadresse Physische Adresse Typ 192.168.10.1 xx-xx-xx-xx-xx-xx dynamisch 192.168.10.5 xx-xx-xx-xx-xx-xx dynamisch 192.168.10.20 xx-xx-xx-xx-xx-xx dynamisch 192.168.10.30 xx-xx-xx-xx-xx-xx dynamisch 192.168.10.255 ff-ff-ff-ff-ff-ff statisch 224.0.0.2 01-00-5e-00-00-02 statisch 224.0.0.22 01-00-5e-00-00-16 statisch 224.0.0.251 01-00-5e-00-00-fb statisch 224.0.0.252 01-00-5e-00-00-fc statisch 239.255.255.250 01-00-5e-7f-ff-fa statisch 255.255.255.255 ff-ff-ff-ff-ff-ff statisch
Schnittstelle: 169.254.147.185 --- 0xf Internetadresse Physische Adresse Typ 169.254.255.255 ff-ff-ff-ff-ff-ff statisch 224.0.0.2 01-00-5e-00-00-02 statisch 224.0.0.22 01-00-5e-00-00-16 statisch 224.0.0.251 01-00-5e-00-00-fb statisch 224.0.0.252 01-00-5e-00-00-fc statisch 239.255.255.250 01-00-5e-7f-ff-fa statisch
Schnittstelle: 169.254.33.215 --- 0x10 Internetadresse Physische Adresse Typ 169.254.255.255 ff-ff-ff-ff-ff-ff statisch 224.0.0.2 01-00-5e-00-00-02 statisch 224.0.0.22 01-00-5e-00-00-16 statisch 224.0.0.251 01-00-5e-00-00-fb statisch 224.0.0.252 01-00-5e-00-00-fc statisch 239.255.255.250 01-00-5e-7f-ff-fa statisch
Schnittstelle: 169.254.123.222 --- 0x13 Internetadresse Physische Adresse Typ 10.10.4.1 00-ff-ee-e7-9c-fa dynamisch 169.254.255.255 ff-ff-ff-ff-ff-ff statisch 224.0.0.2 01-00-5e-00-00-02 statisch 224.0.0.22 01-00-5e-00-00-16 statisch 224.0.0.251 01-00-5e-00-00-fb statisch 224.0.0.252 01-00-5e-00-00-fc statisch 239.255.255.250 01-00-5e-7f-ff-fa statisch
Ping wird ausgeführt für 192.168.10.5 mit 32 Bytes Daten:
Antwort von 192.168.10.5: Bytes=32 Zeit<1ms TTL=64
Antwort von 192.168.10.5: Bytes=32 Zeit<1ms TTL=64
Antwort von 192.168.10.5: Bytes=32 Zeit<1ms TTL=64
Antwort von 192.168.10.5: Bytes=32 Zeit<1ms TTL=64
Ping-Statistik für 192.168.10.5: Pakete: Gesendet = 4, Empfangen = 4, Verloren = 0 (0% Verlust),
Ca. Zeitangaben in Millisek.: Minimum = 0ms, Maximum = 0ms, Mittelwert = 0ms

 

[tq1199]

Das Smartphone hat die IP 192.168.10.15.
Der Webserver hat die IP 192.168.10.5

Ok, d. h. ja, dass dein Router NAT-Loopback kann, denn wenn dein Smartphone die IP .15 hat und dein Webserver beim Zugriff vom Smartphone, aber als source-IP die .1 (IP vom Router?) sieht (wenn die URL-IP benutzt wird), ist das NAT-Loopback:

14:34:45.967503 IP 192.168.10.1.38972 > 192.168.10.5.443: Flags [P.], seq

Wegen deinem PC, siehe mein EDIT oben. Es wird m. E. an der VPN-Software (Routinng??) und evtl. auch an irgendwelchen source-NAT/masquerade/Firewall-Regeln im Win10 liegen.

Maßgebend und wichtig/richtig ist es, so wie es z. Zt. mit deinem Smartphone funktioniert (... wenn im WLAN auf dem Smartphone die externe/öffentliche IPv4-Adresse des "border device" (Router) benutzt wird.)

 

[Captn]

Der Code ist etwas unleserlich.
Hier ein Screenshot

 

[Captn]

Ok, d. h. ja, dass dein Router NAT-Loopback kann, denn wenn dein Smartphone die IP .15 hat und dein Webserver beim Zugriff vom Smartphone, aber als source-IP die .1 (IP vom Router?) sieht (wenn die URL-IP benutzt wird), ist das NAT-Loopback:

14:34:45.967503 IP 192.168.10.1.38972 > 192.168.10.5.443: Flags [P.], seq

Wegen deinem PC, siehe mein EDIT oben. Es wird m. E. an der VPN-Software (Routinng??) und evtl. auch an irgendwelchen source-NAT/masquerade/Firewall-Regeln im Win10 liegen.

Maßgebend und wichtig/richtig ist es, so wie es z. Zt. mit deinem Smartphone funktioniert (... wenn im WLAN auf dem Smartphone die externe/öffentliche IPv4-Adresse des "border device" (Router) benutzt wird.)

Wie gesagt. Ich nutze den VPN nur dafür, das ich meinem Heimnetz vorgaukle, dass ich in diesem Moment von außerhalb meines Netzwerks komme. Das ist nur dafür um zu prüfen, wie mein Netzwerk sich verhält, wenn jmd anderes von außen auf meine URL zugreift.
Leider ist dies das einzige Smartphone, womit dies funktioniert. Ich habe es mit anderen probiert, leider ohne erfolg. Auch mit anderen PCs (mit Win10) innerhalb des Netzwerks funktionert es nicht. Keine Ahnung was mein Smartphone so besonders macht ^^

 

[tq1199]

Der Code ist etwas unleserlich.

Ja, ping im W/LAN bei Benutzung der internen IP-Adresse funktioniert.

Wenn Du das was z. Zt. nicht geht, reproduzieren willst, dann installiere z. B. nmap auf deinem Win10 und mach einen Portscan auf die externe IPv4-Adresse des Routers und den TCP-Port 443, bei aktivem tcpdump auf deinem Webserver.

 

[tq1199]

Keine Ahnung was mein Smartphone so besonders macht ^^

Du könntest ja mit einem anderen Smartphone (mit dem es nicht funktioniert) und tcpdump bzw. nslookup testen.