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

    Verständnisfrage "opt1 subnet" zu "any"

    Scheduled Pinned Locked Moved Deutsch
    4 Posts 2 Posters 2.2k Views
    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
      shiversc
      last edited by

      Hallo,

      ich Pflege gerade pfSense in meine Landschaft ein. Wirklich tolle Distribution, die eine Spende verdient.

      Für meine Gäste soll ein WLAN her, welches die SSID der Accesspoint mit einen VLAN zur pfsense verbindet. Das klappt so weit ganz gut, ich bin zu frieden.

      Jetzt habe ich versucht Regeln anzulegen für die Kommunikation aus dem Subnet des opt1 Netzes. Da sind mir einige Sachen aufgefallen.

      Wenn ich z. B. ICMP, HTTP usw regele, mit der Regel "opt1 subnet" <–> "any" dann ist alles Okay. Gern würde ich die Regel ab so haben, dass der Verkehr über das WAN geht. Wähle ich "opt1 subnet" <--> wan address/wan subnet dann ist die Firewall zu.
      Habe ich hier ein Verständnisproblem?
      Bzw: was heißt "any" genau, im Fall des VLAN getaggten opt1 Traffics?
      Wenn ich any wähle, dann kann kein Client aus dem opt1 subnet nach lan. Das ist auch gut so, soll ja schließlich so sein. oder werfe ich hier was durcheinander?

      1 Reply Last reply Reply Quote 0
      • GruensFroeschliG
        GruensFroeschli
        last edited by

        Wenn ich z. B. ICMP, HTTP usw regele, mit der Regel "opt1 subnet" <–> "any" dann ist alles Okay. Gern würde ich die Regel ab so haben, dass der Verkehr über das WAN geht. Wähle ich "opt1 subnet" <--> wan address/wan subnet dann ist die Firewall zu.

        Any bedeutet genau das, jede IP die es gibt.

        opt-subnet <–> any bedeutet, dass das opt-subnet mit allen IP's kommunizieren darf.
        opt-subnet <--> wan-address/wan-subnet bedeutet, dass das opt-subnet nur mit IPs welche im WAN-subnet/WAN-address sind kommunizieren darf.
        Da irgendwelche Server im Internet normalerweise nicht um Subnet direkt an deinem WAN liegen willst du das wohl nicht ;)

        Wenn dein Ziel ist, dein WLAN ins Internet zu lassen, aber kein Zugriff auf die lokal Netzwerke zu geben.
        1: Erzeuge ein Alias mit all deinen subnetzen.
        2: Erzeuge eine einzelne Firewallregel auf dem opt-interaface:
        allow: protocol: any, source: opt-subnet, source-port: any, destination: !Alias (nicht dein alias), destination-port:any
        Mit einer solchen Regel lässt du Traffic zu für alle destinations welche NICHT in deinem Alias sind (sprich das internet). Alles was nicht dieser Regel entspricht (destination in deinen lokalen netzen) wird von der default-block-rule gedroppt.

        We do what we must, because we can.

        Asking questions the smart way: http://www.catb.org/esr/faqs/smart-questions.html

        1 Reply Last reply Reply Quote 0
        • S
          shiversc
          last edited by

          Okay, probiere ich doch glatt aus.

          Nur habe in eine kleines Problem, wir sind ein internationales Unternehmen, wo alle Standorte der Welt geroutet sind, vom Prinzip her, kann ich alle Netze in allen Standorten erreichen, sofern ich sie kenne.
          Ich kenne viele Netze, vielleicht sogar fast alle, aber bestimmt nicht alle.

          Was kann ich da tun?

          1 Reply Last reply Reply Quote 0
          • GruensFroeschliG
            GruensFroeschli
            last edited by

            Ich gehe mal davon aus, dass dein Unternehmen intern private Adressen verwendet?
            Wenn du das "lokale-netze" alias machst, füge einfach alle privaten Adressen hinzu
            Nach RFC1918 sind das:
            10.0.0.0/8
            172.16.0.0/12
            192.168.0.0/16

            Wenn du die Regel wie vorhin mit dem invertierten Alias erzeugst, dann braucht es noch eine zweite Regel welche den Zugriff auf den DNS forwarder der pfSense zulässt.
            Ein Beispiel aus einem meiner Setups ist als Screenshot angehängt.

            rule.png
            rule.png_thumb

            We do what we must, because we can.

            Asking questions the smart way: http://www.catb.org/esr/faqs/smart-questions.html

            1 Reply Last reply Reply Quote 0
            • First post
              Last post
            Copyright 2025 Rubicon Communications LLC (Netgate). All rights reserved.