NAT Routing Homelab

[NOCling]

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]

@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.

[svenp]

@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

[viragomann]

@svenp said in NAT Routing Homelab:

Das ist die "Block-Bogon" Geschichte, oder?

"Block private networks and loopback addresses"

[svenp]

@viragomann

"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?

[NOCling]

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.

[viragomann]

@svenp
Nein. Ist der gesetzt, steht eine entsprechende Regel ganz oben im Ruleset.

[viragomann]

@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.

[svenp]

@viragomann

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 ms

Packet 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 64

Kudos!

[viragomann]

@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]

@viragomann

Als Workaround für Zuhause mit dem nachfolgenden Regelwerk aber doch vertretbar, oder?

[viragomann]

@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.