pfSense (VM) hinter pfSense
-
Danke funktioniert!
Wie kann ich den Zugriff auf ein weiteres Netz unterbinden, z. B. 10.8.0.0/24? -
Selbe Regel nochmal mit Destination !10.8.0.0/24
-Rico
-
Super! Danke für die schnelle Antwort!
Eine Frage habe ich allerdings noch.
Ich würde gerne aus dem Netz 10.0.0.0/24 auf das Netz 10.0.77.0/24 zugreifen, das geht zur Zeit nicht. -
In der WAN Interface Konfiguration "Block private networks and loopback addresses" deaktivieren:
und entsprechende Firewall Regel für das WAN Interface anlegen:
-Rico
-
Sobald ich einen zweiten Eintrag mache, z. B. !10.8.0.0/24 kann ich 10.0.0.0/24 wieder erreichen?! Das sollte nicht so sein. Ich habe jetzt alle "gesperrten" Netzwerke zu einem Alias zusammengefasst, damit klappt es.
Betreffend dem Zugriff von 10.0.0.0/24 auf 10.0.77.0/24 ...
Ich habe die Regel im WAN IF von der pfSense2 eingefügt. Hat nicht funktioniert.
Gruß
Thomas -
Ja Denkfehler. ;-)
Zwei Destination Invert Regeln mit der selben Source macht natürlich keinen Sinn, denn die Erste hebelt die Zweite aus die dann nie getroffen wird. Eine mögliche Lösung mit dem Alias hast du ja aber schon selbst gefunden. :-)Bzgl. Zugriff von 10.0.0.0/24 auf 10.0.77.0/24 wirst du auf der ersten pfSense noch eine static Route setzen müssen, damit die auch weiß wohin Pakete müssen die ins 10.0.77.0/24 Netz sollen.
Sollte eigentlich gehen wenn du ein Gateway anlegst auf pfSense1 mit der IP von pfSense2 im 10.0.0.0/24 Netz und dann static Route auf pfSense1 Netz 10.0.77.0/24 auf das gerade angelegte Gateway.-Rico
-
Hi,
mach es einfacher: Definiere ein Alias "RFC1918" und packe da alle privaten Netzbereiche rein:
- 10.0.0.0/8
- 172.16.0.0/12
- 192.168.0.0/16
Dann aufbauen wie folgt:
- erstelle eine Reject Regel auf LAN mit Source "LAN net" und Destination "RFC1918"
- erstelle deine Pass any Regel (ohne das !<IPxy> einfach nur mit LAN net als Source)
Jetzt sind auf dem LAN alle Zugriffe auf private IPs geblockt und NUR der Traffic an echte IPs (im Internet) ist erlaubt. Das blockt dir auch Netze die du sonst ggf. im 10er Bereich vor dem Testnetz noch benutzt.
Zugriff vom "WAN" also eigentlich deinem normalen LAN ins TestLAN gehen nur, wenn du
- wie von @Rico beschrieben den Private Net Block auf dem WAN rausnimmst und
- dann eine Allow Regel baust mit source WAN net (sollte ja dein 10er Netz sein) auf LAN net.
- deiner pfSense1 (also deiner richtigen Firewall, nicht der VM!) eine Route beibringst, dass 10.0.77.0/24 (dein TestLAN) via 10.0.0.220 erreicht wird, denn deine LAN Clients können natürlich nix mit dem 77er Netz anfangen und schicken das dann ans Default Gateway, die pfSense 1 hoch.
Gruß Jens
-
Vielen Dank! Passt perfekt!
Einzig die Auflösung funktioniert nicht ganz:
Als Client im Netz 10.0.0.0/24 kann ich auf die pfSense2 via 10.0.77.1 zugreifen, jedoch nicht via pfSense.test.net. Als Client im Netz 10.0.77.0/24 klappt das. Wie kann ich die Auflösung auch aus dem pfSense1 Netz ermöglichen?
LG
Thomas -
gleiche Antwort Thomas: dein Client im Netz 1 wird die Sense aus Netz 1 Fragen, die kennt den Namen nicht. Schreib ihn als Host Override in die dns resolver Einstellung der Sense 1 rein mit der 10.0.0er Adresse, dann klappt's!
BTW nimm als Testdomain lieber .test, also sowas wie net.test oder lab.test
https://en.m.wikipedia.org/wiki/.test.test und .example sind ähnlich den Dokumentations IP4 oder IP6 ranges spezifiziert, dass sie nie vergeben werden dürfen und somit auch nie mit tatsächlichen IPs oder DNSen kollidieren. Sprich kannst du intern komplett nutzen wie "echt" ohne Probleme wie bspw damals AVM als .box plötzlich offizielles TLD wurde ;)
-
Nochmals danke!
pfsense.test.net (=pfsense2) kann ich jetzt von jedem Client im Netz 10.0.0.0/24 erreichen. Andere Clients wie z. B. ap.test.net nicht (nur via die IP Adresse). Muss ich für jeden Client einen Override anlegen? Geht ja nicht, da ja nur die pfSense eine IP im 10.0.0.0/24 Netz hat.
-
OK wenn du test.net generell auf der zweiten Lab-VM-Sense verwalten willst (bzw. deren unbound die verwalten soll), dann kannst du statt eines Host Overrides von pfsense.test.net auf 10.0.0.220 lieber einen Domain Override von test.net auf 10.0.0.220 machen (musst dann aber sicherstellen, dass DNS, also udp/53 auf dem WAN der zweiten pfSense erlaubt ist sowie unbound auf alle Interfaces lauscht). Dann wird für xyz.test.net immer die zweite pfSense gefragt und diese sollte dann per DHCP und manuell vergebene host overrides im dortigen unbound dann alle Adressen parat haben.
Würde trotzdem eher lab.test oder test.example nehmen ;)
Gruß
-
Klappt nicht! Wenn ich "Domain Override: lab.test" statt "Host Override: pfSense.lab.test" aktiviere, wird kein Name im 10.0.77.0/24 Netz aufgelöst. Mit Host Override nur "pfSense.lab.test.
(Ich habe die Test-Domain wie empfohlen geändert!)pfSense1
pfSense2
Zugriff als Client aus 10.0.0.0/24 auf IP Adresse im Netz 10.0.77.0/24 funktioniert.
-
Hast du den DNS-Zugriff auf der 2. pfSense am WAN auch erlaubt?
-
Ich habe auf pfSense2/WAN alles aus 10.0.0.4/24 freigegeben.
-
Dann mach mal einen kurzen Test von deinem Client (Windows? Linux?) und frage bspw. pfsense.lab.test direkt von der 10.0.0.220 an.
Windows: > nslookup pfsense.lab.test 10.0.0.220
Linux: > host pfsense.lab.test 10.0.0.220Dann siehst du ja ob du überhaupt eine Antwort bekommst :) Wenn nicht, muss man da an pfs2 oder den Regeln nochmal nachbohren.
-
Komm einfach nicht dahinter ...
nslookup pfsense.lab.test 10.0.0.220
nslookup 10.0.0.220
FW Rules pfSense2 WAN
FW Rules pfSense2 LAN
-
Steht im oberen Lookup: query refused!
Das heißt dein Unbound auf der zweiten Sense gibt keine Antwort. Unbound mit freigegebenen Netzen konfiguriert?
DNS Resolver / Access List ein Netz (lokal) eingetragen? -
Unter Access List auf pfSense2 ist nicht eingetragen!
Resolver/pfSense2:
-
Dann schau mal in die Resolver Logs ob da was zu sehen ist. Query refused kommt an der Stelle ja nicht von ungefähr :)
Edit: Wenn in Access Lists nichts drin steht, trage mal die beiden Netze auf LAN und WAN testhalber ein :)
-
Ich habe mal beide Netze (10.0.0.0/24 und 10.0.77.0/24) in die Access List auf der pfSense2 eingetragen.
nslookup pfsense.lab.test 10.0.0.220
bringt jetzt folgendes Ergebnis
Das unbound-log zeigt keine Fehler.
