[SOLVED] 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.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 ...
...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 ExternAber 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
-
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 !
- 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)
-
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 !
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
-
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.
- Von Interface LAN (Aggr.) , Source: "IP/Alias der berechtigten Quellen" per Protokoll "Bla" mit Security Profile "Blubb" -> nach "WAN" -> Allow
-
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.