MDNS über mehrere VLANs CISCO und pfsense
Hello : )
Ich habe ne pfSense 2.5.2 mit mehreren VLANs', einen CISCO SG300 (L3 Mode).
Würde gerne von meinem iPhone in HOMEKIT = WLAN (VLAN200), auf mein Server (Proxmox:VM:ioBroker/YAHKA) in IOT (VLAN40) zugreifen.
Ich habe jetzt Avahi Konfiguriert, und mal auf beiden Netzen eine Allow All Scheunentor Regel erstellt... = Funktioniert nicht
Am Switch hab ich jetzt sachen angeklickt die ich nichtmal ansatzweise verstehe. Nicht das Gelbe vom EI :/ = Funktioniert nicht, verwirrt (ich)
Muss man am SG300 etwas einstellen oder reicht es aus Avahi zu installieren und die Regeln zu erstellen?
Anm. Ich habe mit einem iOS APP den Bonjour Service mal Scannen lassen.... Da findet er die Homekit-Bridge.
Ich habe ne pfSense 2.5.2 mit mehreren VLANs', einen CISCO SG300 (L3 Mode).
Würde gerne von meinem iPhone in HOMEKIT = WLAN (VLAN200), auf mein Server (Proxmox:VM:ioBroker/YAHKA) in IOT (VLAN40) zugreifen.
Ich habe jetzt Avahi Konfiguriert, und mal auf beiden Netzen eine Allow All Scheunentor Regel erstellt... = Funktioniert nicht
Am Switch hab ich jetzt sachen angeklickt die ich nichtmal ansatzweise verstehe. Nicht das Gelbe vom EI :/ = Funktioniert nicht, verwirrt (ich)
Muss man am SG300 etwas einstellen oder reicht es aus Avahi zu installieren und die Regeln zu erstellen?
Anm. Ich habe mit einem iOS APP den Bonjour Service mal Scannen lassen.... Da findet er die Homekit-Bridge.
Bitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 1382857583
Url: https://administrator.de/contentid/1382857583
Ausgedruckt am: 17.11.2024 um 19:11 Uhr
14 Kommentare
Neuester Kommentar
Am Switch hab ich jetzt sachen angeklickt die ich nichtmal ansatzweise verstehe.
Welche denn ?? Mit solch oberflächlichen Angaben ist eine zielführende Hilfe nicht oder nur schwer möglich wie du dir sicher auch selber denken kannst. Die grundsätzliche Frage ist WIE kommuniziert die Homekit App mit dem Server ?? Dazu machst du leider keinerlei Aussagen welche aber essentiell wichtig für das Regelwerk der Firewall sind.
Gut, wenn es mDNS/Bonjour ist um sich überhaupt erstmal zu finden benötigst du im Client VLAN (iPhone) einen mDNS/Bonjour Proxy.
Grund dafür ist das mDNS/Bonjour Protokoll eine Link Local Mutlicast Adresse 224.0.0.251 benutzt wird, welche Prinzip bedingt fest einen TTL von 1 hat, also somit nicht routebar sind. (Deshalb ja auch "Link LOCAL Multicast"). Siehe dazu auch: https://de.wikipedia.org/wiki/Zeroconf#Multicast_DNS
Du musst den Server also mit einem Proxy im Client Netz mit einem AVAHI Proxy announcen weil eben die mDNS Frames des Servers dort aus den o.a. Gründen nicht ankommen können.
Die Kardinalsfrage die sich jetzt stellt ist WAS ist genau gemeint wenn du sagst: "Ich habe jetzt Avahi Konfiguriert" ??
WIE und WO hast du das konfiguriert ??
Normal ist dafür ein Proxy notwendig wie z.B. das AVAHI Package der pfSense: https://docs.netgate.com/pfsense/en/latest/packages/avahi.html oder ein externer Proxy mit einem Raspberry Pi.
Netzwerk Management Server mit Raspberry Pi
Hier können wir jetzt nur im freien Fall raten oder die Kristallkugel nehmen WAS du WIE umgesetzt hast ?? Dazu reichen die wenigen Angaben deiner recht einfachen Beschreibung nicht.
Vermutlich hast du dort einen Konfig oder Setup Fehler gemacht. Aber auch das kann man ohne weitere Infos nur raten oder mutmaßen.
Deine IGMP Snooping Konfig ist fehlerhaft bzw. unvollständig !
Sinnvoll ist IGMP Snooping global für alle VLANs zu aktivieren. Es macht doch wenig Sinn das in einem VLAN zu aktivieren und in allen anderen nicht und dort dummes Fluten auf alle Ports laufen zu lassen.
Vielleicht solltest du besser noch einmal nachlesen was IGMP Snooping ist und was es macht:
https://en.wikipedia.org/wiki/IGMP_snooping
Es dient zur intelligenten Steuerung von Multicast in einem Layer 2 Switching Netz. Es sorgt dafür das Multicast nur an solche Ports geforwardet wird wo es auch genutzt wird. Es spart also Performance auf einem Switch da er nicht mehr MC Frames an alle Ports zwangsfluten muss weil das häufig in Software über die CPU passiert.
IGMP Snooping hat aber rein gar nichts mit Multicast Routing zu tun. Das macht PIM: https://de.wikipedia.org/wiki/Protocol_Independent_Multicast
In sofern ist IGMP Snooping für dich primär irrelevant, denn eigentlich musst du ja Multicast routen in andere IP Netze.
Wie oben schon mehrfach ausgeführt scheitert das aber mit mDNS/Bonjour weil die eine NICHT routebare Multicast Adresse nutzen mit einem TTL von 1. Also auch wenn man routen könnte oder würde können die mDNS Frames technisch niemals andere IP Netze erreichen.
https://www.omnisecu.com/tcpip/ipv4-link-local-multicast-addresses.php
Da hilft dann logischerweise IGMP Snooping und auch die richtigen Firewall Regeln kein bisschen. Hier liegt vermutlich dein fataler Denkfehler ?!
Wenn du einmal einen Wireshark oder nur die Packet Sniffing Funktion auf der FW genutzt hättest, hättest du es auch selber sehen können.
Um mDNS/Bonjour also in einem anderen IP Segment laufen zu lassen benötigst du dort einen Proxy also ein Gerät was quasi die Server mDNS Frames in diesem Segment aussendet wo eben der Server nicht ist und seine mDNS Frames eben auch wegen der obigen Bedingungen nicht hinkommen können. Es gilt also dann dortigen Endgeräten vorzugaukeln das dort der Server ist. In dessen MC mDNS Frame steht ja seine wirkliche, physische IP Adresse und die ist relevant für die Clients um ihn zu erreichen aus fremden IP Netzen.
Sprich du musst also nur schlicht und einfach dafür sorgen das die "Fake" Server mDNS Multicasts auch in deinem Client Segment ausgesendet werden.
Genau das machst du mit dem AVAHI Server Packet indem du das on Top über die Packetverwaltung der pfSense installierst und entsprechend customized.
Alternativ mit einem Raspberry Pi usw. der das im Client Segment übernimmt mit seinem AVAHI Server und entsprechender Konfig. Siehe Link zum Raspberry Tutorial oben. Eigentlich doch ganz einfache Logik !
Nur so wird ein Schuh draus !
Sinnvoll ist IGMP Snooping global für alle VLANs zu aktivieren. Es macht doch wenig Sinn das in einem VLAN zu aktivieren und in allen anderen nicht und dort dummes Fluten auf alle Ports laufen zu lassen.
Vielleicht solltest du besser noch einmal nachlesen was IGMP Snooping ist und was es macht:
https://en.wikipedia.org/wiki/IGMP_snooping
Es dient zur intelligenten Steuerung von Multicast in einem Layer 2 Switching Netz. Es sorgt dafür das Multicast nur an solche Ports geforwardet wird wo es auch genutzt wird. Es spart also Performance auf einem Switch da er nicht mehr MC Frames an alle Ports zwangsfluten muss weil das häufig in Software über die CPU passiert.
IGMP Snooping hat aber rein gar nichts mit Multicast Routing zu tun. Das macht PIM: https://de.wikipedia.org/wiki/Protocol_Independent_Multicast
In sofern ist IGMP Snooping für dich primär irrelevant, denn eigentlich musst du ja Multicast routen in andere IP Netze.
Wie oben schon mehrfach ausgeführt scheitert das aber mit mDNS/Bonjour weil die eine NICHT routebare Multicast Adresse nutzen mit einem TTL von 1. Also auch wenn man routen könnte oder würde können die mDNS Frames technisch niemals andere IP Netze erreichen.
https://www.omnisecu.com/tcpip/ipv4-link-local-multicast-addresses.php
Da hilft dann logischerweise IGMP Snooping und auch die richtigen Firewall Regeln kein bisschen. Hier liegt vermutlich dein fataler Denkfehler ?!
Wenn du einmal einen Wireshark oder nur die Packet Sniffing Funktion auf der FW genutzt hättest, hättest du es auch selber sehen können.
Um mDNS/Bonjour also in einem anderen IP Segment laufen zu lassen benötigst du dort einen Proxy also ein Gerät was quasi die Server mDNS Frames in diesem Segment aussendet wo eben der Server nicht ist und seine mDNS Frames eben auch wegen der obigen Bedingungen nicht hinkommen können. Es gilt also dann dortigen Endgeräten vorzugaukeln das dort der Server ist. In dessen MC mDNS Frame steht ja seine wirkliche, physische IP Adresse und die ist relevant für die Clients um ihn zu erreichen aus fremden IP Netzen.
Sprich du musst also nur schlicht und einfach dafür sorgen das die "Fake" Server mDNS Multicasts auch in deinem Client Segment ausgesendet werden.
Genau das machst du mit dem AVAHI Server Packet indem du das on Top über die Packetverwaltung der pfSense installierst und entsprechend customized.
Alternativ mit einem Raspberry Pi usw. der das im Client Segment übernimmt mit seinem AVAHI Server und entsprechender Konfig. Siehe Link zum Raspberry Tutorial oben. Eigentlich doch ganz einfache Logik !
Nur so wird ein Schuh draus !
und geht nicht.
Du müsstest dir mit dem Wireshark oder der Pakte Capture Funktion auf der FW einmal genau ansehen WAS der Server announced. Dort sind bestimmte Dienstemerkmale und andere Parameter im mDNS Frame zu sehen.Zu 98% fehlt da was in deinem AVAHI Setup so das dort zwar ein Multicast kommt, der Inhalt aber fehlerhaft oder unvollständig ist so das der Client den Dienst nicht erkennt.
Ein Wireshark Trace einmal des originalen Multicasts des Servers und einmal dem den der AVAHI sendet sollte da sofort Klarheit schaffen !
Und mit Wireshark kann ich leider nicht umgehen
Na komm... Einschalten, mitlesen, fertisch. Mehr ist doch nicht zu tun. Daran wirds doch bei dir sicher nicht scheitern, oder ? Die "Mac Adress Lösung" klingt verwunderlich aber egal...wenns damit klappt ist ja alles perfekt ! 👏
Dann bleibt ja nur noch den Case als gelöst zu markieren !!
Wie kann ich einen Beitrag als gelöst markieren?
Das ist kein Problem, nur das ganze verstehen
Mmmhhh...Absender IP Adresse lesen um zu verstehen WOHER es kommt, Zieladresse lesen WOHIN es geht, Port lesen WAS es ist....3 banale Dinge die einen doch nicht groß intellektuell überfordern sollten, oder ?! 😉
dürfte aber ein Bug in diesem Adapter sein
Manchmal muss man auch einfach mal Glück haben...Endlich läuft das richtig
👍Geht das Prinzipiell?
Ja, vollkommen problemos. Guckst du hier: Merkzettel: VPN Installation mit WireguardAber auch das hier beachten: PfSense CE 2.5.2 oder 2.6.0 - Wireguard Package und das automatische Erstellen der Routen