Server im internen Netz nur von Extern erreichbar

Das liegt daran, dass der Router erkennt, dass eigentlich eine interne IP anfragt wird. Insofern kommt die Anfrage aus dem Heimnetz und soll ins Webserver-Netz.

Du musst also Zugriff aus dem Heimnetz in das Webserver-Netz erlauben (aber nicht umgekehrt).

Flensgold

Zusätzlich würde ich den DDNS Namen noch mit der internen IP des dazugehörigen Webservers als A Eintrag in das DNS eintragen, dann versucht dein Client nicht mal mehr den Zugriff über die öffentliche IP. Denn auch mit Freigabe von deinem Netz zum Servernetz (kannst auch nur die Ports in der Firewall erlauben die benötigt werden) wird sehr wahrscheinlich kein Zugriff über DDNS host auf die WAN IP aufgelöst klappen, denn die Unifi Gateway machen kein Loopback NAT Zeugs, zumindest war das bisher so.

Noch was zum nachdenken.... Warum darf man aus deinem LAN nicht auf die Server zugreifen, während der Rest der Welt das darf?

Zitat von DoPe

Zusätzlich würde ich den DDNS Namen noch mit der internen IP des dazugehörigen Webservers als A Eintrag in das DNS eintragen, dann versucht dein Client nicht mal mehr den Zugriff über die öffentliche IP

Das kann man mitlerweile über das UI der Netzwork Application, in den Einstellungen des Clients (Webserver) machen, Feld "Local DNS Record". Voraussetzung ist natürlich, dass der Unifi Router als DNS fungiert und propagiert wird.

Zitat von maxim.webster

Das kann man mitlerweile über das UI der Netzwork Application, in den Einstellungen des Clients (Webserver) machen, Feld "Local DNS Record". Voraussetzung ist natürlich, dass der Unifi Router als DNS fungiert und propagiert wird.

Darum hab ich es allgemein gehalten. Wenn ein anderes Gerät DNS spielt, dann muss es halt dort rein. Und als A Record im DNS geht immer, auch wenn man dem Client im Unifi keine fixed IP zuweisen möchte.

Flensgold

Ich mach das immer über die Erweiterte Variante, da man die flags new, related, established braucht. Ich gehe mal davon aus das da der Rückweg nicht geht. Weiß nicht ob bei Traffic Richtung sowas wie beide auswählbar ist.

Bei erweitert würde man sagen können das Default LAN zu Webserver Pakete mit new erlaubt. Zusätzlich dass alle an alle Pakete mit related und established schicken können (für die Antwort). Dann kann der Webserver keine Verbindung ins Default LAN starten aber Antworten. Aus dem Defaul LAN kann man die Verbindung zum Webserver starten.

LAN_IN musst Du nehmen. Lokal ist für die Schnittstellen der UDM selbst.

Wieso kommst Du "immer noch" auf den Server? Dachte das geht nicht und das soll hier das Ziel sein? Mach mal bitte einen Screen von der Firewall Regelliste LAN_IN

Flensgold

Also prinzipiell mal zur Arbeitsweise der Firewall. Um zu bewerten was mit einem Paket passiert, wird das Paket mit den Regeln von oben nach unten verglichen. Stimmt das Paket mit einer Regel überein, dann wird das Paket entsprechend verarbeitet OHNE die nachfolgenden Regeln zu berücksichtigen.

Bedeutet schon mal das die Regel "blockiert die gesamte Kommunikation zwischen VLANs" dazu führt, dass die beiden nachfolgenden Regeln nie zum Zug kommen wenn es um private IP Adressen geht.

Wichtig sind auch die flags in den Regeln. Also sortieren und kontrollieren.

- In der "erlaube etablierte .... Sitzungen" muss dort established und related und zwar nur diese beiden angehakt sein und Position 1 ist ok.

- In "alle ungültigen Zustände löschen" darf nur illegal angehakt werden und die schiebe ich immer auf Position 2

- Bei allen anderen Regeln sollte nur das flag New angehakt werden. Da es nur um den Aufbau einer neuen Verbindung geht. bestehende bzw. das Antworten darauf ist ja in der ersten Regel erledigt. Die Reihenfolge ist hier relativ unwichtig. Wenn es möglich ist das eine Regel besonders oft zutreffen wird, dann diese weiter hoch um nicht erst die weniger auftretenden Regeln zu vergleichen. Aber wie gesagt meist nicht so wichtig. Das ist eher so ein Performanceding bei sehr sehr vielen Regeln.

- "blockiert die gesamte Kommunikation zwischen VLANs" als letztes in der Reihenfolge Hier darf alles (oder gleichzusetzen mit nichts) angehakt sein. Alles was spezialisierter ist sollte vorher schon "abgebogen" sein

Schaue bitte alle flags durch, die Nextcloud Regel wäre zwar nicht zum zug gekommen, aber da der Webserver eine private IP sein dürfte, hätte bereits im Bild die Regel 3 die Erlaubnis für das Paket geben sollen. Die Nextcloud würde auch über der Block Regel nicht greifen weil die 3. Regel bereits Quelle und Ziel (hier halt nicht konkret sondern allgemeiner) enthält.

Warum braucht es überhaupt eine dedizierte Regel für den Nextcloud-Service, wenn sowohl das Mgmt-LAN, als auch das Default LAN auf alle anderen VLANs zugreifen dürfen?

Hast Du die IP-Gruppe „00 | alle privaten …“ mal geprüft, ob das Webserver Netz da drin ist?

Zitat von maxim.webster

Warum braucht es überhaupt eine dedizierte Regel für den Nextcloud-Service, wenn sowohl das Mgmt-LAN, als auch das Default LAN auf alle anderen VLANs zugreifen dürfen?

Hast Du die IP-Gruppe „00 | alle privaten …“ mal geprüft, ob das Webserver Netz da drin ist?

Theoretisch brauchts die wohl nicht. Ich vermute mal das wie bei den meisten dort die RFC1918 Netze drin sind, wie auf deinem Screen. Dann sollte der Server da schon inkludiert sein.

Bei Firewallregeln helfen ist halt immer etwas schwierig, weil man ja nie alles sieht. Was da in den Profiles angelegt ist und welche flags in den Regeln gesetzt sind kann man leider anhand eines Bildes nicht sehen.