Ich habe folgendes Setup: Öffentliche IP A.B.C.D –> Swisscom Router –> 192.168.2.2 –> 192.168.2.1 –> Firewall/DMZ –> Reverse Proxy –> Microservices. Auf dem Router habe ich Weiterleitungen für die Ports konfiguriert, die ich benötige, z.B. Port 80 / 443, um den gesamten Verkehr, der nach A.B.C.D geht, an 192.168.2.1 weiterzuleiten, was von extern oder von innerhalb der DMZ einwandfrei funktioniert. Ich benutze das WLAN des Swisscom Routers für Gäste im Büro. Wenn ich versuche, auf einen Dienst zuzugreifen, der an A.B.C.D weiterleitet, erhalte ich einen Timeout. Es ist, als ob der Swisscom Router die Port-Weiterleitungen nicht auf den Verkehr anwendet, der vom WLAN kommt. Kann mir jemand helfen, was ich hier einrichten muss?

@Feubireuy41 schrieb: …Ich benutze das WLAN des Swisscom Routers für Gäste im Büro…. das separate Gäste WLAN, das vom Router zur Verfügung gestellt werden kann?

@kaetho Habe es jetzt auch mit dem Seperate WLAN probiert, da besteht das gleiche Problem.

Ja, die Frage zielte darauf ab, dass das mit dem Gast-WLAN nicht geht. Warum es so wie du es beschreibst, nicht funktioniert, kann ich momentan nicht nachvollziehen. Muss bei mir zu Hause mal prüfen, ob ich dieselben Probleme habe. Du hast den nachgeschalteten Router in der DMZ. Und du hast Portweiterleitungen darauf eingerichtet. Ich habe zusätzlich noch eine statische Route auf den nachgeschalteten Router in der DMZ gemacht (macht aus sicherheitstechnischen Überlegungen eigentlich keinen Sinn, aber momentan will ich aus dem IB3-Netz auch auf das nachgeschaltete separate Netz zugreifen können). -> Statische Route einrichten, und dann wieder versuchen?

@Feubireuy41 Wie @kaetho glaube ich Deine Frage hat mit dem Thema WLAN gar nichts zu tun, sondern Du versuchst in einem kaskadierten Netz vom hierarchisch höher stehenden Netz in ein nachgeschaltetes Netz reinzugreifen. Genau das will man ja eigentlich durch eine Routerkaskade verhindern, aber mit einer statischen Route vom höheren Netz ins tiefere Netz kann man es natürlich auch wieder aushebeln. Wenn Du zum Test übrigens ein Gerät nicht via Swisscom-WLAN, sondern direkt an einem LAN-Port des Swisscom-Routers anschliesst, solltest Du übrigens ohne statische Route auch nicht ins kaskadierte Netz reinkommen.

@kaetho Der DMZ/nachgelagerte Router funktioniert einwandfrei, wenn ich z.B. vom Internet her über den Swisscom Router über den nachgelagerten Router auf die Microservices zugreife. Statische Routers habe ich versucht, aber bisher erfolglos. Vielleicht mache ich hier was falsch? Ich habe folgendes probiert: Destination subnet: A.B.C.D Subnet mask: 255.255.255.255 Gateway: 192.168.2.1 und Destination subnet: A.B.C.D Subnet mask: Gateway: 192.168.2.1

@Werner Ich gehe aktuell stark davon aus, dass es etwas mit dem WLAN Routing des Swisscom Routers zu tun hat, denn NUR dann passiert der Fehler. Meine Port Forwardings funktionieren z.B. von extern über den Swisscom Router –> Nachgelagerter Router –> Microservice (z.B. Port 80). Sobald ich mit dem WLAN von Swisscom connecte geht das nicht mehr. Eigentlich müsste der Router die Anfrage für Domains mit der externen Domain A.B.C.D umleiten auf 192.168.2.1, das passiert aber nicht.

Feubireuy41 meine eingerichtete statische Route auf der Internetbox sieht so aus: Die UDMpro (nachgeschalteter Rouer) bezieht per DHCP von der Internetbox die 192.168.1.6

kaetho Hm, bei mir sieht das anders aus.. Ich habe gerade geprüft, dass ich die neuste Version der Firmware installiert habe. Bist du direkt auf dem Router? Oder wo stellst du das ein? Ich habe einen Centro Business 2.0

Und nicht vergessen, nach dem Eintrag der statischen Route jeweils den Router neu starten. @Feubireuy41 Ein gesondertes WLAN-Routing gibt es nicht. Routing passiert immer auf der Netzwerkebene. Sonst mache mal mit dem Swisscom-Router den Testvergleich wischen WLAN-connected und LAN-connected.

Port Forwarding vom WLAN funktioniert nicht

PowerMac

@Feubireuy41 schrieb:

[…] Naja, wenns nicht klappt, wechsle ich halt den Anbieter, da geht sowas immer problemlos.

Naja, in diesem Fall möglicherweise auch nicht. NAT-Loopback, aka Hairpinning, ist im Grunde netzwerktechnischer Murks, und etliche Router unterstützen das nicht. Es gibt auch Ausnahmen, allerdings kann ich dir jetzt grad keine nennen da ich das selber nicht brauche.

Ein eleganter Workaround wäre das Ganze via IPv6 zu lösen, falls das mit dem Centro Business möglich ist.

Tux0ne

Ich denke es ist das fehlende NAT Loopback das der Centro Business so nicht unterstützt.
Das ist eher eine Funktion von Consumer Geräten. Klar könnte man sich überlegen das in Router Modus mal zu implementieren. Kuckst du mal @StefanoC mit Marcel @MarcelNag

kaetho

NAT-Loopback würden die IB’en unterstützen. Oder ein eigener DNS-Server (bei mir pihole). Ob Murks oder nicht, mag ich grad nicht beurteilen.

StefanoC

Hallo @Feubireuy41

Kannst du mir via Privat Nachricht deine Anschlussdaten senden? zb. Router Serie Nummer. Ich werde mir das mal anschauen.

Vielen Dank.

Gruss

StefanoC.

MichelB

Wir haben einen Testbuild 13.90.42 generiert, der folgendes Problem löst:

Netzinterne Requests auf public IPs funktionieren nicht mehr

Download

Dieser Testbuild sollte das Problem in diesem Thread lösen.

Beste Grüsse und danke für ein Feedback

« Vorherige Seite