OPNsense Forum
International Forums => German - Deutsch => Topic started by: Ducksoul on April 18, 2022, 01:23:12 pm
-
Moin,
nachdem ich mich die letzten Tage hier lesend rumgetrieben habe, möchte ich nun aktiv werden und eure Expertise einholen. :)
Seit Jahren befasse ich mich immer Mal wieder mehr oder weniger intensiv mit dem Thema 'Netzwerk'. Bis heute habe ich allerdings noch nicht alle meine Anforderungen final umsetzen können. Da ich zusätzlich in der jüngeren Vergangenheit auch einige weniger schönere Erfahrungen mit einigen Tools von Ubiquiti gemacht habe, möchte ich das Thema noch einmal grundlegend neu angehen. Ob ich am Ende die Umstellung versuche selber vorzunehmen oder dies extern gelöst wird, weiß ich noch nicht.
Zunächst aber vielleicht zu meinen Zielen:
- Um eine größere Herstellerunabhängigkeit zu erreichen und flexibler in der Konfiguration zu werden möchte ich das bisher eingesetzte Ubiquiti USG-3P ersetzen. Geplant ist die Einbindung von OPNSense auf einem IPU 602.
- Durch mich betreut werden 2 Heimnetzwerke: Mein eigenes und das meiner Eltern. Beide Netzwerke sollen über ein Site-2-Site - VPN verbunden sein (beide Netzwerke haben leider dynamische public-ip's). Dieses VPN soll unter anderem für Offsite-Backups der in den Netzwerken stehenden NAS-Geräte verwendet werden.
- Für beide Sites sollen folgende Netzwerke eingerichtet werden: Managment, LAN, Gast, Office, IoT
- Als DNS-Server soll eine Pihole-Instanz verwendet werden.
- Auf die NAS-Systeme soll teils auch aus dem Internet zugegriffen werden (bspw. für Zugriff auf den Bitwarden Vault)
.
[/list]
Bevor ich anfange am bestehenden Netzwerk etwas zu ändern möchte ich die Herangehensweise dieses Mal einmal komplett durchplanen bevor ich mitten auf dem Weg auf Probleme stoße, die bereits vorher hätten auffallen können.
Bereits aktuell aufgekommene Fragen:
Welche Software soll auf welcher Hardware laufen?
- Momentan habe ich einen zentralen Unifi-Controller auf einem Cloud Key Gen 2+ laufen, welcher für beide Sites zuständig ist. Pihole und Unbound laufen jeweils als Docker-Image auf dem NAS (je Site) und für Firewall und Routing ist das USG zuständig.
- Was wäre eine optimale Lösung für die Zukunft? Ich habe gelesen, dass ich bspw. auch den Unifi-Controller via Proxmox virtualisieren könnte. Auch Pihole könnte wahrscheinlich auf dem IPU laufen. Was wären Vor- und Nachteile der unterschiedlichen Lösungsansätze? Bzgl. der Robustheit in Update-Szenarien könnte ich mir auch vorstellen 2 Instanzen laufen zu lassen und das Docker-Image als alternativen DNS-Server zu nutzen, falls der primäre einmal ausfällt.
- Ich tendiere zusätzlich dazu beide Sites komplett unabhängig voneinander zu machen (also 2 Controller einzusetzen). Die ursprüngliche Idee alles über einen Controller laufen zu lassen, um direkt ein funktionierendes Site-To-Site einrichten zu können war ein von Ubiquiti kommuniziertes Feature was so leider nie funktionierte.
Wie gehe ich an das Thema Site-To-Site VPN ran? Welche VPN-Lösung bietet sich an und wie gehe ich mit dem Problem 'dynamische IP' am besten um?
Ist die von mir präferierte neu anzuschaffende Hardware https://www.ipu-system.de/produkte/ipu602.html (https://www.ipu-system.de/produkte/ipu602.html) für den Einsatz sinnvoll? Welche SSD und wieviel RAM sollte ich nehmen?
- Aktuelle Bandbreite sind 50 down und 10 up. Ich möchte allerdings zukunftssicher aufgestellt sein, falls ich doch demnächst das Bedürfnis habe mehr Bandbreite zu ordern.
Gibt es noch weitere Dinge die ich beachten sollte, Tutorials oder Seiten die ich durchlesen sollte?
Ich hoffe ich habe es geschafft meine Gedanken halbwegs strukturiert niederzuschreiben. Bei Rückfragen gebt bitte Bescheid. Ansonsten schonmal vielen Dank für die Unterstützung! :)
PS: Ich habe im Anhang einmal einen Netzwerkplan mit der Aufstellung meiner Netzwerkgeräte angehängt. Das Netzwerk meiner Eltern sieht ähnlich aus. Für das Gäste-WLAN werden dort ebenfalls Ubiquiti Access Points. Zur Telefonie und das heimische WLAN sind jedoch noch Geräte von AVM im Einsatz.
-
Das Gerät ist OK. Ich würde das gleich mit 16 GB oder besser 32 GB nehmen.
Eine einfache SATA SSD sollte reichen. Wenn ZFS verwendet werden soll rate ich zur Enterprise Variante.
Consumer SSD werden sonst zu schnell (2-3 jahre) kaputt geschrieben.
Dann Virtualisieren mit Proxmox. Die Frage ist ob wirklich 6 Netzwerkkarten gebraucht werden.
Den Ubi Controller als VM den Pihole auch. So habe ich das bei mir zu Hause.
Zum Spielen kann man dann auch noch mal die eine oder andere VM auf dem Gerät laufen lassen.
Die Vms können dann auf das NAS gesichert werden. Wenn der Proxmox mal kaputt geht ist das ganze in5 Minuten wieder aufgesetzt. USB Stick am besten dafür griffbereit haben.
-
Bestellt habe ich jetzt erstmal folgendes:
- IPU613 mit 16GB RAM und 128GB SSD für mich
- IPU602 mit 8GB RAM und 128GB SSD für Site 2
Sollte sich herausstellen, dass der Arbeitsspeicher auf Sicht knapp wird, kann man den ja auch noch nachträglich aufstocken.
Ich werde mich die kommenden Tage erstmal näher mit Proxmox befassen und im ersten Schritt den Unifi Controller und Pihole angehen.
Wie sieht es mit den anderen Fragen aus? Insbesondere was die Einrichtung des Site-toSite VPN's angeht bin ich momentan sehr planlos und wäre für einen Hinweis dankbar.
Gruß
-
Site-2-Site VPN am besten mit Wireguard (https://docs.opnsense.org/manual/how-tos/wireguard-s2s.html). Damit sich die beiden Seiten finden können benötigst Du natürlich DynDNS. Beides ohne Probleme mit OpnSense möglich, mache ich genauso. Nur dran denken: den beiden LANs unterschiedliche IP-Ranges verpassen, damit man überhaupt routen kann.
-
zu Site 2 Site Tunneln gibts hier ja massenhaft Doku - vielleicht schaust Du Dir das vorher mal in Ruhe an.
Interessant wäre vielleicht auch WireGuard, da ist die Konfiguration etwas einfacher.
Wichtig: bitte nicht in beiden Lokationen das olle Default-Netz verwenden z.B. beide auf 192.168.1.x laufen lassen, sonst wirds schwierig mit den Routen ;) Mit DHCP solte aber auch diese Umstellung kein Problem sein.
-
Hi,
> Um eine größere Herstellerunabhängigkeit zu erreichen und flexibler in der Konfiguration zu werden möchte ich das bisher eingesetzte Ubiquiti USG-3P ersetzen. Geplant ist die Einbindung von OPNSense auf einem IPU 602.
Fein :) Die USGs sind auch nicht wirklich toll.
> Durch mich betreut werden 2 Heimnetzwerke: Mein eigenes und das meiner Eltern. Beide Netzwerke sollen über ein Site-2-Site - VPN verbunden sein (beide Netzwerke haben leider dynamische public-ip's). Dieses VPN soll unter anderem für Offsite-Backups der in den Netzwerken stehenden NAS-Geräte verwendet werden.
Prinzipiell kein Problem, aber dann würde ich SEHR dazu raten, die Netze ordentlich durchzuplanen und Luft zu lassen.
> Für beide Sites sollen folgende Netzwerke eingerichtet werden: Managment, LAN, Gast, Office, IoT
Sind die IP Ranges bei den Eltern da schon in Betrieb schon fix? Oder kann/wird das alles noch umgestellt?
> Als DNS-Server soll eine Pihole-Instanz verwendet werden.
Habe ich hier auch laufen (sogar derer zwei mit Sync), kein Problem.
> Auf die NAS-Systeme soll teils auch aus dem Internet zugegriffen werden (bspw. für Zugriff auf den Bitwarden Vault)
Auch kein großes Problem, hängt nur davon ab, wie der Internetzugang hergestellt werden soll. Ob direkt, mit Providerbox davor etc.
> Das Netzwerk meiner Eltern sieht ähnlich aus.
OK aber ist das Netz der Eltern wie gesagt schon fix? Sind da IP Ranges schon vergeben? Welche? Kann das ggf. neu geplant werden?
Sinn würde es auf jeden Fall machen - wenn du beides managen sollst - dass du dir bei den IP Ranges keine Steine in den Weg legst und nicht zu "großzügig mit der groben Kelle" die IP Ranges vergibst. Wird gerne mal gemacht, da ist dann das 192.168.1.x da und dann noch .100.x für Gast und .200.x für WiFi o.ä. damits schön getrennt ist - und schon hast du fast den kompletten 192.168er Adressraum versemmelt und kannst ihn nicht sinnvoll zusammenfassen.
Prinzipiell kein Problem wenn du sagst "alles klar, dann bleiben die Eltern in 192.168.x.y und ich geh wo ganz anders rein" aber wenn die Netze ähnlich sind, ist das vielleicht nicht ganz so toll, weil man sonst ja schön vergleichen und abschauen könnte wie es auf den Seiten aussieht etc.
Darum am Besten jetzt schon früh ordentliche IP Ranges planen mit Luft nach oben, also mit zusätzlichen Netzen/VLANs die man alle mit einem sinnvollen CIDR Range greifen und abdecken kann, damit bspw. deine VPNs sich sehr einfach zusammenfassen lassen.
Beispiel:
Seite 1 (deine): Managment, LAN, Gast, Office, IoT
Geplant: 5 + VPNs -> sind wir schon schnell an der Grenze zu 8 womit ein CIDR Range von /21 fast zu klein wäre. Also lieber mit /20 planen, das wären dann 16 mögliche /24er Netze. Da zu Hause oft 10.0.0.0 oder 192.168.x.0 auftauchen, gehen wir vllt. einfach besser ins 172.16-31er Segment.
Seite (1)
Mgmt: 172.21.0.0/24
LAN: 172.21.1.0/24
Office: 172.21.2.0/24
IoT: 172.21.3.0/24
... Platz für mehr Netze/VLANs
Gast: 172.21.14.0/24
VPN Einwahl: 172.21.15.0/24 (ganzes Netz reservieren, aber ggf. nur ein /26 oder so konfigurieren, damit Platz für Multiple VPNs)
Seite 1 komplett: 172.21.0.0/20
Seite 2 machen wir genauso nur statt .21 mit .22 an zweiter Stelle. Tada, schon haben wir
Seite 2 komplett: 172.22.0.0/20
Für den VPN Tunnel nehmen wir dann was Artfremdes: 10.21.22.0/30 (da brauchen wir normalerweise nur 2 Endpunkte, also genügt ein /30) und wir nutzen 21 und 22 damit klar ist zwischen was der Tunnel spielt.
Wenn man nun intern noch mit VLANs arbeitet kann man auch hier die 2. und 3. Stelle der IP nutzen und hat für Seite 1: VLANs 2100-2115 und für Seite 2: VLANs 2200-2215 und kann das noch beliebig vergrößern. Da VLANs bis 4096 problemlos gehen, sind wir da gut dabei, kollidieren nirgends und haben eindeutige IP Bereiche auf allen Seiten, die sich komplett greifen lassen oder einzeln adressieren, haben disjunkte VLANs die eindeutig sind und nirgends gibts Überschneidungen. Trotzdem kann man schön .21 und .22er Netze vergleichen und sieht dann ggf. wo man Fehler gemacht hat oder was ergänzen kann und alle Netze sind erweiterbar.
VPN damit kann man dann auch das Routing durch das VPN sehr charmant mit einer einzigen Route 172.21.0.0/20 via 10.21.22.x (Tunnelendpunkt des VPNs) erschlagen - und das auf beiden Seiten - und kann so direkt schon vorsorgen, dass 172.2x.0-15.0/24 alle erreichbar "wären" (ob sie es sind entscheidet am Ende ja die Firewallregel, nicht die VPN Config). Ergänzt man irgendwo ein Netz muss man das VPN erstmal nicht anpassen, weil alles schon drin ist.
So arbeitet man sich da in der Netzwerkarchitektur und -planung ab und schaut, dass der Kram zukunftssicher und ordentlich verschnürt ist und damit auch lange ohne Kollisionen oder sonstige Probleme läuft :)
Cheers
-
Hi zusammen,
vielen Dank schonmal für eure Anmerkungen und Tipps. Ich versuche einmal strukturiert darauf einzugehen.
@meyergru, @trixter:
Ich habe mich in der Vergangenheit bereits etwas intensiver mit dem Thema VPN beschäftigt. Bevor ich die Netzwerke neu einrichte möchte ich (gem. JeGr's Rat) das Thema schonmal grob durchgehen, damit ich auf dem Weg nicht auf unerwartete Probleme stoße.
Der Tipp auf WireGuard zu setzen entspricht auch meinem bisherigen Bauchgefühl welche VPN-Lösung ich einsetzen möchte. Ich frage mich allerdings ob die Lösung via DynDNS der richtige Weg ist. Hintergrund: Neben Site-To-Site plane ich auch ein User-VPN.
Bei WireGuard habe ich diesbezüglich das Problem gehabt, dass der Host nur zum Zeitpunkt des Tunnelaufbaus aufgelöst wird. Habe ich nun bspw. von einem mobilen Endgerät aus das VPN aufgebaut und die lokale WAN-Adresse ändert sich, führt dies zu einem Abbruch im Tunnel (trotz DynDNS), welcher erst durch einen neuen manuellen Verbindungsaufbau behoben werden kann.
Ein wenig Internetrecherche hat mir ein paar Hinweise erbracht, dass ich dieses Problem ggf. mittels eines VPS-Servers mit eigener IP umgehen könnte. Sofern ich das verstehe würden Geräte sich in dem Fall immer mit dem VPS-Server verbinden (welcher als WireGuard-Server dient) und die Sites wären als VPN-Clients angebunden.
Ich bin hier mit der Recherche noch ziemlich am Anfang und weiß auch nicht, ob dies der optimale Weg für mein Setup wäre oder es nicht vielleicht doch alternative Möglichkeiten gibt das Thema mit den dynamischen IP's in Verbindung mit einer möglichst robusten Leitung anzugehen.
@JeGr:
Erst einmal vielen Dank dafür, dass du dir die Zeit für eine so ausführliche Antwort genommen hast. Die Ausführungen zu den IP-Ranges haben mich jetzt schon sehr viel weiter gebracht. Tatsächlich sind die Sites aktuell wirklich so konfiguriert wie du es grade nicht empfiehlst... ^^
Um auf die Fragen zu antworten:
>Sind die IP Ranges bei den Eltern da schon in Betrieb schon fix? Oder kann/wird das alles noch umgestellt?
Ich plane die Netzwerke und eingebundenen Geräte komplett neu zu konfigurieren, u.a. um auch einige Fehler aus der Vergangenheit direkt zu fixen. Dementsprechend können auch die IP-Ranges komplett umgestellt werden.
>OK aber ist das Netz der Eltern wie gesagt schon fix? Sind da IP Ranges schon vergeben? Welche? Kann das ggf. neu geplant werden?
Die IP-Ranges können neu geplant werden. Zum aktuellen Netzaufbau beider Sites werde ich die kommenden Tage noch einen Netzwerkplan erstellen und hier zur Verfügung stellen.
Deine Hinweise zu einem möglichen Netzaufbau werde ich die kommenden Tage auch einmal in einen Netzwerkplan gießen, um das ganze einmal zu visualisieren.
Eine Frage aus deinen Ausführungen hat sich für mich ergeben:
VPN Einwahl: 172.21.15.0/24 (ganzes Netz reservieren, aber ggf. nur ein /26 oder so konfigurieren, damit Platz für Multiple VPNs)
Hier habe ich ich noch eine Wissenslücke was CIDR angeht. Angenommen ich definiere '172.21.15.0/26' für ein VPN und möchte dann noch ein weiteres VPN in dem 24er Netz einrichten. Wie würde ich dann bspw. eine weitere Sub-Range zwischen 172.21.15.63 und 172.21.15.254 definieren?
Inzwischen hat sich mir auch noch eine 2. allgemeine Frage ergeben. Gibt es Best Practices in welches Netz ich das NAS hänge? Aktuell hängt sie mit einem Port im LAN und einem weiteren Port im MGMT (für Pi-Hole).
Ciao
-
Der Tipp auf WireGuard zu setzen entspricht auch meinem bisherigen Bauchgefühl welche VPN-Lösung ich einsetzen möchte. Ich frage mich allerdings ob die Lösung via DynDNS der richtige Weg ist. Hintergrund: Neben Site-To-Site plane ich auch ein User-VPN.
Bei WireGuard habe ich diesbezüglich das Problem gehabt, dass der Host nur zum Zeitpunkt des Tunnelaufbaus aufgelöst wird. Habe ich nun bspw. von einem mobilen Endgerät aus das VPN aufgebaut und die lokale WAN-Adresse ändert sich, führt dies zu einem Abbruch im Tunnel (trotz DynDNS), welcher erst durch einen neuen manuellen Verbindungsaufbau behoben werden kann.
Ich weiß nicht, ob das Wireguard-Problem mit der DNS-Auflösung noch existiert oder ob bei Abbruch der Verbindung neu aufgelöst wird.
Beim User-VPN hast Du das Problem mit der neuen IP ja weniger, weil die Verbindung mutmaßlich nur temporär aufgebaut wird. Bei Site-2-Site wird die Verbindung ja von jeder Seite aus aufgebaut. Derjenige, der wegen Abbruch der Verbindung eine neue IP bekommt, wird ja (hoffentlich) den Wireguard neu starten, so dass es keine Rolle spielt, ob die Gegenseite bei unveränderter eigener IP neu auflöst.
VPS geht natürlich, kostet aber extra, wenn man nicht sowieso einen hat. Außerdem erhöht es die Latenz und verringert ggf. den Durchsatz.
-
Ich weiß nicht, ob das Wireguard-Problem mit der DNS-Auflösung noch existiert oder ob bei Abbruch der Verbindung neu aufgelöst wird.
So weit ich weiß, löst Wireguard die IP Adresse nur bei dem start des Dienstes auf. Heißt also, wenn die IP der "Server" Seite sich ändert, muss auf der anderen Seite der Dienst neu gestartet werden.
-
Ja, das ist immer noch so, ich habe es inzwischen nachgesehen.
Ich habe einen Pull Request eingestellt, mit dem man zukünftig einen Cron-Job für die Aktualisierung nutzen kann:
https://github.com/opnsense/plugins/pull/2956
-
Hi,
> Hier habe ich ich noch eine Wissenslücke was CIDR angeht.
Kein Problem :)
> Angenommen ich definiere '172.21.15.0/26' für ein VPN und möchte dann noch ein weiteres VPN in dem 24er Netz einrichten. Wie würde ich dann bspw. eine weitere Sub-Range zwischen 172.21.15.63 und 172.21.15.254 definieren?
Mit reservieren hatte ich hier schlicht die Planung gemeint, dass man nichts anderes in das VPN Segment packt, auch wenn man es ggf. nicht vollständig benötigt oder adressiert. Wenn man eh meist nur max. 10 VPN Clients hat, lohnt es sich ja nicht unbedingt ein /24er Subnetz dafür zu verballern, auch wenn es defacto nichts ausmacht. Aber man kann sich dann Routing-Ärger sparen, indem man überall wo man das VPN braucht als Route einfach die /24 nimmt und damit auch automatisch alle kleineren Abstufungen darin mitnimmt.
Da man bspw. bei OpenVPN oft/gerne mal zwei VPN Server einrichtet - einen für UDP/1194 und einen auf TCP/443 für renitente impertinente Hotel/Public WiFis die tumb irgendwelche Ports blocken, muss man für jedes VPN ein eigenes Einwahl/Transfernetz definieren. Oder man braucht mal noch ein zusätzliches VPN mit anderen Voreinstellungen. Und dann sitzt man da und muss das wieder überall in die Routings eintragen etc. Nimmt man aber nur ein Netz was für einen im Normalfall reicht - bspw. müssen nur 3-4 Leute da rein, dann reicht mir ein /28 für 14 IPs - dann kann man davon mehrere kleine /28er definieren im gleichen /24 Segment und muss an den Routings oder VPN Tunneln etc. gar nichts ändern :)
Beispiel:
172.21.15.0/24 als Bereich für VPNs. VPN brauchst du nur für 2-3 Leute, also reicht ein /28er locker.
172.21.15.0/28 - 1. VPN Bereich (0-15, nutzbar 1-14)
172.21.15.16/28 - 2. VPN Bereich (16-31, nutzbar 17-30)
172.21.15.32/28 - 3. VPN Bereich... usw. usw.
Man kann hier auch verschiedene Größen mixen, man muss nur auf die Boundaries / Grenzen der Netze achten. Bspw.
172.23.15.0/27 - 1. VPN von 0-31, nutzbar 1-30
172.31.15.32/27 - 2. VPN von 32-63, nutzbar 33-62
172.31.15.64/28 - 3. kleineres VPN von 64-79
172.31.15.80/28 - 4. kleineres VPN von 80-95
Jede Adressierung die kleiner wird /28 -> /27 enthält doppelt so viele IPs wie vorher.
1x /24 -> 2x /25 -> 4x /26 -> 8x /27 -> 16x /28 -> 32x /29 -> 64x /30
Und das ist mixbar, wobei man darauf achten muss, dass man einen größeren Bereich nicht einfach x-beliebig festlegen kann, sondern dieser nur an den entsprechenden Grenzen beginnen darf. Beispiel: /27er Netze sind 32 IPs, diese beginnen bei .0, .32, .64 etc. Wenn man jetzt aber die .0 als /28er definiert hat, kann man nicht einfach bei der .16 ein neues /27er anfangen, denn der nächste Start für ein 27er ist die .32. Wenn du also den "Raum" eines größeren CIDR Subnetzes "betreten" hast, ist der ganze Raum blockiert und kann nur von Netzen gleicher und kleinerer Größe genutzt werden.
Es ist wie ein Raster. Ein /24er hat für die ganzen kleineren Netze (25, 26, etc.) ein vorgegebenes Raster wo was reinpasst. Wenn du da was kleineres reinpackst, musst du dich trotzdem an die Grenzen für die Netze halten, sonst adressierst du das falsche Netz. Dafür verwendet man am besten Subnetz-Rechner wie sowas hier:
https://www.calculator.net/ip-subnet-calculator.html?cclass=any&csubnet=27&cip=172.15.11.0&ctype=ipv4&printit=0&x=69&y=16 (https://www.calculator.net/ip-subnet-calculator.html?cclass=any&csubnet=27&cip=172.15.11.0&ctype=ipv4&printit=0&x=69&y=16)
Als Faustregel einfach merken: kleinere Netze gehen in größere rein, aber umgekehrt nicht. Deshalb plant man sowas auch gern als Tabelle ein wenig vor, dann kann man diese Berechnungen und Fehler vorher machen und nicht während dem Einrichten :)
> Inzwischen hat sich mir auch noch eine 2. allgemeine Frage ergeben. Gibt es Best Practices in welches Netz ich das NAS hänge? Aktuell hängt sie mit einem Port im LAN und einem weiteren Port im MGMT (für Pi-Hole).
Ich würde sagen, das hängt stark davon ab, ob bspw. das NAS direkt Kontakt von außen hat (also vom Internet aus erreicht werden kann/soll) oder nicht. Wenn es von extern erreichbar ist, packen es viele gern in eine Art "DMZ" oder extra Netz um das besser absichern zu können. Wenn Performance das Credo ist, dann sollte man es dorthin packen, wo viele Clients mit Zugriff darauf hängen, also bspw. LAN, denn dann kann ohne Umweg über die Firewall direkt drauf zugegriffen werden. Wenn Performance kein Problem sondern eher Security der Fokus ist, dann in ein Server oder DMZ Netz und man definiert Regeln auf der Firewall, wer drauf darf und wer/was nicht.
Ein zweites Bein sollte das NAS dann eher nicht haben, außer vielleicht für Management wenn man normale Operationen (Filetransfer etc.) und Management (WebUI, Console etc.) trennen möchte. Sonst macht ein NAS mit zwei Interfaces eher die Firewall sinnfrei, denn wird bspw. dein NAS von extern kompromittiert und hat Interface im LAN und Server Netz mit deinem PiHole kann jemand in beide Netze direkt rein ohne von der Firewall gehindert zu werden. Das umgeht die Security-Logik. Und kann je nachdem auch zu doofen Effekten oder asymmetrischem Routing führen wenn das Paket vom Client an das NAS plötzlich auf nem anderen Interface wieder zurückkommt weil das NAS zwei Beine in verschiedenen Netzen hat.
Das sollte man dann schon besser vorab ordentlich planen. :)