Protectli FW4C - Netzwerkumbau Teil2

[blurrrr]

Hm, dachte es sollte "einfach" und - wenn möglich - alles beim alten bleiben?

Hinter die Firewall klemmen, WAN auf 192.168.x.2/24 konfigurieren (statisch, Gateway 192.168.x.1), LAN auf "192.168.1.1/24" konfigurieren, DHCP-Reservierungen eintragen und DHCP einschalten, alles aus dem Router raus, hinter die Firewall (damit wäre der Netz-"1"-Zustand erstmal wieder der alte), nochmal kurz an den Router klemmen (IP sollte es ja noch via DHCP geben), Router-LAN auf 192.168.x.1 konfigurieren (somit erreicht die Firewall auch wieder ihr Gateway). Wieder hinter die Firewall klemmen und über die Firewall auf den Router zugreifen und dort DHCP abschalten (oder einfach anlassen, solange die DHCP-Range nicht bei 1."2" anfängt).

Halt in diese Richtung: Internet |R| 192.168.x.1 <-> 192.168.x.2 |FW| 192.168.1.1

 

[Fidibus]

Hm, dachte es sollte "einfach" und - wenn möglich - alles beim alten bleiben?

Das hab ich auch gewollt. Aber irgendwie habe ich mir immer Probleme reingebaut.
Das Umschubsen der Geräte wird nun auch nicht sooo viel Aufwand machen, zumal ich nun schon alles vorbereitet ahbe.
Allerdings hat zumindest vorhin da 2. LAN-Segment an OPT1 nicht wirklich die gewünschten Ziele erreicht hat und im Log erst mal gar nicht wirklich was Hilfreiches drin stand.

 

[the other]

Moinsen,
im default Modus (also frisch ausgepackt) besteht für das LAN IF die allow any any Regel und die Hintertür auf die GUI (anti-lockout-rule).
Für die weiteren Interfaces (LAN2, opt) besteht dagegen die (für eine firewall absolut korrekte) DENY any any Regel.
Das bedeutet: ohne dass du explizit etwas erlaubst ist sonst eben ALLES verboten. Daher wundert es mich nicht, dass aus opt1 heraus nichts funktioniert hat.
Das muss dann mit Regeln gemacht werden (wofür die pfsense ja EIGENTLICH auch da ist).
Zum Anfangen (und ausprobieren) kannst du ja einfach eine passende Allow any any Regel reinzimmern...(aber später dann eben anpassen, sonst kann ja gleich alles in EIN einziges Netzwerksegment ohne Unterscheidung in LAN und opt1.)

 

[Fidibus]

Moin,
Frustration macht sich breit. Nachdem ich gestern kein Testgerät hatte, wollte ich heute auf dem Stand aufsetzen und die nächsten Schritte machen.
Aktuell hatte ich das Netz so verlassen, Problem war, dass Opt1 nicht raus kam:

Heute will ich nun weitermachen und starte, so wie verlassen.
Allerdings bekomme ich zwar (lokalen, aus dem Heimnetz neu) Zugriff auf pfsense, nur der Weg ins Internet ist versperrt.
Scheinbar ein DNS-Thema, da habe ich echt noch gar nichts angefasst.

 

[blurrrr]

Immer erstmal die "grundlegenden" Dinge testen, dazu gehört in allererster Linie das Routing (ohne DNS). Das kannst Du am einfachsten via Traceroute testen (z.B. "tracert 8.8.8.8" in der Windows-Eingabeaufforderung). Wenn das funktioniert ist schon mal gut, danach kannst Du Dich um die (im OSI-Modell) höher gelagerten Dinge kümmern, wie z.B. DNS. Firewalls haben normalerweise eine Einstellungen, wo konfiguriert werden kann, auf welchen Interfaces der DNS-Resolver überhaupt auf DNS-Anfragen lauscht (dazu kommen ggf. noch die Firewall-Regeln, wer überhaupt anfragen darf, aber das ist nochmal ein anderes Thema).

 

[Fidibus]

Moin.
da es ja vor 2 Tagen geklappt hat, hab ich mir da keine weiteren Gedanken drum gemacht.

"tracert 8.8.8.8

 

[Fidibus]

das Routing

 

[blurrrr]

Würde mal behaupten, dass da irgendwas kräftig schief hängt, denn:

1) der Traceroute (ICMP) läuft nur bis zur Firewall
2) der Router antwortet auf einen Ping (ebenfalls ICMP)

Theoretisch müsste der Traceroute zumindestens bis zum Router laufen (Hop 1: Firewall, Hop 2: Router, usw.).
Du bist aber nicht zufällig gleichzeitig via Kabel und WLAN verbunden, oder?

 

[Fidibus]

Alles zum Routing auf der pfsense:

 

[Fidibus]

Du bist aber nicht zufällig gleichzeitig via Kabel und WLAN verbunden, oder?

Nein, steter Wechsel.

 

[blurrrr]

Ok, lass wir das mal kurz mit dem ICMP aussen vor, bis zum Router scheint es ja durchaus zu gehen, ergo wird NAT aktiv sein (sonst könnten die Pakete - ohne statische Routen auf dem Router - nicht zurück hinter die Firewall).

In der Firewall unter "Diagnostics" gibt es 3 Punkte, welche genau das gleiche machen:

1) Ping
2) Traceroute
3) DNS Lookup

Der Unterschied ist da, dass diese Dinge von der Firewall selbst laufen. Probier die 3 Sachen mal aus, Screenshots brauchste nicht machen, kurzes jeweiliges ja/nein reicht

 

[Fidibus]

1) Ping
2) Traceroute
3) DNS Lookup

Auf 8.8.8.8
ping - nein
traceroute - nein
nslookup:

 

[blurrrr]

1) Es sollte eine Firewall-Regel geben, welche besagt:

Quelle: 192.168.18.0/24 -> jegliches Protokoll (any/"*") -> jegliches Ziel (any/"*") -> Erlauben

Kann aber auch gut sein, dass es so eine Regel schon gibt, da ggf. schon automatisch erstellt.

2) Es sollte eine NAT (SNAT/"outbound") geben, welche besagt:

Quelle: 192.168.18.0/24 -> Interface: WAN -> jegliches Protokoll -> Source: 192.168.18.0/24 -> Destination: any/"*" -> Translation-Address: WAN-IP

Kann aber hier auch gut sein, dass es so eine Regel schon gibt, da ggf. auch schon automatisch erstellt.

Versuch mal vom Client ein "nslookup 8.8.8.8 192.168.1.1", damit wird die DNS-Anfrage direkt an den Router geschickt. Eventuell antwortet die Firewall einfach nicht auf DNS-Anfragen. Selbst kann sie ja durchaus welche auflösen, von daher liegt die Vermutung nahe, dass die Teilnehmer aus dem 18er Netz die Firewall nicht als DNS-Resolver benutzen dürfen. Der o.g. nslookup-Test sollte darüber Aufschluss geben. Falls das funktioniert, schaust Du mal in der Firewall unter "Services/DNS Resolver", aktivierst das ggf. und markierst dort alle Interfaces der Firewall, auf welchen der DNS-Resolver lauschen soll (in Deiner aktuellen Konfiguration wohl nur OPT1). Weiter unten solltest Du auch noch den Haken bei "DNS Query Forwarding" setzen, damit Anfragen, welche die Firewall nicht beantworten kann, weitergeleitet werden an den nächsten Resolver (z.B. Dein Router (192.168.1.1)).

 

[Fidibus]

Erst einmal schon vielen danke für dein begleitendes Konfigurieren .
1. nach meiner Meinung nach vorhanden (automatisch).
2. nach meiner Meinung nach vorhanden (automatisch).

unter "Services/DNS Resolver"

Bei IF Auswahl steht "alle", eine Einzelaktivierung würde nach meinem Eindruck sehr viel ausschließen und scheint auch keine Mehrfachauswahl zu sein.

DNS Query Forwarding

Dieser Haken brachte einen Fortschritt:

Versuch mal vom Client ein "nslookup 8.8.8.8 192.168.1.1"

Trotzdem ist das Internet aus dem 192.168.18.0 nicht erreichbar. (das Netz 192.168.1.0 schon)

 

[Fidibus]

Etwas, was ich nach allerlei Angucken nicht verstehe.

Nach meinem Verständnis passieren laut dem Eintrag keine Pakete die FW, obwohl ein nslookup sowie Traffic in das 192.168.1.0 Netz laufen.
Ich habe einige selbst getätigte Einträge nach Überprüfung auf Funktionslosigkeit inzwischen noch wieder entfernt.
Es scheint nun bis auf die NAT-Regel alles wohl im default-Modus wieder zu sein.
Daher hänge ich in Zukunft wieder mehr Screenshoots mit an, nicht das irgendwo was fehlt, was ich gerade nicht beachte.

 

[blurrrr]

Also... mal so zum ganz "grundlegenden" Verständnis - erstmal ohne DNS und so:

Ohne Kenntnisse "anderweitiger Netzwerke" (UND den Gateways, welche in diese Netze führen), können Geräte nur mit Geräten "innerhalb" ihres "eigenen" Netzwerkes kommunizieren. Heisst - ohne weitere Beachtung der Netzwerk-Topologie - z.B.:

192.168.1.100 <-> 192.168.1.1 = funktioniert
192.168.18.100 <-> 192.168.1.1 = funktioniert nicht.

Warum das nicht funktioniert? Weil die Geräte alle eine "Default"-Route haben mit einem "Default"-Gateway. Warum? Alles was an Netze geht, welche die Geräte selbst nicht gehen, wird zum Default-Gateway geschickt (frei nach dem Motto: "Das Ding wird schon wissen, wohin das Zeugs muss"). Ist bei der Post auch nicht anders - geb ich Dir meine Adresse und Du schickst mir ein Paket, interessiert Dich auch der Weg nicht, das übernimmt die Post für Dich bzw. "initial" die Stelle, bei welcher Du Deine Pakete immer zum Versand abgibst (quasi Default-Gateway) - Rest interessiert nicht. Das nur mal für ein grobes Verständnis.

Wenn man sich jetzt primär mal: "192.168.18.100 <-> 192.168.1.1" anschaut, sieht das etwas detailierter wie folgt aus:

Router: 192.168.1.1
Firewall: WAN: 192.168.1.2, LAN: 192.168.18.1
Client: 192.168.18.100
Client-Ziel: 8.8.8.8

Nun läuft das ganze wie folgt: Der Client (192.168.18.100) schickt ein Paket an ein Netz/eine IP (8.8.8.8) - wo er selbst den Weg dorthin nicht kennt - zu seinem Default-Gateway (192.168.18.1). Das Default-Gateway wiederum prüft, ob es eventuell das Netz kennt (in Deinem Fall ist das nicht so) und leitet das Paket wiederum an sein Default-Gateway weiter, usw. (das läuft im Internet selbst dann auch nicht anders).

Soweit alles kein Ding, problematisch werden die Dinge dann aber auf dem "Rückweg" (wenn Dein Postbote quasi nicht weiss, wo Du wohnst). Wenn Dein Router ein Paket zur Adresse 192.168.18.100 zustellen soll, weiss er nicht was er damit machen soll, denn er kennt den Weg dorthin nicht. Ergo wird er das Paket an "sein" Default-Gateway schicken (und somit ins Internet). Das Paket wird also niemals bei Dir ankommen. Bei einem Router, bei welchem man selbst Routen anlegen könnte (z.B. einer Fritzbox), wäre es leicht: Du legst eine Route an in Form von "Netz 192.168.18.0/24" ist erreichbar über Gateway "192.168.1.2" (Firewall-WAN-Interface). Diese Möglichkeit hast Du jetzt aber nicht.

Es gibt aber durchaus eine Lösung, die nennt sich "NAT" (Network Address Translation). Das macht Dein Router sowieso schon, denn niemand im Internet kann Dir eine Antwort an Deine private IP-Adresse (192.168.x.x) schicken, denn niemand kennt den Weg dorthin. Dein Router geht nun bei "ausgehenden" Paketen hin, schaut in die Paketinformationen und überschreibt die Paket-"Quell" von z.B. 192.168.1.100 auf seine eigene WAN-IP, denn die eigene WAN-IP ist öffentlich im Internet erreichbar und dorthin kann man aus dem Internet auch Pakete schicken. Macht Dein Router so eine Umschreibung, merkt er sich das auch. Kommt nun das Antwort-Paket von extern bei der WAN-IP Deines Routers an (Paket-Ziel = Router-WAN-IP), schaut er in seine Tabelle (die er sich schlauerweise angelegt hat) und überschreibt bei dem Paket die Ziel-IP (neues Paket-Ziel = LAN-IP des Clients, welcher zuvor das initiale Paket rausgeschickt hat).

So... kommen wir wieder zu Deinem "internen" Aufbau: Wenn ein Paket aus dem 18er Netz soll, kann der Router keine Antwort darauf schicken, er kennt das Netz nicht. Deswegen muss "NAT" aktiv sein. Schickst Du mit aktiviertem NAT ein Paket zum Router, wird im Paket die Quelle umgeschrieben von der Client-IP (192.168.18.100) auf die WAN-IP der Firewall (192.168.1.2). Nun kriegt der Router also eine Anfrage von der (vermeintlichen) IP 192.168.1.2 und kann die Antwort auch direkt zurück schicken, denn - wie eingangs erwähnt - Geräte im gleichen Netz können "direkt" miteinander kommunizieren. Die Firewall nimmt das Antwort-Paket entgegen, schaut in ihre Tabelle und stellt das Paket dem Client zu, welcher das Paket initial losgeschickt hat.

So, hoffe dieser kleine (sehr vereinfachte) Ausflug hat zumindestens bzgl. Routing und NAT ein "bisschen" Licht gebracht, habe mich bemüht es reicht einfach zu halten Das ist jetzt auch erstmal ohne Bezug auf Deine aktuelle Problematik, sondern soll einfach ein "generelles" Verständnis für die Dinge bringen.

P.S.: An dieser Stelle noch ein klitzekleiner Hinweis: Firewalls sind dazu da, sich unerwünschen Traffic vom Hals zu halten und genau das tun sie i.d.R. auch. Nun hast Du eine Regel, welche besagt: LAN darf überall hin. Scheint aber wohl nicht so wirklich zu funktionieren! Glücklicherweise kannst Du pro Firewall-Regel auch mitschneiden lassen, was genau verworfen/geblockt wird (Firewall-Regel -> Extra Options -> Log). Die verworfenen Dinge kannst Du dann unter "Status/System Logs/Firewall/Normal View" einsehen, ggf. auf "dynamic" schalten, dann sollte die Liste auch dynamisch aktualisiert werden. Das aber nur mal am Rande zwecks Troubleshooting-Möglichkeiten

 

[blurrrr]

So... jetzt mal zu den "Regeln": Da Du Deinen Router anpingen und via DNS aus dem 18er Netz befragen kannst, kann man davon ausgehen, dass NAT "grundsätzlich" aktiv ist (bei dem Router kann man ja keine eigenen Routen anlegen, also ist das auch die einzige Möglichkeit). Die Frage ist jetzt: "In welchen Situationen passiert WAS?".

Du hast jetzt zum einen die "niedrigen" Dinge (Routing/NAT) und die "höheren" (DNS, HTTP/S, etc.). So "ganz" grundsätzlich sollte man sich "immer" erst darum kümmern, dass es unten läuft, ansonsten wird es oben nie laufen (niedrig/hoch basiert hier übrigens auf dem OSI-Schichtenmodell (falls von Interesse)). Vergleichbar ist das mit einem Auto und einer Strasse... was willst Du groß am Auto schrauben (damit Du noch schneller fahren kannst), wenn es gar keine Strasse zum fahren gibt? Somit ergibt sich folgendes:

1) Physikalische Verbindungen (Kabel müssen stecken, Strom muss da sein, sonst wird das halt alles nix )
2) Routing (Strassen und Wegweiser müssen da sein)
3) ggf. noch NAT (spätestens am Router "brauchst" Du es, zumindestens bei IPv4 (bei IPv6 dann nicht mehr))

Erst wenn diese 3 Dinge grundlegend eingerichtet sind/funktionieren, beginnt man damit sich um den Rest zu kümmern.

Zu "testen" wäre demnach folgendes:

1) Erreichbarkeit der Firewall aus dem LAN
2) Erreicherkeit eines anderen Netzes (OPT1) hinter der Firewall (z.B. ein Ping auf die IP vom TL-SG1005P (172.20.18.x))

Wenn diese beiden Dinge funktionieren, kannst Du erstmal grundsätzlich davon ausgehen, dass das Routing "hinter" der Firewall funktioniert. Diese beiden Dinge sollten in der aktuellen Konfiguration auch schon funktionieren (aufgrund der "LAN -> ANY"-Regel). Vom OPT1-Netz ins LAN kommt man vermutlich nicht, da es dafür derzeit (vermutlich) keine entsprechende Regel gibt.

Soweit... wenn die Kommunikation "hinter" der Firewall nun funktioniert, wird es Zeit, dass man sich das ganze mal "vor" der Firewall anschaut. Wie wir ja mittlerweile wissen, wird diesbezüglich definitiv NAT benötigt (in diesem Fall ein SNAT (Source-NAT), welches besagt: Sobald Traffic aus Netz XY kommt und über das WAN-Interface raus geht, überschreib die Paket-Quelle mit der Firewall-WAN-IP. Ansonsten weiss der Router nicht wohin mit der Antwort und schickt diese an sein Default-Gateway (Internet, wo das Paket dann verworfen wird).

Also schau mal unter Firewall / NAT / "Outbound" (es geht ja um "ausgehenden" Traffic - aus Sicht der Firewall). Dort gibt es automatisch erstellte Regeln und ggf. auch manuell erstellte. Ich persönlich bin ein Freund von manuell erstellten Regeln, denn dann weiss man auch was man wie und warum getan hat und es ist auch genau "so", wie man das selbst möchte. Ganz unten auf der Seite sollte es die "Automatic Rules" geben, es müsste auch schon eine vorhanden sein, welche besagt: Die Netze "hinter" der Firewall werden beim Austritt über das WAN-Interface mit der WAN-Address umgeschrieben (NAT-Address). Ist da etwas entsprechendes vorhanden?

 

[Fidibus]

Moin @blurrrr
Dank für die ausführlichen Erklärungen - die Theorie ist mir eigentlich gut bekannt, hab ich mir bisher zumindest eingebildet, ist halt auch ne Form von Bildung .
Ich folge mal deiner Anleitung.
Firewallregel mitloggen -> check
Logging dynamisch, Filter auf meine Absende-IP -> check
In meinem Client im Browser: www.google.de -> enter

Meine rudimentäre Fehlersuche:
Client: IP, Gateway und Netzmaske -> check
Ping lokales Gateway -> check
Ping WAN-Gateway -> check
Ping auf 8.8.8.8 -> nein
nslookup auf www.google.de ->

Hmm..."Nicht autorisierende Antwort:" -> mal schauen, ob das erst mal ein Problem ist.
Überlegung: die VF-Box kennt den Weg über pfsense in das 192.168.18.0 nicht. Warum dann auch immer nslookup funktioniert, erst mal keine Ahnung.
Aber durch keine Logeingträge macht es das Ganze auch nicht einfacher.

 

[blurrrr]

Hehe, also erstmal: Wenn Du bei einer Regel das Logging einschaltest, werden auch nur Pakete aufgezeichnet, welche "diese" Regel betreffen. Btw sicher, dass ".1.18" korrekt ist?

Weiter gehts: "Was funktioniert?" Was funktioniert, wäre die Tatsache, dass Deine Firewall mittlerweile auf DNS-Anfragen von einem Client aus dem 18er Netz antwortet UND diese auch entsprechend weiterleitet (Firewall alleine kann erstmal keine DNS-Anfragen beantworten, wie sollte sie auch?). Dazu muss man jetzt allerdings auch wissen, dass die Firewall diese Anfrage "selber" stellt (sie leitet also nicht einfach weiter, sondern sendet sie wiederum mit ihrer WAN-IP an den nächsten Server (Upstream-DNS-Resolver)).

Allerdings wissen wir auch schon, dass "NAT" für das LAN definitiv funktionieren "muss", denn eine DNS-Abfrage ging ja erfolgreich durch (vom 18er Client an den 1er Router). Ich würde an dieser Stelle aber vorschlagen, dass Du Dir nochmal die Sache mit dem NAT durchliest, denn scheinbar ist das nicht ganz angekommen (oder ich hab schlecht erklärt), ansonsten würden sich solche Überlegungen direkt erübrigen:

Überlegung: die VF-Box kennt den Weg über pfsense in das 192.168.18.0 nicht. Warum dann auch immer nslookup funktioniert, erst mal keine Ahnung.

Ganz nebenbei: Ping (ICMP) kann durchaus auch von der Firewall geblockt werden. Wenn Du ein Ping zu Deinem Router durchführst und es nicht funktioniert (DNS geht ja!), versuch einfach die Weboberfläche vom Router im Browser zu öffnen (aus dem 18er Netz).

 

[Fidibus]

Btw sicher, dass ".1.18" korrekt ist?

Natürlich nicht!