3
Pfsense VLAN trennen konfiguration
Hallo zusammen,
ich habe eine Pfsense anhand von diesem Forum installiert, besten Dank für die vielen Tipps hier !
Zur Kontrolle möchte ich die Konfiguration hier schnell zeigen ...
Es gibt 9 VLAN'S die nur ins Internet dürfen. Untereinander soll alles gesperrt sein.
Auch darf das pfsense Webgui nicht geöffnet bzw. angezeigt werden.
Ein VLAN (98) darf jedoch in alle anderen VLAN'S zugriff haben, auch das Webgui der pfsense soll erreichbar sein.
Es funktioniert alles wie gewünscht. Hab ich dennoch etwas übersehen oder falsch gemacht ?
Die VLAN 60 - 82
Das Admin VLAN
ich habe eine Pfsense anhand von diesem Forum installiert, besten Dank für die vielen Tipps hier !
Zur Kontrolle möchte ich die Konfiguration hier schnell zeigen ...
Es gibt 9 VLAN'S die nur ins Internet dürfen. Untereinander soll alles gesperrt sein.
Auch darf das pfsense Webgui nicht geöffnet bzw. angezeigt werden.
Ein VLAN (98) darf jedoch in alle anderen VLAN'S zugriff haben, auch das Webgui der pfsense soll erreichbar sein.
Es funktioniert alles wie gewünscht. Hab ich dennoch etwas übersehen oder falsch gemacht ?
Das Admin VLAN
Auf Facebook teilen
Auf Twitter teilen
Auf Reddit teilen
Auf Linkedin teilenBitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 2102428083
Url: https://administrator.de/forum/pfsense-vlan-trennen-konfiguration-2102428083.html
Ausgedruckt am: 23.12.2024 um 08:12 Uhr
3 Kommentare
Neuester Kommentar
Hi,
in deinem Regelwerk habe ich 1 Fehler festgestellt.
1. verwende Drop anstelle von Reject.
Drop funktioniert nur bei TCP.
Ich selber setze die Regeln etwas anders als du.
ich kann dann bei Bedarf genaueres Loggen einschalten.
- IPv6 any protocol Source any to Destination any -> Deny
- Separator <Access to Firewall>
- IPv4 ICMP from x_VLAN net to Firewall -> Allow
- IPv4 TCP/UDP DNS from x_VLAN net to Firewall -> Allow
- IPv4 TCP/UDP NTP from x_VLAN net to Firewall -> Allow
- Separator <Access to private networks>
- IPv4 any from any to RFC1918 -> Deny
- Separator <Access to Internet>
Hier Regeln für Zugriff auf Internet
- IPv4, Source immer x_VLAN net -> allow benötigte Ports
- IPv4, from any to any -> Block , logging standardmäßig nicht enabled, falls benötigt (temporär) einschalten.
Gruß
CH
in deinem Regelwerk habe ich 1 Fehler festgestellt.
1. verwende Drop anstelle von Reject.
Drop funktioniert nur bei TCP.
Ich selber setze die Regeln etwas anders als du.
ich kann dann bei Bedarf genaueres Loggen einschalten.
- IPv6 any protocol Source any to Destination any -> Deny
- Separator <Access to Firewall>
- IPv4 ICMP from x_VLAN net to Firewall -> Allow
- IPv4 TCP/UDP DNS from x_VLAN net to Firewall -> Allow
- IPv4 TCP/UDP NTP from x_VLAN net to Firewall -> Allow
- Separator <Access to private networks>
- IPv4 any from any to RFC1918 -> Deny
- Separator <Access to Internet>
Hier Regeln für Zugriff auf Internet
- IPv4, Source immer x_VLAN net -> allow benötigte Ports
- IPv4, from any to any -> Block , logging standardmäßig nicht enabled, falls benötigt (temporär) einschalten.
Gruß
CH
Hallo.
Ich halte das wie @ChriBo.
Suksessive die erlaubten Ports oder Alias Gruppen pro Schnittstelle eintragen und am Ende eine Block any / any Regel. Diese ist zwar überflüssig, sieht aber sauber aus und man kann die Regel überprüfen, wie oft diese schon "getroffen" wurde.
Bei der Verwendung von Reject statt Block bekommt der "Zurückgestoßene" ja immer mit, dass er unerwünscht war. Bei einem Block latscht man da in eine Timeout irgendwann, als wenn nichts anwortet.
Im internen Netzwerk jetzt zunächst nur teilweise relevant, es sei aber erwähnt.
Wie auch @ChriBo schrieb, nicht vergessen den Zeitbezug zu definieren bzw. zu erlauben:
Kann manchmal knallen, wenn ein Gerät keine korrekte Zeit bekommt.
Gruß
Marc
Ich halte das wie @ChriBo.
Suksessive die erlaubten Ports oder Alias Gruppen pro Schnittstelle eintragen und am Ende eine Block any / any Regel. Diese ist zwar überflüssig, sieht aber sauber aus und man kann die Regel überprüfen, wie oft diese schon "getroffen" wurde.
Bei der Verwendung von Reject statt Block bekommt der "Zurückgestoßene" ja immer mit, dass er unerwünscht war. Bei einem Block latscht man da in eine Timeout irgendwann, als wenn nichts anwortet.
Im internen Netzwerk jetzt zunächst nur teilweise relevant, es sei aber erwähnt.
Wie auch @ChriBo schrieb, nicht vergessen den Zeitbezug zu definieren bzw. zu erlauben:
Kann manchmal knallen, wenn ein Gerät keine korrekte Zeit bekommt.
Gruß
Marc
Du meintest sicher Reject funktioniert nur bei TCP ?! 
Das Management und dessen Zugriff kann man statt Regeln an jedem VLAN auch einfacher über die Anti Logout Rule lösen. Ist etwas effizienter aber alles letztlich eine Frage der Kosmetik. Eis gibt viele Wege nach Rom...
Und ob man IPv6 generell totlegt und das sinnvoll ist muss man sich auch fragen.
Die Deny Regel der RFC 1918 ist eigentlich überflüssig, denn es ist eh alle DENied was nicht explizit erlaubt ist. Eine Deny any any ist also immer explizit am Ende des Regelwerkes ohne das man es konfiguriert.
Das Management und dessen Zugriff kann man statt Regeln an jedem VLAN auch einfacher über die Anti Logout Rule lösen. Ist etwas effizienter aber alles letztlich eine Frage der Kosmetik. Eis gibt viele Wege nach Rom...
Und ob man IPv6 generell totlegt und das sinnvoll ist muss man sich auch fragen.
Die Deny Regel der RFC 1918 ist eigentlich überflüssig, denn es ist eh alle DENied was nicht explizit erlaubt ist. Eine Deny any any ist also immer explizit am Ende des Regelwerkes ohne das man es konfiguriert.
