WebGUI über WAN-Adresse aus dem internen Netz erreichbar

haithabu84

Hallo,

ich habe ein komisches Verhalten in meinem pfSense Setup festgestellt. Leider weiß ich nicht welche Einstellung dies begünstigt.

Es gibt mehrere VLANs und nur aus einigen wenigen, kann ich direkt mit aufruf der IP-Adresse oder dem internen DNS-Namen die WebGui aufrufen. Aus allen anderen, ist das eben nicht möglich. Soweit in Ordnung.

Nun kann ich aber aus den Netzwerken, wo ich nicht will das eine Verbindung zur WebGui möglich ist, über die Eingabe der WAN-Adresse eine Verbindung herstellen. Von extern gibt es aber kein Port-Forwarding oder eine Freigabe, als aus dem Öffentlichen ist die WebGUI nicht erreichbar.

Im Log steht dann die interne IP-Adresse beim erfolgreichen Login. Es muss sich also um eine Art Redirection handeln.

Wie ist das möglich? Welche Einstellung ist dafür verantwortlich?

Gruß

viragomann

@haithabu84
Die spezielle Einstellung kann nur die Firewall-Regel sein, die das erlaubt. Wenn du aus den internen Netzen allen Zugriff auf öffentliche IPs erlaubst und deine WAN IP ist eine solche, dann kann man von da auch auf die WebGUI zugreifen.

Dass ein Rechner auf allen seinen Adressen auf allen Interfaces ansprechbar ist, ist ein ganz normales Verhalten. Aber bei einem Standardgateway kommt der Umstand hinzu, dass alle Netzewerksegmente ihre Anfragen für IPs in anderen Subnetzen dahin schicken.

Um es zu unterbinden musst du eine Blockregel setzen. Am besten eine Floating mit Quick angehakt und "This Firewall" als Ziel und den WebGUI Port auswählen und die Regel für alle Interfaces aktivieren, die nicht auf die pfSense zugreifen sollen.
Achte darauf, dass du nicht gleich alles blockst. Z.B., wenn die pfSense DNS macht, wie üblich, darf das nicht geblockt werden.

haithabu84

@viragomann Achso ist das. Dachte das wird schon von Hause aus gemacht. Habe jetzt erstmal eine Floating-Rule mit "This Firewall" als Ziel und Port 443 gemacht. Interfaces dann eben die entsprechenden VLAN-Interfaces. Damit funktioniert es.

Danke

haithabu84

@viragomann Kurze Frage noch zu den Floating-Rules, so oft verwende ich die nicht:

Wie ist die Hirachie bei diesen, stehen die über den Interface-Rules?

Szenario: Man hat in einem VLAN-Interface IPv4* allow any, und macht jetzt eine Floating-Rule mit Block TCP 5100 z.B... Was würde passieren?

viragomann

@haithabu84
Das entscheidet die Quick Option.

Floating-Regeln mit Quick werden als erstes vor den Regeln auf den Interface Tabs überprüft und ggf. angewandt und die weiteren Regeln ignoriert.

Ist Quick nicht angehakt, wird die Floating-Regel nach den Interface-Regeln geprüft. Nur wenn da keine zutrifft, wird sie angewandt.

In deinem Beispiel wäre also der Zugriff erlaubt.

JeGr

@haithabu84 said in WebGUI über WAN-Adresse aus dem internen Netz erreichbar:

Im Log steht dann die interne IP-Adresse beim erfolgreichen Login. Es muss sich also um eine Art Redirection handeln.

Nö. Warum sollte es?
Bitte das Log zeigen, das du meinst und was das besagen soll. Ansonsten steht im Log natürlich immer die interne IP des Clients beim Login, da wird ja nicht die IP des Servers auf dem Server angezeigt.

Wenn es nicht blockiert wird, ist die Sense UI logischerweise immer über die Public IP auch von innen erreichbar, es ist ja eine IP des Geräts, warum sollte sie daher darüber nicht erreichbar sein, egal aus welcher Richtung?

@haithabu84 said in WebGUI über WAN-Adresse aus dem internen Netz erreichbar:

Dachte das wird schon von Hause aus gemacht.

Von Haus aus ist auf dem LAN alles erlaubt. Alles andere ist sonst geblockt. Wenn du auf einem Interface aber eben "allow any" drauf hast wird auch any erlaubt. Daran ist nichts mystisches :)

@viragomann said in WebGUI über WAN-Adresse aus dem internen Netz erreichbar:

@haithabu84
Das entscheidet die Quick Option.

Floating-Regeln mit Quick werden als erstes vor den Regeln auf den Interface Tabs überprüft und ggf. angewandt und die weiteren Regeln ignoriert.

Ist Quick nicht angehakt, wird die Floating-Regel nach den Interface-Regeln geprüft. Nur wenn da keine zutrifft, wird sie angewandt.

In deinem Beispiel wäre also der Zugriff erlaubt.

Da ist dann der größte Haken an Regeln auf Floating. Darum empfehle ich diese auch nicht, weil es zu viele Logikprobleme für viele bringt, denn jetzt kommen Abhängigkeiten über Abhängigkeiten. Die Aussage stimmt nicht ganz, die @viragomann hier bringt. Die korrekte Reihenfolge ist abhängig von zwei Dingen, das ist richtig:

Floating, Gruppeninterface oder Einzelinterface
Quick-Setting in der Regel

Jede Regel auf Einzelinterfaces oder Gruppeninterfaces (auch IPsec, OpenVPN und Wireguard sind Gruppen!) haben implizit immer das Setting "quick" in pf gesetzt. Gelten also immer sofort.

Somit hat man im normalen Regelfluss ein Top-Down Verhalten: der erste der passt, gewinnt! Das wären dann Regeln auf Floating, dann Gruppen und dann Interface Regeln. OK.
Quick führt aber nicht dazu, dass die Regel aus Floating später geprüft wird, sondern dass sie nicht sofort greift! Eine Regel in PF bei der KEIN quick gesetzt wurde ist quasi eine "Merkregel". Heißt: es wird dieser Zustand angenommen, die Regelverarbeitung geht aber weiter! Wenn dann etwas anderes bis zum Schluß noch mit Quick matcht, wird dies sofort angewendet und gewinnt. Treffen wir aber auf weitere Regeln die nicht quick sind, dann kann es sein, dass ein Paket mehrfach erlaubt, geblockt, rejected, erlaubt, geblockt und wieder erlaubt als Status vermerkt bis endlich alle Regeln durch sind. Und dann gewinnt - wenn vorher keine quick Regel mehr auslöst - der letzte Zustand. Also haben wir plötzlich eine last-matching-rule wins Situation statt umgekehrt - außer zwischendrin grätscht uns was aus der Ecke mit "quick" dazwischen.

Klingt komplex? Genau deshalb empfehlen wir nicht mit Floating und non-quick Rules zu arbeiten, denn meistens wird das ganze ein großer gordischer Knoten und keiner blickt am Ende mehr konkret durch, was jetzt eigentlich gilt und was nicht.

Die pfSense Default Rule - block log any - ist genau deshalb eine Regel die vor allen anderen (quasi als erste Floating Regel) definiert ist. Es soll erstmal alles geblockt und geloggt werden ... alles was nicht später definiert ist. Darum kein quick, da wir hier das Standard Verhalten definieren. Alles danach macht die Regelabarbeitung sehr ... nennen wir es spannend

Darum: bitte macht nach Möglichkeit keine non-quick-rules wenn ihr nicht genau wisst, was ihr da tut, sonst könnt ihr euch ggf. euer ganzes Regelwerk aushöhlen ohne es zu merken (gerade bei Kunden für Sie entdeckt!)

Cheers
\jens

NOCling

Ja ich würde zu Int Gruppen raten.
Eine in der alle Ints drin sind und die definieren was hier wie bezüglich pfSense Host Zugriffen drin ist.
Bei mir tcp-udp/53,tcp-udp/853,udp/123.
Dann deny any this Firewall und fertig ist.

Floatings arbeiten mit dem any match Prinzip, ist hier also irgendwo was erlaubt, greift das.
Damit kann man geile Sachen machen, wenn man ganz genau weiß was man tut.
Limiter hier mit match rein und alles super.

JeGr

@nocling said in WebGUI über WAN-Adresse aus dem internen Netz erreichbar:

Eine in der alle Ints drin sind und die definieren was hier wie bezüglich pfSense Host Zugriffen drin ist.

Vorsicht nur davor, WANs in Gruppen zu packen. DON'T! Interne Netze - klar.