Hallo Zusammen
Ich habe ein VLAN(10/Name:WLanInt) dass das WLAN für alle Mobilegeräte zur Verfügung stellt. Vom VLAN10 aus soll auf das VLAN20(Name:WPrint) Gedruckt werden können. Im VLAN20 liegen alle Drucker. Die Drucker haben also ein eigenes WLAN aus diversen Gründen.
ich habe angenommen dass mdns die Lösung sei. mdns wie hier beschrieben installiert https://docs.opnsense.org/manual/how-tos/multicast-dns.html (https://docs.opnsense.org/manual/how-tos/multicast-dns.html) unter Hörende Schnittstellen habe ich den Namen des VLANs 10 also WLanInt und den Namen für VLAN20 WPrint eingetragen.
Leider aber kann via IPhone oder Tablet immer noch kein Drucker gefunden werden. Habe ich etwas vergessen einzustellen oder das Prinzip falsch verstanden?
Gruss und Danke
Hey,
du musst auf beiden Schittstellen eine Firewall-Regel zum zulassen des jeweiligen Netzwerks (Source) mit Ziel(Destination) auf die multicast IPs und den mDNS Port.
multicast IPs: 224.0.0.251 und ff02::fb
mDNS Port: 5353
Hallo inils
Danke dir für deine Antwort. Wenn ich dich richtig verstehe meinst du:
Schnittstelle Protokoll Quelle Ziel Port
VLAN10 IPv6 TCP/UDP VLAN20 ff02::fb/32 5353
VLAN10 IPv4 TCP/UDP VLAN20 224.0.0.251/24 5353
VLAN20 IPv6 TCP/UDP VLAN10 ff02::fb/32 5353
VLAN20 IPv4 TCP/UDP VLAN10 224.0.0.251/24 5353
bei 224.0.0.251 könnte wahrscheinlich auch /32 stehen.
Leider hat das so nicht funktioniert. Ich hoffe du kannst mir sagen wo mein Fehler liegt.
Danke im Voraus
Wenn du auf dem Interface VLAN10 als Quelle auch VLAN10 nimmst sollte es funktionieren.
Edit: Bei VLAN20 natürlich dasselbe
Dafür gibt es auch das MDNS-Repeater Plugin. :)
Grüsse
Franco
Ruffy91 hat recht. Wenn du es so machst wie er schrieb sollte es gehen.
Das Plugin benötigt diese Firewall regeln wenn man nicht Automatisch alles auf der Schnittstelle zulässt.
Ist es wirklich nötig den Multicast selektiv weiterzuleiten?
Grüsse
Franco
Das weiterleiten macht doch das Plugin. Aber wenn z.b. die Firewall Regel kein multicast durchlässt klappt es nicht. Deshalb erlaube ich die multicast Anfrage auf Port 5353
Na gut, generelle Kommunikation zwischen VLAN10 und VLAN20 vorausgesetzt.
Soweit ich verstanden habe wurde immer nur ein Routing benötigt und dann kam das Multicast aber nicht durch wohin das Plugin erstellt wurde.
Vielleicht kann man das noch irgendwie im Handbuch vervollständigen dass sich die Interfaces per Firewall-Regel sehen müssen, optional auch nur über Multicast.
Grüsse
Franco
Hallo zusammen
mDNS ist natürlich installiert.
ich habe nun die Schnittstellen angepasst. bei den IP die /24 gesetzt weil zum Teil im log auf die 224.0.0254 auftritt. Als ich den Drucker per Port 5353 nicht erreichen konnte habe ich nun mal auf any gestellt. Leider erreiche ich den Drucker nicht. Muss auf dem VALN wo der Drucker liegt noch eine ausgehende Regel deklariert werden?
Gruss und Danke euch
Hey Shadow,
bei mir hat's gereicht auf beiden Schnittstellen nur Die multicast in wie oben beschrieben auf dem Port 5353 zuzulassen. Den Rest macht das Plugin. Und sonst habe ich keine Regel dafür erstellt.
Was ist wenn du als Ziel einmal any/* einstellst? Klappt es dann?
Hey franco,
ja das wir nicht sofort ersichtlich. Und da meine vlans nur bestimmten Traffic durchlassen sollen musste ich gucken wie die die Freigaben machen muss. Falls natürlich eine any Regel besteht sollte es auch so Kappen.
Gruß
Leider geht aus so nicht.
ich werde heute Abend noch eine zweite Firewall aufsetzen zum testen und schauen was da passiert.
Danke
hmhhhh... ich habe soeben auf meinem Testgerät nochmals die aktuelle Version installiert mit dem Ergebnis das AirPrint nicht funktioniert.
Nun habe ich aber die alte Version 18.1.6 nochmals installiert und siehe da alles läuft wie gewollt.
Mein Versuch ist nun das AirPrint unter einer alten Version zu konfigurieren und dann auf die aktuelle Version upzudaten.
Da ich noch nie ein Update für das Plugin gemacht habe, kann es dann nur eine Änderung im Core oder Port sein.
hallo zusammen
zum einen möchte ich mal Fabian danken für die Implementation des MDNS-R. Tolle Sache!
Nach längerem testen kann ich nun sagen dass bei einem Testrechner das AirPrint nicht lief aber nur mit der vorletzten Version. Nach einem Update funktioniert alles wieder. Könnte sogar sein dass nicht mit der Hardware kompatibel ist was mit dem Update danach wieder gefixt wurde. Leider habe ich aber nicht rausbekommen an was es genau liegt.
Aber Danke euch nun läuft alles wieder
Ich möchte das Thema noch mal aufmachen, weil ich die gleichen Probleme habe, wie im ursprünglichen Post.
OPNsense 21.7.2_1 (latest)
Ich habe zwei Subnets A und B. Firewall-Regeln lassen Multicasts (224.0.0.0/4) zu (also A nach Multicast, und B nach Multicasts), alle Ports (any) sind erlaubt.
Ich habe dazu eine Foating Rule erstellt:
Action: pass
Interfaces: A, B
Protocoll: TCP/UDP
Source and Port: any
Destination: 224.0.0.0/4, any Port
MDNS repeater (Version 1.0_1) ist aktiv auf den Subnets A und B (Listen Interfaces auf A und B aktiviert)
Im Subnet A befindet sich ein Airprint-Drucker mit Bonjour-Protokoll.
Wenn ich mich im Subnet A befinde, dann wird der Airprint-Drucker angezeigt.
Wenn ich mich im Subnet B befinde, dann nicht.
Gewünscht ist natürlich, dass der Airprintdrucker im Subnet B auch angezeigt wird.
Was kann ich tun? Hat es jemand mit den aktuellen Versionen zum Laufen bekommen?
Grüße Michael
Benutz mal Discovery und lass Dir anzeigen, was der Drucker denn so kundtut wie er erreichbar sei.
Mein Brother hier publiziert per Bonjour eine IPv6-Linklocal-Adresse. Das Funktioniert über Subnetze hinweg grundsätzlich nicht, da gibt es dann aber auch keinen Fix. Selbst wenn man am Drucker IPv6 deaktiviert, tut er das ...
https://apps.apple.com/us/app/discovery-dns-sd-browser/id1381004916
Gruß
Patrick
Discovery zeigt hier so einiges an. Ich habe bestimmt 10 Einträge. Leider kann ich aus den Infos nicht wirklich einen Nutzen ziehen. IPv6 wird bei meinem Drucker jedenfalls nirgends angezeigt. IPv4 Adressen von meinem Drucker schon.
Ich habe einen Kyocera M5526cdw. Vielleicht hat ja ein Kollege es hinbekommen, Bonjour in ein anderes Subnetz zu bekommen. In der Firewall sehe ich, dass
dass aus Subnet A mit Source [fe80::c4b:9579:cadf:94c3]:5353 auf Destination [ff02::fb]:5353 wegen der Regel "udp Block bogon IPv6 networks from NwMb" geblockt werden. Wer da von Port 5353 sendet ist mir nicht klar. IPv6 Listen führe ich nicht, weil mein Netzwerk eigentlich nur ein IPv4 Netzwerk ist.
Laut Statusseite vom Drucker sollte der Drucker die IPv6-Adresse fe80::217:c8ff:fe80:80a8 / 64 (IPv6 Kabelnetzwerk) und fe80::217:c8ff:fe5f:e3a6 / 64 (IPv6 WLAN) haben.
Die fe80::/64 Adressen sind link-local. D.h. die funktionieren nicht über Router/Firewalls hinweg, auch nicht mit einer "allow all" Regel.
Siehe Screenshot - das ist das, was mein Brother hier ins Netz bläst - zu sehen in Discovery.
Wenn nun mein Mac in einem anderen Subnetz ist, und IPv6 präferiert - was er leider tut - dann findet er den Drucker nicht. Es gibt 2021 keine reinen IPv4-Netze mehr. Alle Betriebssysteme machen standardmäßig zumindest link-local IPv6. Aber das funktioniert eben nur im selben Subnetz, weil "link-local".
Hoffe, ich habe mich verständlich ausgedrückt.
Wenn es jetzt nicht um Airprint mit einem iPad oder iPhone geht, sondern tatsächlich um einen Mac, dann kannst Du den Drucker natürlich manuell mit seiner IPv4-Adresse anlegen. Das wird dann funktionieren. Und dann ggf. vom Mac aus wieder freigeben, damit ein iPhone o.ä. dann dort hin drucken kann.
Gruß
Patrick
Hi,
bei mir funktioniert ein Kyocera M5521cdw problemlos über mehrere VLANs mit AirPrint. Allerdings habe ich auch IPv6 aktiviert, inkl. IPv6 ULA Adressen. Vielleicht tut es deshalb. Ich verwende anstatt mdns-repeater den udpbroadcastrelay zum Weiterleiten der Bonjour-Pakete.
Am Wochenende bin ich wieder Zuhause und kann dann mal meine Konfiguration dokumentieren und hier posten.
Gruß KH
Ich hab auch IPv6 aktiv, aber Brother annonciert nur eine link-local Adresse und da ist dann eben Schluss.
Hi pmhausen
Auch IPv6 ULA ?
Gruß KH
Nö, global unicast, also "richtige" Adressen. Wie geschrieben announced der Brother aber nicht diese sondern nur link-local. Ist mir nicht wichtig genug, eindeutig ein Bug im Drucker.
Hallo Zusammen,
ich habe das gleiche Problem mit meinem aktuellen Setup. Ich habe zwei VLANs (VLAN50 und VLAN68). Im VLAN68 soll der Drucker sein und im VLAN50 alle Drahtlosen clients.
Ich habe bereits das multicast-Plugin installiert und für die beiden VLANs aktiviert. Ich habe die Firewallregeln für Multicast DNS im Client und Drucket-VLAN eingetragen. Ich sehe im Firewall log, dass das Multicast beim Drucker ankommt. Ich kann auch den Drucker via Handy und auch am Laptop via Bonjour Discovery finden.
Allerdings habe ich das Problem, dass auf meinem iPhone bei einem Druckversuch nach dem Auswählen des Druckers nach kurzer Zeit der Drucker wieder aus der Auswahl verschwindet.
Auf meinem Arch-Laptop kann ich zwar den Drucker einrichten, aber die Druckeinstellungen reagieren sehr träge, und wenn ich was Drucken will, dann wird kein Drucker angegeben.
Habt ihr eine Idee, was das Problem sein könnte? Ich habe die Vermutung, dass noch irgendwelche Firewallregeln fehlen.
Hier die relevanten Firewallregeln im Clients-Netz
IPv4 TCP/UDP Clients net * DruckerScanner net 631 * *
IPv4 TCP/UDP Clients net * DruckerScanner net 515 * *
IPv4 TCP/UDP Clients net * MulticastDNS 5353 - 5354 * *
IPv4 TCP Clients net * DruckerScanner net 80 (HTTP) * *
IPv4 TCP Clients net * DruckerScanner net 443 (HTTPS) * *
Die Firewallregeln im DruckerScanner net
IPv4 ICMP Clients net * DruckerScanner net * * *
IPv4 TCP Clients net * DruckerScanner net 631 * *
IPv4 TCP Clients net * DruckerScanner net 80 (HTTP) * *
IPv4 TCP Clients net * DruckerScanner net 443 (HTTPS) * *
PS: Ich habe zwar regeln in den Tabellen für das Erlauben von PINGs/ICMP und den Zugriff auf das Drucker-Webfrontend, aber ich kann weder den Drucker anpingen, noch komme ich aus dem Clientnetz auf das Webfrontend des Druckers.
Danke und Grüße
PS: Ich hoffe, dass es ok ist wenn ich diesen alten Thread recycle.
Benutz mal was wie mDNS-Explorer und guck dir an, was der Drucker da tatsächlich verteilt. Mein oller Brother z.B. ist zwar sichtbar, teilt per mDNS aber eine Link-local v6-Adresse. Das geht über Netzwerke hinweg schlicht nicht.
https://github.com/mnellemann/mdns-explorer
Und dann kann es natürlich noch sein, dass da noch Regeln im Clients-Net fehlen. Pakettrace hilft.
Die Regeln im Drucker-Netz sind überflüssig 😉
Und abschließend ganz pragmatisch: weshalb den Drucker nicht in das Netz, in dem auch die Clients sind, die ihn benutzen? So hab ich das. Sehe keinen Grund, so ein Gerät zu isolieren.
Ich hab auf dem Laptop das Avahi-Discovery Tool verwendet. Damit kann ich den Drucker finden und bekomme diverse Dienste mit der IP aus dem Drucker-VLAN angezeigt. Unter anderem finde ich den UNIX-Print Dienst auf der IP-Adresse.
QuoteUnd dann kann es natürlich noch sein, dass da noch Regeln im Clients-Net fehlen. Pakettrace hilft.
Hab's mal getraced, kann da aber nicht wirklich was sehen. Was mir auffällt ist, dass ich bei der gesamten Kommunikation nicht einmal die IP-Adresse vom Drucker sehe. Im pcap sehe ich kein mDNS. Ich sehe aber (reproduzierbar) im OPNsense Firewall log mehrere mDNS-Requests, die aber von IP's (Source) im WAN Netz kommen und dementsprechend von der Firewall geblockt werden.
Kann es sein, dass die mDNS query irgendwie im WAN-Netz landet und dann die Geräte im WAN-Netz versuchen darauf zu antworten?
QuoteUnd abschließend ganz pragmatisch: weshalb den Drucker nicht in das Netz, in dem auch die Clients sind, die ihn benutzen? So hab ich das. Sehe keinen Grund, so ein Gerät zu isolieren.
Drucker sind halt böse :-). Ja ich vermute, dass ich langfristig auch auf diese Lösung umsteigen werden. Ich wollte mich aber generell mal mit der Materie verraut machen, da ich noch andere Geräte habe (WLAN-Lautsprecher) die ich dann doch gerne in einem seperaten VLAN hätte.
Genau das ist der Punkt, den ich am wenigsten verstehe ... Drucker, Scanner, Lautsprecher ... kommt bei mir alles ins vertrauenswürdige Familiennetz. Ich kauf da halt keinen China-Kram, sondern Geräte mit Doku, was sie tun. Lautsprecher z.B. ist eine Airport Express an der Stereoanlage. Drucker Brother mit Ethernet und SNMP ... was tun denn moderne Drucker so? Ich hatte noch nie einen, der nachhause telefoniert hätte. Meiner braucht sogar fürs Firmware-Update ein externes Tool.
Isolieren tue ich ganz anderen Kram 🙂
Da hatte ich schon viele, die das tun, z.B. von HP. Wenn man die lässt, melden sie den Verbrauch nach Hause, checken, ob Firmware-Updates vorliegen und bestellen Verbrauchsmaterial nach.
Die Firmware-Updates machen ggf. Third-Party-Cartridges unbrauchbar - habe deswegen gerade einen HP zurückgeschickt.
Am Rande nutzen sie Cloud-NTP-Server.
Der Nachfolger - ein Lexmark - ist nicht viel anders.
Quote from: Patrick M. Hausen on December 26, 2025, 12:12:58 AMGenau das ist der Punkt, den ich am wenigsten verstehe ... Drucker, Scanner, Lautsprecher ... kommt bei mir alles ins vertrauenswürdige Familiennetz. Ich kauf da halt keinen China-Kram, sondern Geräte mit Doku, was sie tun. Lautsprecher z.B. ist eine Airport Express an der Stereoanlage. Drucker Brother mit Ethernet und SNMP ... was tun denn moderne Drucker so? Ich hatte noch nie einen, der nachhause telefoniert hätte. Meiner braucht sogar fürs Firmware-Update ein externes Tool.
Isolieren tue ich ganz anderen Kram 🙂
Ja tatsächlich ist wahrscheinlich der Aufwand zu groß, als das man dieses "Business-Gerät" in ein seperates VLAN steckt. Ich hatte hier noch einen Medion WLAN Lautsprecher, den ich gerne weiternutzen würde. Allerdings wird der über eine Fragwürdige App konfiguriert. Für solche Fälle wollte ich lernen, wie man die Geräte separiert. Und grundsätzlich bin ich der Meinung, dass wenn es keinen guten Grund gibt, dann dürfen die Geräte in ihrem eigenen VLAN/WLAN sich tummeln.
Ich schließe dann den Fall für mich ab und werfe den Drucker in das Client-Netz.
Ich habe das ganze mittlerweile anders gelöst und nutze meinen Drucker nur noch unicast mit unbound. Das funktioniert super mit Android als Mopria-Drucker, mit Airprint für iPhones etc. Und auch für Windows.
Ich brauche kein ymd s Repeater etc. Und hatte seitdem nie mehr das Problem, dass mein Drucker über verschiedene Vlans nicht gefunden wird. Vielleicht wäre das eine Lösung.
https://forum.opnsense.org/index.php?msg=245044
Kleiner Nachtrag. Ich hab mich gewundert, warum ich trotz einer ICMP-Regel den Drucker vom Clientnetz nicht anpingen konnte. Dann habe ich noch zwei Dinge entdeckt, die ich reinkonfiguriert aber dann wieder vergessen hatte. Das eine war eine statische Route. Das viel interessantere war eine Gruppenregel, die für das Clientnetz zwar angewendet wurde, ich diese aber nicht gesehen habe, da sie ausgeblendet war.
Die Regel war im Prinip wie folgt:
IPv4 * Trusted net * !PrivateNetworks * * *
PrivateNetworks ist ein Alias für die bekannten privaten Netze (192..,172..,10.).
Da die Regel ein ,,First Match" war, hat diese immer zuerst gegriffen und den PING (und anderes) blockiert.
Nachdem ich eine ,,Last Match" daraus gemacht habe, konnte ich auch wieder ,,pingen" und die Konfigurationsoberfläche vom Drucker erreichen :-)