[SOLVED] pfSense Interfaces & Rules

cyruz

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)

(rot = meine WAN IP)
Die 65.52.150.47 auf 443 hört auf :
zu 4.) geändert
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

Regeln WAN Interface

Floating

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

nodau

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.

viragomann

Hallo,

das Log zeigt dir doch die Regel, die den Zugriff erlaubt:

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

nodau

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.

cyruz

@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)
Allow IPv4 * MM * * * LAN

States gekillt ...

Erneuter Test mit dem RasPlex:
Erreichbarkeit NAS auf Port 32400

Prinzipiell i.O (laut Log)

Zugriff auf INet Adressen verboten

Prinzipiell i.O, (was auch immer der RasPlex da Extern anfunken will)

GDM Autodiscovery

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 ...

100fach "Deny"-Hits auf P2MP Multicast Adresse

INet geblockt - sehr schön

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

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 !

nodau

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

cyruz

@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 ...

...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)

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

@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

nodau

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.

cyruz

@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.

nodau

Na dann sollte ja heute Abend alles laufen.

cyruz

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

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

Datenvolumen Mobile & Leitung zu Hause gibt´s her...

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)

nodau

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.

cyruz

@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 !

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

cyruz

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

nodau

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

cyruz

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.

nodau

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.