[SOLVED] pfSense Interfaces & Rules



  • Moin zusammen,

    ich bräuchte dringend mal eine andere Sichtweise, da ich atm bei meinem Setup nicht weiterkomme ...
    Aktuell läuft pfSense 2.4.4-p3 auf einer APU.4C4 .

    • igb0 = WAN (PPPoE Telekom FibreModem)
    • igb1 = LAN (192.168.5.0/24) "Hausnetz" ... hier hängt der Switch (Netgear GS116Ev2), SynoNAS und meine Arbeitsstation dran
    • igb2 = VoIP 172.20.20.0/24 (Fritte 7490 die aktuell noch für´s WLAN zuständig ist, jedoch von MSSID-fähigem Zyxel AP abgelöst wird, wenn Grundsetup steht); danach nur Telefonie (funzt)
    • VLAN50 = Multimedia (192.168.50.0/24) hängt genau ein RasPlex und ein SmartTV mit Plex App dran. Switch Ports Untagged in VLAN50 -> geht soweit
    • VLAN30 / 40 werden WLAN Intern und WLAN Guest. WLAN Intern soll übliche Verdächtige (Smartphones/Tablets) inkl. WLAN-fähige Schalter/Steckdosen abdecken und den Smartphones BackUp auf die Syno im Hausnetz. Dem schaltbaren WLAN Zeugs würde ich gerne den Zugriff aufs WAN verweigern, außer Port 123 NTP für Zeit/Wetter-gesteuerte Aktionen (App ELESION) - per OVPN zusätlich von Extern die Möglichkeit haben per Smartphone die Schalter/Steckdosen zu steuern. WLAN Guest -> kein Rätsel, nur für Gäste; kein DNSBL, komplett an meinem Geraffel vorbei straight raus !
    • OVPN (10.8.8.0/24) - kompletter Traffic durch Tunnel, per ACL auf pfBlockerNG -> AD & Trackingfrei unterwegs -> geht, jedoch kein Zugriff (mehr) auf das schaltbare Steckdosen/Schalter-Geraffel

    Ebenfalls bekomme ich den RasPlex (192.168.50.11) in VLAN50 nur mit Scheunentorregel dazu, die Synology (192.168.5.80:32400) zu discoveren. Deaktivere ich die Scheunentorregel und breche den Zugriff auf "LAN Address" der Syno runter, so kann er zwar darauf zugreifen, kann jedoch trotz Block VLAN50 to WAN Regel über das LAN Interface ins Netz ☹
    53f17600-9eb0-466b-b400-95bb34f6c79e-image.png
    a0d3684e-60d7-433b-853a-342c9627309e-image.png

    Log:
    5af72c81-8fb2-4e2b-a4e2-df57b23c969f-image.png
    Korrespondierende Regel besagt doch:
    "Lass alles von VLAN50 nach irgendwo AUSSER WAN"
    8d41e2ef-db19-41ac-a27e-ec5ccfdafb5e-image.png
    Oder habe ich mich hier vertan ?

    Besten Dank !
    cyruz



  • Moin,

    hier geht's ja ab. Erstmal zum Wesentlichen.

    1. deine DNS Regel für Plex macht nur Sinn, wenn es andere Geräte im Subnet nicht dürfen. Da du aber weiter unten allen Geräten den Zugriff erlaubst, kannst du diese Regel rausschmeißen.

    2. bei deiner Block MM to WAN Net Regel solltest du auch das WAN Net angeben und nicht WAN Address.

    3. die EasyRule kann auch raus, da dein MM Subnet keinen Internet Zugriff hat.

    4. deine VLAN50 to any Regel kannst du auch so anpassen: IPv4 * MM Net * * * * none. Grund, es ist ja nur noch das Lan Subnet offen. Und da du vorher bereits alle anderen Netze blockiert hast, kannst du bei dieser Regel sogar any to any machen.

    5. Somit entfallen unten, ab Plex Remote Control, alle weiteren Regeln.

    Nach der Änderung entweder States löschen oder die Sense neustarten.



  • Moin,

    • zu 1.: deaktiviert
    • zu 2.: korrigiert
    • zu 3. : leider doch ! Das ist ja das Problem ... beide Clients im MM VLAN kommen raus, was Sie ja nicht sollen. Die brauchen/sollen lediglich auf die Syno (192.168.5.80 u. 81 Port 32400)
      877eb3d0-a7ce-46d9-8989-45035c7a27d1-image.png
      5650dd1e-06bf-41ba-ba93-8700bf61133f-image.png (rot = meine WAN IP)
      Die 65.52.150.47 auf 443 hört auf :
      d3181b0c-8abe-4488-b0ed-629b06189761-image.png
    • zu 4.) geändert
      fb555e8e-83f7-4f4b-bf38-59ae38af7cfe-image.png
    • zu 5.) done

    Trotz der Regeln kann ich von beiden Clients Ressourcen im INet abgreifen (siehe FW Logs) ... Nach den Korrekturen die Sense durchgestartet = same ...

    Regeln LAN Interface
    42cecb0e-debf-41bd-9ede-2757fe3ac2c4-image.png

    Regeln WAN Interface
    4932eacd-786d-467e-9b0a-3a6fedc4bfe4-image.png

    Floating
    a61dbcf0-aeeb-47fe-8fad-2b60c124e905-image.png

    Wenn ich noch was zu NAT Mappings / Port Forwards zeigen soll, tu ich das gerne. Im Endeffekt NAT SIP für VOIP der Fritte, paar Ports für Weboberfläche / Plex nach draußen und "doppelter Boden" zum Erzwingen von DNS Anfragen der Interfaces durch den local Resolver.

    Grüße



  • Wenn du bei vlan50 alle Regeln deaktivierst, kommst du dann trotzdem ins Internet?

    Theoretisch dürfte das nicht möglich sein. Wenn doch, liegst vielleicht an deinen vlan Einstellungen.

    Poste mal bitte nochmal deine MM Regeln.



  • Hallo,

    das Log zeigt dir doch die Regel, die den Zugriff erlaubt:
    13508bd8-351c-4772-9aea-0ec9d5d3a704-grafik.png

    Also die Regel "Allow ANY from VLAN50 to LAN" am MULTIMEDIA Interface.
    Vermutlich erlaubt die auch andere Ziele als LAN. Dass das so im Namen steht, reicht eben nicht aus.

    Grüße



  • Wenn's so nicht funktioniert, würde ich dann nur den Zugriff auf das LAN Net erlauben. Also Allow IPv4 * MM * * * LAN. Vorher wieder die DNS Regel aktivieren, damit die Namensauflösung funktioniert. Dann brauchst du auch die Block Regeln nicht.

    Und die !WAN Net Regel blockiert auch nur den Zugriff auf die lokalen IPs des WAN Subnets. Somit funktioniert sie nicht, wie du willst.

    Deshalb so wie oben beschrieben nur den Zugriff aufs LAN Subnet erlauben. Dann sollte es klappen.



  • @bahsig said in pfSense Interfaces & Rules:

    Wenn du bei vlan50 alle Regeln deaktivierst, kommst du dann trotzdem ins Internet?

    Theoretisch dürfte das nicht möglich sein. Wenn doch, liegst vielleicht an deinen vlan Einstellungen.

    Poste mal bitte nochmal deine MM Regeln.

    Nein ! Wenn ich alle deaktiviere, greift Default Deny - alles was nicht explizit erlaubt ist ... usw. Dann erreiche ich gar Nichts - so, wie es sein soll.

    @viragomann said in pfSense Interfaces & Rules:

    Vermutlich erlaubt die auch andere Ziele als LAN.

    Scheint so ... wenn einem jedoch die richtige Sichtweise fehlt, wie die Sense mit den Regelwerken umgeht und "wie" sie´s haben will, ist man halt verunsichert. Meine Herangehensweise war ja nicht per se "falsch" - nur nicht das, was die Sense haben will. Und dass die "Description" keine Wirkung auf die Regel selbst hat, ist mir auch bewusst.

    @bahsig said in pfSense Interfaces & Rules:

    Wenn's so nicht funktioniert, würde ich dann nur den Zugriff auf das LAN Net erlauben. Also Allow IPv4 * MM * * * LAN. Vorher wieder die DNS Regel aktivieren, damit die Namensauflösung funktioniert. Dann brauchst du auch die Block Regeln nicht.

    • DNS Regel reaktiviert (und aufs MM Net als Source geändert)
      700e4c34-2ff9-422d-8298-0c16971f24b7-image.png
    • Allow IPv4 * MM * * * LAN
      413fdb6d-81bc-4e13-9064-6a38dcaf9c64-image.png
      States gekillt ...

    Erneuter Test mit dem RasPlex:
    Erreichbarkeit NAS auf Port 32400
    a3aec60b-83ad-4de9-95a8-acfefe4972bc-image.png
    Prinzipiell i.O (laut Log)

    Zugriff auf INet Adressen verboten
    b822f24a-7aeb-49ba-b91f-a92af14a3811-image.png
    Prinzipiell i.O, (was auch immer der RasPlex da Extern anfunken will)

    GDM Autodiscovery
    8560d7cc-752d-42b1-90b2-c202e798e162-image.png
    Plex-eigenes Autodiscovery Protocol (32410 - 32414) auf BC-Adresse. Wird wahrscheinlich (richtigerweise) einfach nicht ins Zielsubnetz weitergereicht (?)

    Erneuter Test mit der PlexApp Samsung TV:
    Schonmal gut ...
    c0f50533-d4ac-42a3-b6c9-721c910ebf61-image.png

    100fach "Deny"-Hits auf P2MP Multicast Adresse
    4683045d-8286-4f1b-848f-b4b2aef84430-image.png

    INet geblockt - sehr schön
    f52a8bfc-354e-4161-963e-071a41c548ac-image.png

    Jedoch startet auf dem SmartTV nicht einmal die PlexApp .... Verbindungsaufbau ... schreit ins Netz und bekommt keine Antwort. Lösung: Multicast & IGMP explizit erlauben ?

    Beim RasPlex die Broadcast-Geschichte auf 1900 UPD explizit erlauben ? Sollte doch beides mit den EasyRules aus dem Log zu erstellen sein. Hatte ich - zumindest für den RasPlex (...50.11) - siehe ganz oben - schon in meinem Erstsetup drin

    204002ae-98d6-457c-8d91-dcc7238f1663-image.png

    Sorry für die vielen Pics - soll halt nachvollziehbar sein und beim Lösungsweg helfen .... Ich bin für alles offen und auch Re-Design nicht abgeneigt, sofern sinnvoll und kontrollierbar. Möchte natürlich nur das freigeben, was für den jeweiligen Zweck wirklich nötig.

    Besten Dank !



  • Nicht, dass der SmartTV zwingend ne Internetverbindung braucht, um AppUpdates zu ziehen.
    Warum Autodiscover geblockt wird, kann ich nicht nachvollziehen. Deine Regel erlaubt alle IPv4 Protokolle, die von MM zu Lan gehen. Vielleicht funkt noch eine Floating Rule dazwischen.

    edit: broadcasts über Subnetze hinweg, ist ein Thema für sich. Versuche mal die Broadcastadresse des LANs explizit als allow rule anzugeben und packe sie vor die MM to LAN Regel

    edit: broadcasts werden von der Sense nicht in andere Netze geroutet, außer man hat ne Bridge oder ein IGMP-Proxy



  • @bahsig said in pfSense Interfaces & Rules:

    Nicht, dass der SmartTV zwingend ne Internetverbindung braucht, um AppUpdates zu ziehen.
    Warum Autodiscover geblockt wird, kann ich nicht nachvollziehen. Deine Regel erlaubt alle IPv4 Protokolle, die von MM zu Lan gehen. Vielleicht funkt noch eine Floating Rule dazwischen.

    Die Floating Rules ...
    932b9260-c4ac-4546-a91d-947af3575654-image.png
    ...beziehen sich ja nur auf die Erreichbarkeit des Unbound DNS Webservers, oder wie man das Teil halt schimpft. Die Andere verbietet unverschlüsselte DNS Anfragen auf #53 nach Extern

    Aber nu hab ich den Knoten etwas raus ! Der Smart TV öffnet die Plex App und findet sofort die Syno per Autodiscovery (Allow MultiCast P2MP)
    1c3471ce-a9bc-4928-98ca-b89785c7791a-image.png

    Mein Fehler lag wohl in der Betrachtungsweise der "invert match" Rulesets und wie ich das aufgebaut habe.

    Einzig der RasPlex findet nach wie vor meine Syno nicht ... Er "sucht" sich nen Wolf ...(da wo sonst die Bibliotheken angegeben sind steht über "SUCHEN"). Das Log spuckt dazu diverse externe Adressen aus, die der Rasplex versucht auf #123 (NTP) zu erreichen. Mir war jedoch so, als würde die Sense auch als NTP-Geber fungieren 😐
    025fc87c-a63b-41a0-a678-8a0724bd917f-image.png

    @bahsig: Ich danke dir schon mal vielmals für deine Unterstützung ! Ich teste morgen weiter - für mich ist heute Feierabend und der TV, an dem der RasPlex hängt, ist gerade durch meine bessere Hälfte belegt ✌



  • Moin, ändere mal am Plex den NTP Server auf die IP der Sense, wenn diese als Zeitserver in deinem Netzwerk fungiert. Wenn nicht, auf der Sense einfach den Zeitserver konfigurieren.



  • @bahsig Der NTP-Server der Sense lief natürlich nicht 😑 Nach dessen Aktivierung zeigten Hits der entsprechenden Regel, dass der RasPlex eine Zeit auf der 192.168.5.1 abfragt. Als ich das auf dem Client verifizieren wollte, zeigte diese irgendne Zeit aus 2018 ...

    Prüfe ich das auf unter Linux gegen per sntp -d sense.localdomain

    Ruperts-Air:~ meinuser$ sntp -d sense.localdomain
    sntp 4.2.8p10@1.3728-o Tue Mar 21 14:36:42 UTC 2017 (136.200.1~4588)
    kod_init_kod_db(): Cannot open KoD db file /var/db/ntp-kod: No such file or directory
    handle_lookup(sense.localdomain,0x2)
    move_fd: estimated max descriptors: 256, initial socket boundary: 20
    sntp sendpkt: Sending packet to 192.168.5.1:123 ...
    Packet sent.
    sock_cb: sense.localdomain 192.168.5.1:123
    2019-08-08 15:41:52.358644 (-0200) +0.013712 +/- 0.207317 sense.localdomain 192.168.5.1 s2 no-leap
    

    Zeit scheint korrekt ausgegeben zu werden.

    NTP-Log

    Aug 7 15:14:01	ntpd	64747	Listen normally on 15 igb1.50 192.168.50.1:123
    

    @cyruz said in pfSense Interfaces & Rules:

    Einzig der RasPlex findet nach wie vor meine Syno nicht ... Er "sucht" sich nen Wolf ...(da wo sonst die Bibliotheken angegeben sind steht über "SUCHEN").

    Mich beschleicht ein Layer 8 Problem .... und zwar gibt es beim RasPlex 2 mir bekannte Anmeldearten. Einmal per plex.tv/link , bei dem man seinen RasPlex per OnlineAccount verlinkt und er so "automatisch" seine entsprechend registrierten Server findet (...setzt natürlich Onlineverbindung voraus...und warum er beim booten ständig versucht externe Dienste zu erreichen). Und einmal eine "fixe" Verlinkung per IP / Port unter Angabe seines im Server hinterlegten Benutzers. Ich vermute mal, dass ich aus Gründen der Bequemlichkeit in der Testphase des Clients Ersteres gewählt habe. Werde also heute Abend einmal den RasPlex resetten und eine Offline-Verlinkung direkt zur Syno probieren.



  • Na dann sollte ja heute Abend alles laufen.



  • @bahsig In der Tat ... das tut es !

    299cc912-944a-45d3-8674-f01255022bf9-image.png

    • NTP Server (sense) fix im RasPlex hinterlegt
    • Link zur Syno per IP / Port klappt
    • externe Adressen werden brav geblockt

    RasPlex läuft nu auf nem anderen, frisch installierten RPi - d.h. der IP-Wechsel.

    Vielen, vielen Dank !!! 😎

    Das war der erste Streich. Nun folgt noch die WLAN Geschichte per Zyxel AP (NWA1123-AC-Pro):

    • WLAN Guest -> Wie bekomme ich VLAN 40 ins WAN mit DNS Auflösung am pfBlockerNG vorbei und ohne Zugriff auf meine andere Netze ?
    • WLAN Intern -> Zugriff per OVPN (Smartphone von unterwegs) auf die WLAN-fähigen Schalter, welche aktuell noch über die Fritte (VoIP-Netz) angebunden sind, jedoch selbst kein Zugriff ins INet brauchen - außer NTP Abfragen für Zeit/Wetter-gesteuerte Aktionen (App ELESION)

    OVPN ist bereits eingerichtet und funktioniert sehr gut. Nur eben der Zugriff auf das steuerbare WLAN Geraffel nicht. Auf andere Ressourcen (Fritte selbst & Repeater im gleichen Netz) komme ich per OVPN problemlos. OVPN hat eine Scheunentorregel

    aba83497-2184-4209-86a1-80458be2a12e-image.png
    356e50f9-34d4-4349-8e82-6d2d56ccca13-image.png
    6cc4fc45-3ed9-4e2d-b0ae-973ca00adeae-image.png
    Datenvolumen Mobile & Leitung zu Hause gibt´s her...
    470cbaba-4112-4947-a3bf-599d8e85d245-image.png

    • per ACL das OVPN Netz 10.8.8.0/32 auf den DNS Resolver
    • pfBlockerNG Listener auf das OVPN Netz gesetzt .... funktioniert tadellos !
    • OVPN & VoIP Netz any to any allow

    Ideen / Vorschläge ? (zu beidem)



  • Erstelle einfach einen Alias, der alle Netzwerke außer WLAN Guest enthält. Dann erstellst du eine Inversregel mit dem Alias als Ziel. Somit hast du Internet aber blockierst den Zugriff auf alle anderen Netze.

    Und bei OpenVPN die Netze in der Serverconfig hinzufügen, auf die du Zugriff haben willst.



  • @bahsig said in pfSense Interfaces & Rules:

    Erstelle einfach einen Alias, der alle Netzwerke außer WLAN Guest enthält. Dann erstellst du eine Inversregel mit dem Alias als Ziel. Somit hast du Internet aber blockierst den Zugriff auf alle anderen Netze.

    Danke ... es kann so einfach sein !
    8155285d-3960-4543-9c3e-06b1d4b6e051-image.png
    323137fa-4fd8-46f1-a4f5-98ad0d8eea5a-image.png
    Komme aus dem WLAN Guest brav ins Netz, aber auf absolut nix Internes ! 👌

    @bahsig said in pfSense Interfaces & Rules:

    Und bei OpenVPN die Netze in der Serverconfig hinzufügen, auf die du Zugriff haben willst.

    Nur nochmal kurz zusammengefasst ... das WLAN Geraffel hängt aktuell noch im WLAN provided by FritzBox (VOIP). WLAN der FritzBox hat Allow IP4 * to ** ** none .... OVPN ebenfalls ... ich kann alles vom OVPN Netz erreichen - auch alles im WLAN der FritzBox (VOIP). Ich kann die Steckdosen, etc. auch vom OVPN Netz aus pingen, nur nicht mehr über die App vom Smartphone mit VPN Verbindung steuern, was bin vor kurzem noch tadellos ging. Ich bekomme leider nicht mehr rekonstruiert, seit wann und das "warum".
    Kann also nicht ganz nachvollziehen, warum ich in der Server Config etwas angeben sollte. Du meinst bestimmt VPN -> OpenVPN -> Server -> Edit
    d13451f1-99da-42eb-a693-1fd60b2547ef-image.png



  • alle Pferde zurück ! Ich sag lieber nicht, was es war 😡 Auch das Steuern der WLAN-fähigen Geräte per VPN klappt.



  • Schön, dass jetzt alles so läuft, wie du dir das vorgestellt hast. Am besten oben noch den Thread als gelöst setzen.



  • Was mich natürlich trotzdem interessieren würde, was für die pfSense das WAN Interface sein soll, wenn nicht Internetzugriff (?) Ich kann natürlich Rulesets invertieren und das so lösen, wie ich´s nu gelöst habe .... aber für´s Verständnis - vielleicht kann mir das jemand erklären ...

    Wenn bei ner FortiGate am (phys.) Interface (i.e. "WAN") den I-Net Zugriff vom Provider anliegen habe, eine IPv4 Policy baue die besagt

    • Von Interface LAN (Aggr.) , Source: "IP/Alias der berechtigten Quellen" per Protokoll "Bla" mit Security Profile "Blubb" -> nach "WAN" -> Allow
      ...dann geht das auch raus. Bei der Sense offensichtlich nicht - ich möchte es halt einfach nur verstehen.


  • Moin,

    du sprichst doch vom Client nicht direkt das WAN Interface an, um ins Internet zu kommen, sondern die IP des LAN Interfaces (Gateway) an die der Client angebunden ist. Die Sense routet anschließend den Verkehr vom LAN zum WAN.
    Mit deiner Regel block LAN to WAN versuchst du den Zwischenschritt über die Sense zu umgehen, was folglich nicht möglich ist.


Log in to reply