NAT Routing Homelab
-
@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.
