Navigation

    Netgate Discussion Forum
    • Register
    • Login
    • Search
    • Categories
    • Recent
    • Tags
    • Popular
    • Users
    • Search

    Hilfegesuch für Regeleinrichtung

    Deutsch
    3
    3
    301
    Loading More Posts
    • Oldest to Newest
    • Newest to Oldest
    • Most Votes
    Reply
    • Reply as topic
    Log in to reply
    This topic has been deleted. Only users with topic management privileges can see it.
    • S
      STyXxX last edited by

      Sehr geehrte Community,
      ich bin gerade dabei pfSense als Firewall für ein Studentenwohnheim einzurichten.

      Die Firewall befindet auf einem virtualisierten Gerät und hat 3 virtuelle Verbindungen, die wie folgt verteilt sind:

      • WAN = Internetverbindung
      • LAN = Managementverbindung
      • OPT1 = Useranschlüsse

      Gefordert ist, dass:
      1. OPT1 nicht mit LAN kommunizieren darf
      2. WAN nicht mit LAN kommunizieren darf
      3. WAN nur eingeschränkt mit OPT1 kommunizieren dar
            (näher: WAN -> OPT1 nur Port 0 - 1023; OPT1 -> WAN nur Ports >=1024)

      Leider scheitere ich bereits an den Forderungen 1 und 2, da ich trotz der Floatregeln im Bild (siehe Anhang) mit Testmaschinen im jeweiligen Netz auf die Firewall komme.
      Ich habe bereits, leider erfolglos, mehrere Kombinationen an Sources und Destinations getestet, und habe mich nun dazu entschieden mir Hilfe zu suchen.

      Danke im voraus.
      MfG

      1 Reply Last reply Reply Quote 0
      • jahonix
        jahonix last edited by

        ::)

        Opt1 address ist genau das: die Adresse des Opt Interfaces.
        Von der kommt aber gar kein Traffic, höchstens von Opt1 network. Gelle?
        Gleiches gilt für LAN address und WAN address.

        Dann willst Du sicherlich die Floating Regeln alle löschen und auf die einzelnen Interfaces verteilen. Macht mehr Sinn und ist für eine Anfänger deutlich übersichtlicher.

        Wenn in einer stateful Firewall eine Verbindung bestanden hat, dann sind die "states" dafür gesetzt. Wenn ich jetzt eine Regel einrichte, die das unterbinden soll, dann muss ich auch diese States erst zurücksetzen oder auf deren Timeout warten, bevor ich eine Erfolg der Regel sehen kann. Das war bei Dir sicherlich eines der Probleme.
        -> Diagnostics: States: Reset state

        Was hast du denn am WAN hängen, dass es "eingeschränkt mit OPT1" kommunizieren soll? Im Regelfall werden eingehende Verbindungen (also von WAN zu LAN oder OPT) geblockt, außer du betreibst dahinter Server. Das ist in einem Wohnheim eher selten … aber wer weiß.

        1 Reply Last reply Reply Quote 0
        • JeGr
          JeGr LAYER 8 Moderator last edited by

          Was Chris sagt. Zudem:

          1. OPT1 nicht mit LAN kommunizieren darf

          auf OPT1 Interface: a) block rule opt1 net nach lan net, b) allow any any

          2. WAN nicht mit LAN kommunizieren darf

          WAN darf per default GAR NICHTS. Das ist eine Firewall, keine Fritzbox :P

          3. WAN nur eingeschränkt mit OPT1 kommunizieren dar
                (näher: WAN -> OPT1 nur Port 0 - 1023; OPT1 -> WAN nur Ports >=1024)

          Warum? Port 0-1023 ist mal unsicher wie nur was, da da unter anderem Ports und Protokolle dabei sind die im Internet kein Mensch haben will oder die nicht verschlüsselt laufen, was man heute ebenfalls nicht haben will. Wenn man schon Ports REIN lassen will, dann nur die Dienste die man auch braucht. Dafür gibt es Aliase und damit kann man das problemlos zusammenfassen (SMTPS/Submission/POP3S/IMAPS bspw.). Aber mal kurz 1024 Ports aufzumachen … kurz nachdenken ... nein! Die andere Anforderung - OPT1 nach WAN >1024 hört sich nach Standard-Antwort Traffic bzw. Client Traffic an. Die Anforderung ist auch quatsch, entweder OPT1 spricht mit WAN, dann geht die Verbindung auf nen Server Port (meist <1024) - der Rest geschieht Stateful (das ist der Job der Firewall, dass man für den Antwort Traffic nicht auch noch Regeln machen muss) oder es geht andersherum, aber auch dann brauche ich keine Regel für Antwort Traffic.
          Da du nichts über die Anbindung schreibst (public/private IPs) sollte da noch ggf. NAT ausgeschaltet werden (wenns überall public Adressen sind) bzw. manuell konfiguriert, damit nur das genattet wird was sein muss.

          Trotzdem klingt gerade 3. für ein Wohnheim sehr dubios. Da stimme ich Chris zu.

          Gruß

          1 Reply Last reply Reply Quote 0
          • First post
            Last post

          Products

          • Platform Overview
          • TNSR
          • pfSense
          • Appliances

          Services

          • Training
          • Professional Services

          Support

          • Subscription Plans
          • Contact Support
          • Product Lifecycle
          • Documentation

          News

          • Media Coverage
          • Press
          • Events

          Resources

          • Blog
          • FAQ
          • Find a Partner
          • Resource Library
          • Security Information

          Company

          • About Us
          • Careers
          • Partners
          • Contact Us
          • Legal
          Our Mission

          We provide leading-edge network security at a fair price - regardless of organizational size or network sophistication. We believe that an open-source security model offers disruptive pricing along with the agility required to quickly address emerging threats.

          Subscribe to our Newsletter

          Product information, software announcements, and special offers. See our newsletter archive to sign up for future newsletters and to read past announcements.

          © 2021 Rubicon Communications, LLC | Privacy Policy