Subcategories

  • 107 Topics
    1k Posts
    S

    📌 Ziel:
    Ich möchte mDNS-Discovery VLAN-übergreifend ermöglichen, damit ein PlexAmp-Client auf einem Raspberry Pi im IoT-VLAN über die PlexAmp-App auf meinem Smartphone über den Plex-Server im LAN automatisch entdecken und sich verbinden kann.

    Sobald sich mein Handy und der Plexamp Client (Headless) im selben Netzwerk befinden, funktioniert das Streaming.

    🧑‍💻 Netzwerkübersicht:
    Komponente Details
    Firewall pfSense (aktuell, mit Avahi-Paket)
    Switch/AP UniFi (Controller & Geräte aktuell)
    HomeNetz LAN – 192.168.8.0/24 (Plex + Roon Core)
    IoT IoT – 192.168.10.0/24 (Raspberry Pi mit Plexampheadless)
    Avahi Installiert auf pfSense, reflektiert zwischen LAN und IoT

    ✅ Konfiguration bisher:
    pfSense:
    Avahi installiert und aktiv
    mDNS-Repeater für LAN und IoT aktiviert
    Firewall-Regeln:
    any-to-any zwischen VLANs
    Zusätzlich: UDP 5353 → 224.0.0.0/8 mit „Allow packets with IP Options“

    UniFi:
    SSID „KugelMensch_IoT“ → VLAN IoT
    WLAN-Optionen:
    ✅ Multicast-Erweiterung aktiv
    ❌ Client-Isolation deaktiviert
    ❌ Multicast/Broadcast-Filter deaktiviert
    ✅ Erweiterte IoT-Konnektivität aktiv
    IGMP Snooping: (standardmäßig aktiv)

    🔧 Zusätzliche Firewall-Regeln getestet:
    Im VLAN IoT:
    ✅ UDP 5353 → 224.0.0.251, „Allow packets with IP Options“
    ✅ UDP 32414 → 192.168.8.0/24 (Plex GDM Discovery)
    ✅ TCP 32400 → Plex Server
    ✅ UDP 9003 + TCP 9100–9200 → Roon Core
    🧪 Beobachtungen:
    Multicast-Traffic wird sichtbar über tcpdump
    Clients empfangen die Antworten aber ggf. nicht korrekt
    IGMP Snooping evtl. blockierend (aber noch nicht deaktiviert getestet)

    Es scheint nichts zu funktionieren. Hat jemand noch eine schlaue Idee?

    Vielen Dank im voraus.

  • 80 Topics
    433 Posts
    JeGrJ

    Heute spontan OpenHouse im NSFW.pub. Gern einfach mal reinschauen, kann allerdings sein dass zwischendurch mal gerade keiner am "virtuellen Tresen" ist oder ich Getränke hole/wegbringe.

    Cheers :)

  • Update von thunderbird blocken.

    4
    0 Votes
    4 Posts
    562 Views
    A

    Alles klar, danke. Ich habe diese beiden Adressen nicht gefunden.
    Ich muss es über die Adressen machen, weil die Thunderbird-Benutzer weltweit verteilt sind, jedoch alle über diesen Router geleitet werden.

    Gruß, Arti.

  • 0 Votes
    8 Posts
    271 Views
    P

    Hi,

    ohne TLD läuft es wirklich viel entspannter, sprich es verändert sich nichts am SWAP-Verhalten im negativen Sinn.
    Zumal wer ProNs sehen möchte findet immer einen Weg oder Seite die nicht gelistet ist, zumindest die "bekannteren" Seiten sind für Jugendliche unter 18 nicht sofort erreichbar. Aber ich denke der Grundschutz ist damit schon gegeben.

    Wie es mit den Ads usw. und anderen BLs ist - da sehe ich noch immer die gleichen die sich im Log finden. Sieht somit auch nicht schlecht aus.

    Werde erst einmal es so belassen und diesen Thread damit schließen. Danke für die Unterstützung!

    Viele Grüße!

  • Fritz!Box 6660 - 2.5Gbit LAN1 <> pfSense Fehler

    23
    0 Votes
    23 Posts
    4k Views
    Bob.DigB

    @JeGr Hab es getestet und Du hattest, wie immer, recht. Es macht auch die Zwischenschritte.

    Clipboard01.jpg

    Musste aber erst meine andere Verbindung (1G) in Windows trennen, damit die herabgesetzte Verbindung (2.5G) genutzt wird, keine Ahnung warum (win<>win).

  • pfSense UserGroup (nächstes Meeting: #002)

    48
    3 Votes
    48 Posts
    6k Views
    JeGrJ

    So, kurz zur Info: Ich hab dieses allgemeine Thema was angepinnt bleibt erstmal "bereinigt" und alles vom ersten Meet&Greet in ein eigenes Thema gepackt. Sollte nicht noch was dazwischen kommen, gibt es dann bald auch nen Unterforum, wo die alle sortiert werden und wo man dann munter noch weiterdiskutieren kann bevor/nachdem die Meetings gelaufen sind, ohne hier das Überthema zuzuspammen ;)

  • VPN über pfSense PC und Fritzbox wechsel !

    9
    0 Votes
    9 Posts
    677 Views
    JeGrJ

    Nochmal zum mitschreiben:

    Es ist VÖLLIG egal ob deine Fritte BridgeMode kann oder nicht. Du kannst dahinter deine pfSense hängen und OpenVPN Server spielen lassen und es GEHT. Ob du es nun mit direktem Durchreichen via Bridge Modus machst und sich die Sense quasi selbst verbindet oder ob du die Sense IP-Technisch hinter die FritzBox hängst und per "Exposed Host" Funktion einfach jeden Port durchreichst ist völlig egal. OpenVPN ist da wesentlich einfacher und geselliger als der IPsec Kram und nicht umsonst deshalb oft die angenehmere Alternative und häufiger genutzt wenn man kann.

    Ob deine Fritte den Menüpunkt mit Bridge Modus hat oder nicht, kann ich wie gesagt nicht hellsehen. Normalerweise sollte sie es. Wenn beide selbstgekauft waren und die alte das hat, dann sollte es auch die neue haben. Das ist aber AVM Sache, da kann ich nichts zu sagen. Anscheinend gibt es Leute, die mit dem FBeditor die Funktion aktivieren konnten und dann das gleiche Menü haben wie ich auf der 6591. Verstehe zwar nicht ganz warum man jetzt gerade die 6660 so hyped, da sie IMHO auch nicht schneller als die 6591 ist, aber so what. Die HW soll ja nicht gerade sehr stabil sein momentan.

    Grüße

    Edit: Ich würde bei der Kaufentscheidung auch mit einbeziehen, dass die 6591 eine Providerbox ist. Sprich die wird in riesiger Stückzahl von Kabelanbietern abgenommen. Die 6660 (noch) nicht und hat demzufolge vielerorts keine Prio bei der Bugbeseitigung etc. weil die nur early adopter einsetzen.

  • 0 Votes
    57 Posts
    10k Views
    Bob.DigB

    Hab bei meinem VPN-Anbieter folgendes beobachtet, wenn als DNS Server 8.8.8.8 oder 1.1.1.1 genutzt werden, dann beantwortet der VPN Server selbst die Anfragen.

  • HE.net IPv6 Tunnel-User - Gegenstelle?

    2
    0 Votes
    2 Posts
    194 Views
    Bob.DigB

    Ich hab leider regelmäßig schon auf dem normalen WAN loss von ein paar Prozent (Pyur/Telecolumbus), hab den beobachteten loss beim TUNNELBROKERNET daher ignoriert. Als ich es damals eingerichtet habe, wollte ich zuerst Frankfurt nehmen, ein Pingvergleich sah dann aber Berlin deutlich im Vorteil, wo ich im übrigen auch wohne. 😉
    Läuft aber eh nicht viel drüber und dank dual-stack nutze ich wohl vorwiegend meinen ISP IPv6, welcher aber nur einen einzigen /64er zur Verfügung stellt...

  • Neue Netgate Hardware

    1
    1 Votes
    1 Posts
    293 Views
    No one has replied
  • Outbound NAT Mode: Hybrid / 3CX / OpenVPN TLS Error

    6
    0 Votes
    6 Posts
    496 Views
    JeGrJ

    @Fischermeister said in Outbound NAT Mode: Hybrid / 3CX / OpenVPN TLS Error:

    Also es geht ja nicht um den OpenVPN Eingang sondern Ausgang.

    Richtig ist aber egal wie oben beschrieben. Umstellung von Auto auf Hybrid - wie du unten im Screen selbst siehst - belässt alle Auto Regeln intakt und fügt nur bei Bedarf obendrüber noch manuelle Regeln ein. Daher ist eine Umstellung auf hybrid normalerweise völlig transparent und ändert nichts.

  • pfSense und Fritz!Box

    2
    0 Votes
    2 Posts
    589 Views
    W

    @beanz82

    An einem Telekom Glasfaseranschluss wird als Abschluss ein Glasfaser-Modem verwendet, welches direkt per CAT-Kabel mit einem physikalischen WAN-Port einer pfSense verbunden werden kann. Die Verbindung wird da per PPPoE über VLAN7 von der pfSense aufgebaut. Für Telefonie/WLAN kann man da eine Fritzbox dahinter im LAN betreiben. Oder auf LAN-fähige Telefone, Telefonanlagen oder eigene APs zugreifen.

  • Einfache Firewall Regel klappt nicht

    25
    0 Votes
    25 Posts
    2k Views
    JeGrJ

    Wenn ihr so nett wärt, mir noch ein paar Verständnisfragen zu beantworten:

    natürlich!

    hinter jeder Rule liegt ein "deny all"? Wenn ich AUS dem eigenen Netz1 die Verbindung in Netz2 erlaube, ist Netz3 automatisch geblockt?

    Nicht ganz. Es ist generell ein "block any any" auf jedem Interface stehend aktiv. Daher: alles was nicht explizit in Form von Regeln erlaubt wird, wird am Ende durch die "block any" Regel weggeworfen. Sieht man auch schön in den Firewall Logs, dass der meiste Kram wegen "default block rule" weggefiltert wird.

    Dadurch wäre es einfacher alle Regeln auf die ausgehenden Traffic anzuwenden

    Der Logik kann ich nicht folgen. Ausgehender Traffic ist überhaupt nicht auf den Interfaces filterbar. Zumindest nicht das, was man als ausgehend bezeichnet. Ausgehend wäre den Verkehr nicht eingehend beim Ankommen auf dem Interface bspw. LAN zu erlauben/blocken, sondern erst abgehend auf dem WAN bspw. bevor er ins Internet geht. Das ist so ohne weiteres nicht möglich. Technisch ist es das mit Floating Regeln, aber das willst du nicht. Das Filterprinzip der pfSense und generell von pf ist, den Traffic dort zu filtern, wo er DAS ERSTE MAL die Firewall betritt. Dort wird gefiltert, erlaubt oder verworfen, und dann weitergemacht. Hat man sich an den letzten Satz gewöhnt, ist das Regel erstellen auch recht einfach zu durchdenken.

    Wenn ich am Ende eine * * Rule setze, erlaube ich damit automatisch ins WAN Netz und das dahinter liegende Internet, sofern ich das WAN nicht zuvor geblockt habe

    Vielleicht wäre es einfacher, wenn du genauer schreiben würdest, was eine * * Rule ist. Ich gehe mal von "source any, destination any" aus? Wenn ja erlaubt das schlichtweg alles. Alles - egal ob legitim oder nicht darf dann vom Interface, auf dem die Regel liegt überall hin. Egal wo. Intern, extern egal. Sowas will man eigentlich nicht. Source sollte meistens das "XY_net" sein, also bspw. LAN_net wenn wir von innen nach außen oder innen nach innen reden. Nur auf dem WAN sind Regeln meistens von "any", ansonsten sollte das immer beschränkt sein, schon allein um Miskonfigurationen auszuschließen.

    Wenn ich vom Netz1 aus, nur eine IP im Netz2 freigeben möchte, muss ich zuerst die "Allow IP" sezten (denn dadurch werden keine weiteren Regeln mehr geprüft) und danach das ganze Netz2 ja noch "blocken", richtig?

    Das ist richtig. Erst die einzelne IP erlauben, dann das komplette Netz rejecten (blocken wäre intern hart, ich würde rejecten damit die Clients auch ne Antwort bekommen). Die zweite Regel ist aber wie Bob sagt nur nötig, wenn danach noch eine größere Allow Regel kommt. Wenn danach nichts mehr kommt, würde eh die block any Regel greifen.

    selbes wie oben für IP/Port .. danach muss ich erst das ganze Netz blocken

    Mutmaßlich ja, am konkreten Beispiel kann man das sicher besser erläutern.

    wenn ich vom Netz1 den Zugriff auf Netz2 komplett blocke, aber es kommt eine Kommunikation vom Netz2 ins Netz1 ... was passiert mit den Antwort Paketen. Diese sind ja wieder vom Netz1 nach Netz2. Die Kommunikation wurde aber aus dem Netz2 initiert und das klappt dann wohl mit den States

    Die Firewall ist "stateful", das solltest du ggf. nachlesen. Das heißt, dass bei Zugriff von N2->N1 - sofern die Verbindung per Regel erlaubt ist - ein State erzeugt wird, der diesen Traffic (hin & zurück) erlaubt. Es wird immer nur der Verbindungsaufbau gefiltert. Nicht der danach folgende Verkehr (und Rückverkehr), daher ist der Rücktraffic für eine stateful Firewall immer irrelevant da durch den State implizit gestattet. Bei Stateless Filtering, was viele sog. L3 Switche anbieten, ist genau das ein Problem, dort muss gezielt bei jeder Freigabe der Hin- und Rückverkehr konkret angegeben werden, ansonsten wird geblockt. Da das recht schnell komplex ausartet, will man das eigentlich nicht ;)

    Ansonsten kann ich nur auf den Freitag hinweisen: https://forum.netgate.com/post/932803
    Vielleicht ist das ja mal was für dich zum Frage in den Raum werfen :)

    Grüße

  • Wie Syncthing über mehrere Interfaces nutzen

    10
    0 Votes
    10 Posts
    806 Views
    JeGrJ

    Offizielle Doku?

    https://docs.syncthing.net/users/stdiscosrv.html
    https://docs.syncthing.net/users/strelaysrv.html

    Außerdem nützlich:

    https://docs.syncthing.net/users/security.html

    beschreibt was welcher Modus genau sendet.

  • Web Server: Domäne intern nicht erreichbar

    3
    0 Votes
    3 Posts
    621 Views
    S

    au mann ... danke ... das es so einfach ist hätte ich nicht gedacht ... klappt! ;)

  • Vodafone FttH

    9
    0 Votes
    9 Posts
    1k Views
    JeGrJ

    Das ist ne Verschlechterung der bisherigen Leistung, sollte man tatsächlich wegen Streß machen können. Aber ja, super Verbesserung 🙄

  • Fragen zum Netzwerktraffic debuggen

    4
    0 Votes
    4 Posts
    494 Views
    J

    Super, vielen Dank für eure Antworten, dann bin ich jetzt wieder ein Stückchen schlauer :-)

  • Pfsense 2.4.5 Port forwarding

    11
    0 Votes
    11 Posts
    889 Views
    S

    So, dummer Fehler, dass Tool lief nicht richtig bzw hat dazu noch den falschen port abgehört.
    Jetzt klappt alles einwandfrei von aussen intern.

    Vielen Dank Jungs!!

  • Beschreibung (Description) für DHCP Host

    2
    0 Votes
    2 Posts
    247 Views
    JeGrJ

    Andersrum gefragt: was spricht denn dagegen, dass die Dinger ne feste IP bekommen (an Hand ihrer MAC)? Gerade wenn mehrere rumschwirren ist das doch auch einfacher, wenn man einen sucht oder konfigurieren will, dass man direkt seine IP weiß/raussuchen kann anstatt sich auf DHCP zu verlassen. Netzwerkhardware bekommt bei mir immer fixe IPs (Switche, APs, ggf. auch DLAN wenn benötigt, etc.) :)

    Aber du kannst bei den Mappings natürlich auch das IP Feld leer lassen. Steht sogar als Kommentar drunter 😄

    If no IPv4 address is given, one will be dynamically allocated from the pool.

  • Webinterface zugangs Probleme ohne IPv4 Upstream Gateway

    3
    0 Votes
    3 Posts
    306 Views
    JeGrJ

    @NoX_Noa said in Webinterface zugangs Probleme ohne IPv4 Upstream Gateway:

    Falls weitere Infos gebraucht werden bitte melden.

    Jap, so ziemlich alles aus dem Sticky hier im Forum 😄
    Version, Screenshots, klare Ansagen welche Interfaces es gibt, was wo dran hängt und was wovon oder wozu nicht geht :)

  • UPnP bei doppeltem NAT - Patch verfügbar, wie "vorantreiben"?

    14
    1 Votes
    14 Posts
    886 Views
    JeGrJ

    @altmetaller said in UPnP bei doppeltem NAT - Patch verfügbar, wie "vorantreiben"?:

    Ich denke aber, das hat mit der pfSense und der hier erwähnten Problematik nichts zu tun...?!?

    Jein, kann sein, kann nicht. Normalerweise brauchst du zusätzlich für abgehende NAT noch für die Geräte die uPNP machen den outbound NAT Haken bei "static port" aber eben nur die Geräte (Konsole oder PC) damit das was nicht per upnp raus läuft den Port beibehält. Aber solang es geht würde ich jetzt auch nimmer schrauben :)

  • Vlan Problem

    5
    0 Votes
    5 Posts
    449 Views
    J

    Vielen Dank für eure Hilfe, ich habe den Fehler gefunden, jetzt funktioniert es 👍

Copyright 2025 Rubicon Communications LLC (Netgate). All rights reserved.