NAT Routing Homelab
-
@svenp
Mit dem Transit-Netz wärst du schon auf der richtigen Spur. Hast vermutlich schon recherchiert?Ist aber nicht zwingend nötig und hier wahrscheinlich unnötig kompliziert.
Das Problem ist wohl, der ISP Router (fälschlicherweise als Modem bezeichnet) kennt das Subnetz des Servers nicht, und schickt damit die Pakete von Client 1 auf sein Standardgateway, also ins Internet.
Lösungen:
- Statische Route am Client 1 selbst, die die WAN IP der pfSense als Gateway verwendet.
- oder eben eine NAT Regel auf der pfSense. Du könntest dafür auch eine 2. WAN-IP (Firewall > Virtual IPs, Type = IP Alias) hinzufügen und ein NAT 1:1 auf den Server einrichten, oder eben auf der existierenden WAN IP nur bestimmte Ports an den Server weiterleiten.
Bevor die Idee kommt: Eine statische Route, auf dem ISP-Router würde nicht funktionieren.
-
@viragomann
Hi, vielen Dank für die blitzartige und fundierte Antwort!Eine statische Route auf dem ISP-Router ist dank anbieterseitiger Kastration nicht möglich, genau. Die statische Route auf Client1 (sudo route -n add -net 192.168.100.0/24 192.168.0.189) in Richtung Lan-Bereich2 (alleine) brachte leider nicht den gewünschten Erfolg.
Hatte zu dem Transit-Netz recherchiert, exakt; Habe jetzt einen IP Alias mit 192.168.1.1/24 auf die WAN IP gelegt, mit einer Outbound NAT Rule:
Und einer statischen Route:
Vermutlich meintest Du so etwas mit "unnötig kompliziert"...
Über Diagnose > Ping lässt sich von 192.168.1.1 in Richtung LAN-Bereich1 und LAN-Bereich2 erfolgreich kommunizieren.
Ein Versuch den WAN Traffic auf 192.168.1.1 zu NAT'ten war leider nicht erfolgreich.Über einen Packet Capture sieht es so aus, als kenne die PFSense den "Rückweg" Richtung Lan-Bereich1 nicht, oder käme aus irgendwelchen gründen nicht hin?:
20:38:22.867420 IP 192.168.0.192 > 192.168.100.133: ICMP echo request, id 56963, seq 0, length 64
20:38:22.868117 ARP, Request who-has 192.168.0.192 tell 192.168.100.133, length 46Ein selektives Port-Forwarding würde ich gerne vermeiden und stattdessen lieber das Routing zwischen den beiden Netzen korrigieren, weil in LAN-Bereich2 später noch ein (virtuelles) GW installiert werden soll.
-
@svenp said in NAT Routing Homelab:
Die statische Route auf Client1 (sudo route -n add -net 192.168.100.0/24 192.168.0.189) in Richtung Lan-Bereich2 (alleine) brachte leider nicht den gewünschten Erfolg.
Zusammen mit einer Firewall-Regel am WAN natürlich, die den Zugriff erlaubt.
pfSense ist ja das Standgateway auf dem Server? Wenn ja, sollte das reichen und es wär wohl die beste Lösung.Habe jetzt einen IP Alias mit 192.168.1.1/24 auf die WAN IP gelegt,
Ich hatte eigentlich eine zusätzliche IP im selben WAN-Netz gemeint.
Auf eine andere kann der Client ja nicht zugreifen, solange er selbst nicht in diesem Netz ist. Er würde die Pakete zum Router schicken.mit einer Outbound NAT Rule:
Und einer statischen Route:Ist hier beides fehl am Platz.
Was siehst du mit Packet Capture am WAN u. am LAN, wenn du die statische Route am Client angelegt hast und die Server-IP pingst?
-
Ist hier beides fehl am Platz.
Outbound NAT Rule, statische Route und 1:1 NAT deaktiviert.
Was siehst du mit Packet Capture am WAN u. am LAN, wenn du die statische Route am Client angelegt hast und die Server-IP pingst?
Client1 (mit statischer Route):
PING 192.168.100.133 (192.168.100.133): 56 data bytes Request timeout for icmp_seq 0Packet Capture WAN side:
21:23:20.225592 IP 192.168.0.192 > 192.168.100.133: ICMP echo request, id 55941, seq 78, length 64Packet Capture LAN side:
21:23:20.225592 IP 192.168.0.192 > 192.168.100.133: ICMP echo request, id 55941, seq 78, length 64Diagnose > Ping an Server1 von LAN(Bridge):
PING 192.168.100.133 (192.168.100.133) from 192.168.100.1: 56 data bytes 64 bytes from 192.168.100.133: icmp_seq=0 ttl=64 time=0.578 ms -
@svenp
Na ja, dann würde ich sagen, alles korrekt konfiguriert, doch der Server blockiert Zugriffe von außerhalb seines Subnetzes.
Ist eigentlich die Standardkonfiguration fast jedes Netzwerk-befähigten Gerätes.Du musst das am Server erlauben.
-
Hatte das ganze Szenario ohne Änderung am Server am laufen, bevor die SD Karte in der APU abgeraucht ist. Natürlich kein Configbackup und die Einrichtung liegt schon länger zurück.
Ich meine ich wäre damals über ein Transit-Netz gegangen (1:1 NAT und Outbound Rule + vIP?), bekomme es nicht mehr zusammen und habe das Gefühl, die PFSense macht teils "unsaubere" Sachen beim umkonfigurierten der NAT-Regeln, ohne kompletten Neustart (der auf der APU schon mal gut und gerne 2 Minuten dauert)?
-
2 Minuten für einen full Reboot ist für eine Firewall eine gute Zeit, ein Reroot reicht hier aber meist schon, das schafften die Kisten dann teilweise in der hälfte.
Warum wird das Modem nicht als Modem verwendet, dann einfach alles an die pfSense direkt gehangen und dann ist die GW und kann alles sauber routen.
Wenn der Server dann nur mit seinem eigenen NET reden will, gut dann gibt es dafür halt ein NAT mit Virtueller IP und schon kann man den hinters Licht führen. Mache ich mit meinen Switchen, denn wenn ich da das Management VLAN definieren, dann reden die nur noch mit System im gleichen Netz.
Meine Clients die die verwalten sind aber in einem ganz andern, also löst NAT + Regelwerk das Problem.Die Provider Kiste davor zu betreiben wäre mir persönlich zu viel Betrieb durch Zufall! Da kannst nix einstellen, die Dinger sind je nach SW die dir einfach draufgeballert wir mal stabil mal ein Kartenhaus. Ein Modem kann da halt weniger Falsch machen wie im Router Modus, zudem die pfSense dann auch gleich sauber die WAN IPs bekommt und auch das Prefix für ipv6, das ist sonst immer ein Akt wenn es denn überhaupt geht.
-
@viragomann
Ach ja, eine Sache noch vergessen. Auf der pfSense muss in den WAN Interface Einstellungen auch noch "block private networks" deaktiviert werden, was standardmäßig für WAN gesetzt ist. -
@NOCling
Ja und Ja - 2 Minuten sind gut, wenn man sich durch das NAT'ting nicht selbst ausgesperrt hat (Administration erfolgt über Client1, also sensenseitig das WAN Interface). Das ISP-Gerät in einen Full-Modem Modus / Bridge Mode zu versetzen geht glaube ich nur einmalig, dabei wären WLAN und zusätzliche LAN-Ports dann "futsch". Ansonsten Full-ACK, ISP-Modem-Bridge-> APU PFSense -> L3 Switch -> Peripherie wäre vermutlich die sauberste Lösung.@viragomann
Das ist die "Block-Bogon" Geschichte, oder? Die Haken sind auf beiden Interfaces (WAN/LAN) draußen.Notiz an mich selbst: Mehr Doku schreiben und Config's extern sichern
-
@svenp said in NAT Routing Homelab:
Das ist die "Block-Bogon" Geschichte, oder?
"Block private networks and loopback addresses"
-
"Block private networks and loopback addresses"
Beide Haken, auf beiden Interfaces, draußen:
Nur für mich zum Verständnis: Mit Haken "Block private networks" auf dem WAN Interface hätte der ICMP Request von Client1 auch nicht auf dem LAN-Interface aufschlagen dürfen, oder?
-
Ja die Ports wären dann futsch, aber die sind eh doof, können keine VLANs, Port Stats, Spanning Tree, Loop Protection, LACP usw.
Zudem steht die Kiste meist nicht da wo ein AP hängen sollte für perfekte WLAN Versorgung. -
@svenp
Nein. Ist der gesetzt, steht eine entsprechende Regel ganz oben im Ruleset.
-
@svenp said in NAT Routing Homelab:
Hatte das ganze Szenario ohne Änderung am Server am laufen, bevor die SD Karte in der APU abgeraucht ist. Natürlich kein Configbackup und die Einrichtung liegt schon länger zurück.
Ich meine ich wäre damals über ein Transit-Netz gegangen (1:1 NAT und Outbound Rule + vIP?), bekomme es nicht mehr zusammen und habe das Gefühl, die PFSense macht teils "unsaubere" Sachen beim umkonfigurierten der NAT-Regeln, ohne kompletten Neustart (der auf der APU schon mal gut und gerne 2 Minuten dauert)?
Ein Transit-Netzwerk würde bedeuten, dass zwischen ISP-Router und pfSense ein separates Netzwerk eingerichtet wird und auf dem Router eine statische Route für das Netzwerk hinter der pfSense gesetzt wird.
Letzteres unterstützt dein Router nicht, meine ich oben gelesen zu haben. Wenn das zutrifft, dann unterstützt er wohl auch kaum mehrere Subnetze.
Dann war es das wohl eher nicht.Ich würde eher vermuten, dass du die Blockade des Servers mit eine Outbound NAT-Regel umgangen bist, ähnlich wie oben, nur eben die richtige Quell-IP.
Allerdings braucht es dann dennoch entweder eine statische Route am Client oder du musst es mittels NAT Portforwarding machen. -
Oh man - Stimmt, die Outbound NAT-Regel war es. Danke!
Client 1 (mit statischer Route):
PING 192.168.100.133 (192.168.100.133): 56 data bytes 64 bytes from 192.168.100.133: icmp_seq=0 ttl=63 time=6.174 ms 64 bytes from 192.168.100.133: icmp_seq=1 ttl=63 time=2.449 msPacket Capture LAN side:
00:09:41.703797 IP 192.168.100.1 > 192.168.100.133: ICMP echo request, id 37546, seq 0, length 64 00:09:41.704473 IP 192.168.100.133 > 192.168.100.1: ICMP echo reply, id 37546, seq 0, length 64Kudos!
-
@svenp
Als Empfehlung war das aber nicht zu verstehen. Wie geschrieben, umgehst du damit nur die Schutzmaßnahmen der Server-Firewall. Es ist eben nur ein Workaround.Die Empfehlung ist, die Server-Firewall so zu konfigurieren, dass sie Zugriffe vom Client erlaubt, jene aus dem Internet aber nicht (wenn nicht nötig).
-
-
@svenp
Ja, solange die Quelle in der Outbound NAT Regel auf das interne Subnetz eingeschränkt bleibt.
Ich würde sie noch weiter, nur auf die Client IP beschränken (Maske /32).Ich habe einige Consumer-Router gesehen, die standardmäßig ebenso eine Masquerading Regel am internen Interface hatten und damit sämtlichen eingehenden Traffic aus dem Internet so aussehen ließen, als würde er aus dem lokalen Netz kommen.
Einen solchen würde deine Regel abermals mit der eigenen Interface IP verschleiern.
