Sophos Firewall: mDNS-reflector voor apparaatdetectie tussen VLANs

De mDNS-reflector in SFOS 23 maakt apparaatdetectie tussen geselecteerde interne netwerken en VLANs mogelijk. Zo kan een client bijvoorbeeld een AirPlay-ontvanger in een ander VLAN vinden. De reflector draagt zoekopdrachten en dienstaankondigingen over, niet automatisch het daaropvolgende toepassingsverkeer. De vrijgave voor streaming, afdrukken of externe toegang wordt afzonderlijk gepland en gecontroleerd.

De korte procedure: schakel onder Network > mDNS mDNS reflector in, selecteer gericht IP version, Allowed interfaces en Services en pas de instellingen toe met Apply. Test daarna Discovery, het daadwerkelijke gebruik en de netwerkgrenzen die geblokkeerd moeten blijven afzonderlijk.

Deze handleiding beschrijft de SFOS-23-interface. Een bestaande SFOS-22-handleiding voor statische multicastroutering blijft een andere procedure; deze vervangt geen reflector. De beschikbaarheid van documentatie alleen is geen bewijs voor de releasestatus of de geschiktheid van een bepaalde firmwarebuild.

Discovery en gebruik van elkaar onderscheiden

mDNS, oftewel Multicast DNS, wordt samen met DNS-SD gebruikt voor lokale dienstdetectie. Bonjour is Apples benaming voor dergelijke Zero Configuration-diensten. In gescheiden subnetten blijft deze detectie normaal gesproken binnen het betreffende segment. De reflector verbindt de Discovery-laag van de uitdrukkelijk geselecteerde interfaces, zonder de netwerken tot één gezamenlijk VLAN te maken.

Dit heeft twee verschillende gevolgen:

• Een apparaat kan zichtbaar worden terwijl de verbinding met zijn dienst nog geblokkeerd is. Zichtbaarheid bewijst niet dat er een passende firewallregel is of dat streaming werkt.
• De geselecteerde netwerken ontvangen extra informatie over aangeboden diensten. Ook bij geblokkeerd toepassingsverkeer kan deze zichtbaarheid ongewenst zijn, bijvoorbeeld tussen het gastnetwerk en het beheernetwerk.

Allowed interfaces is daarom een beveiligingsgrens, niet alleen een technische selectie. Het dialoogvenster definieert deelnemende interfaces, geen gericht paar van bron en doel. Ga er niet van uit dat hierdoor alleen clients in het ene VLAN apparaten in het andere zien. Services beperkt de gereflecteerde dienstcategorieën; een categorie is echter geen vrijgave voor elke host of elke poort van een toepassing.

WAN- en VPN-interfaces worden niet ondersteund. Een externe VPN-client wordt door deze instelling niet automatisch onderdeel van de lokale Discovery. Ook een ander detectieprotocol wordt niet ondersteund alleen omdat een toepassing daarnaast mDNS gebruikt.

Vereisten en beperkt voorbeeld

Vóór de wijziging zijn de volgende zaken nodig:

• Een SFOS-23-build met Network > mDNS, WebAdmin-toegang en onafhankelijke beheertoegang.
• Reeds geconfigureerde interne interfaces met correct toegewezen VLANs en netwerken. Zones en interfaces moeten overeenkomen met de daadwerkelijke topologie.
• Een client en een bekende dienstaanbieder waarvan de mDNS-detectie binnen hetzelfde segment al werkt.
• Een beslissing over welke dienstcategorieën over segmentgrenzen heen zichtbaar mogen zijn, en de vereiste toepassingspoorten volgens de gebruikte toepassing en apparaatversie.
• Een configuratieback-up en een notitie van de eerdere reflectorstatus, IP-versie, interfaces, categorieën en bestaande toepassingsregels.

Voor een beperkte AirPlay-test wordt bijvoorbeeld het volgende gebruikt:

• Client 10.20.20.50 in het medewerkers-VLAN 10.20.20.0/24, firewallinterface Port2.20, zone LAN.
• Ontvanger 10.30.30.20 in het media-VLAN 10.30.30.0/24, firewallinterface Port2.30, eigen zone MEDIA.
• IP version: IPv4, omdat deze test uitsluitend IPv4 gebruikt.
• Allowed interfaces: alleen Port2.20 en Port2.30.
• Services: alleen AirPlay.

Adressen, VLAN-ID’s, interfacenamen en de voorbeeldzone MEDIA worden vervangen door de eigen configuratie. De reflector selecteert interfaces, niet deze twee afzonderlijke hosts: ook andere apparaten op de betrokken interfaces kunnen binnen de geselecteerde categorieën deelnemen aan Discovery. Voor een fijnmazigere vertrouwensgrens is een passend segmentatieontwerp nodig, niet alleen striktere toepassingsregels.

Gast-, beheer- en andere niet-betrokken interfaces blijven in dit voorbeeld uitgesloten. Een eerste geslaagde test met twee interfaces levert meer inzicht op dan een brede vrijgave waarbij oorzaak en gevolg nauwelijks nog aan elkaar te koppelen zijn.

mDNS-reflector configureren

Eerdere toestand vastleggen en IP-versie kiezen

1. Open in WebAdmin Network > mDNS en leg de bestaande instellingen vast. Een uitgeschakelde reflector kan een oudere configuratie bewaren; controleer daarom vóór het inschakelen ook de opgeslagen selectie.
2. Schakel mDNS reflector in. De gedocumenteerde standaardstatus is Off.
3. Kies bij IP version de daadwerkelijk benodigde variant: IPv4 reflecteert alleen IPv4-mDNS, IPv6 alleen IPv6-mDNS en Dual beide versies.

Voor het voorbeeld blijft de keuze IPv4. Dual is geen algemene reparatieoptie: deze breidt Discovery uit naar beide IP-versies. Als later IPv6-diensten worden gebruikt, moeten ook de bereikbaarheid en toepassingsregels voor IPv6 bewust worden gepland en afzonderlijk worden gecontroleerd.

Interfaces en dienstcategorieën beperken

1. Selecteer onder Allowed interfaces Port2.20 en Port2.30. Alleen de geselecteerde interfaces nemen deel aan gereflecteerde zoekopdrachten en aankondigingen; maximaal 16 interfaces worden ondersteund.
2. Selecteer onder Services AirPlay.
3. Controleer vóór het toepassen dat er niet per ongeluk een gast-, WAN-, VPN- of beheerinterface in de geplande selectie staat.
4. Klik op Apply. De firewall reflecteert het ondersteunde Discovery-verkeer onmiddellijk tussen de geselecteerde interfaces.

Naast AirPlay zijn AirDrop, Apple File Share, Chromecast, IoT Smart Home, Printer, Remote Desktop, Scanner, Sonos en Spotify Connect beschikbaar. Pas de selectie aan de daadwerkelijke behoefte aan. Een dienstcategorie vervangt niet de controle of de concrete toepassing naast Discovery nog andere vereisten heeft.

⚠️ Any verwerkt alle mDNS-dienstcategorieën, ook categorieën die niet afzonderlijk worden vermeld. Dit kan extra netwerkverkeer veroorzaken en de systeemprestaties verminderen. Het vergroot bovendien het aantal zichtbare diensten. Schakel niet over op Any alleen omdat één apparaat ontbreekt; controleer eerst de Discovery van dat apparaat en de passende categorie.

Toepassingsverkeer afzonderlijk toestaan

Voor het latere gebruik wordt een gerichte firewallregel gemaakt of een al passende regel gecontroleerd. In de test is de regelnaam bijvoorbeeld AirPlay-Test-Client-zu-Media, de bron de host 10.20.20.50 in LAN en het doel de host 10.30.30.20 in MEDIA. De Services komen overeen met de voor dit apparaat en deze toepassing bevestigde TCP-/UDP-poorten; logging wordt ingeschakeld voor de acceptatietest.

Hier wordt bewust geen universele AirPlay-poortenlijst aangeboden om te kopiëren. De apparaatfuncties en vereiste verbindingsrichtingen moeten vóór de vrijgave vaststaan. Ontbrekende informatie van de fabrikant wordt niet vervangen door Any. Als de toepassing daarnaast een door de dienstaanbieder geïnitieerde verbinding nodig heeft, wordt deze afzonderlijk onderbouwd en beperkt toegestaan. Het normale antwoord op een bestaande verbinding is niet automatisch een reden voor een brede regel in de omgekeerde richting.

Het is evenmin zinvol om op basis van een vermoeden een algemene UDP-vrijgave in te stellen als vervanging voor de reflectorconfiguratie. De Discovery-selectie en de toepassingsregel hebben verschillende taken. Wijzigingen blijven beperkt tot de gedocumenteerde test; andere regels, NAT en Multicast-routes worden niet terloops gewijzigd.

Succes aantonen met drie afzonderlijke controles

1. Discovery op de geselecteerde interfaces

Controleer na Apply opnieuw de opgeslagen IP-versie, interfaceselectie en categorieën. Start vervolgens op de testclient de apparaatdetectie van de toepassing opnieuw. De bekende ontvanger uit het media-VLAN moet worden gevonden, niet alleen een vermelding uit een eerdere zoekactie.

Start bij een onduidelijk resultaat onder Diagnostics > Packet capture een korte, in tijd begrensde opname. Als BPF-filter voor mDNS is het volgende geschikt:

udp port 5353

Het filter is alleen een hulpmiddel voor observatie en wijzigt geen vrijgaven. Voor de IPv4-test wordt mDNS-verkeer met het lokale Multicast-adres 224.0.0.251 verwacht. Vergelijk interface en tijdstempel: ontstaat de zoekopdracht in het clientnetwerk en is overeenkomstig Discovery-verkeer ook op de geselecteerde media-interface te zien? De pakketinhoud en een opname op de client helpen om te controleren of de verwachte dienst daadwerkelijk wordt aangekondigd. Eén pakket of een bepaalde pakketstatus alleen bewijst geen geslaagde detectie. De procedure wordt uitgelegd in Packet Capture op Sophos Firewall.

2. De daadwerkelijke dienst gebruiken

Selecteer de gevonden ontvanger en start een korte AirPlay-test. Succes betekent dat de gewenste functie op de ontvanger werkt, niet alleen dat zijn naam verschijnt. Controleer in het regellog of in een afzonderlijke opname van het hostpaar 10.20.20.50 en 10.30.30.20 het doeladres, de poorten, de verbindingsrichting en de passende regel.

Als Discovery slaagt maar het gebruik niet, blijft de reflectorselectie in eerste instantie ongewijzigd. Controleer nu de toepassingsregels, daadwerkelijke poorten, routing, lokale apparaatfirewalls en de toepassing zelf. Een ruimere reflectorselectie verhelpt geen geblokkeerde toepassingsdienst.

3. De niet-vrijgegeven grenzen controleren

Controleer met een nieuwe zoekactie in een uitgesloten testsegment dat de dienst niet via deze reflector zichtbaar wordt. Test daarnaast of niet-vrijgegeven verbindingen nog steeds worden geblokkeerd. Bestaande caches en andere Discovery Gateways kunnen het resultaat vertekenen; een vermelding zonder passend nieuw netwerkverkeer is geen voldoende bewijs voor ongewenste reflectie.

In HA worden de reflectorinstellingen tussen de apparaten gesynchroniseerd. De SFOS-23-functie ondersteunt Discovery ook bij failover. Dit is geen garantie voor ononderbroken toepassingssessies. Gebruik een toch al geplande HA-test om na de rolwisseling Discovery en gebruik opnieuw te controleren; voer niet uitsluitend voor deze handleiding een failover in productie uit.

Fouten gericht isoleren

Network > mDNS ontbreekt of een interface ontbreekt

Controleer de geïnstalleerde SFOS-versie en de daadwerkelijke interfaceconfiguratie. Deze handleiding gaat uit van de SFOS-23-interface. WAN- en VPN-interfaces zijn uitgesloten. Documenteer een ontbrekende interne interface of een selectie die niet kan worden opgeslagen met de build, het interfacetype en de exacte melding; de grens van 16 interfaces mag niet worden overschreden. Omzeil dit niet met een statische Multicast-route of een ongedocumenteerde shellwijziging.

De dienst wordt niet gevonden

Controleer eerst in het lokale segment van de aanbieder of diens Discovery werkt. Als deze daar al ontbreekt, zijn het apparaat, de toepassing, WLAN-clientisolatie of lokale netwerkfilters de volgende kandidaten, niet de reflector. Als Discovery lokaal werkt, controleer dan de IP-versie, beide geselecteerde interfaces, de dienstcategorie en het daadwerkelijk opgeslagen resultaat na Apply.

Vergelijk daarna de korte mDNS-opnamen aan beide zijden. Als de zoekopdracht al ontbreekt op de clientinterface, controleer dan de client en het netwerkpad. Als de zoekopdracht aanwezig is maar een passende dienstaankondiging ontbreekt, onderzoek dan de aanbieder. Als er een passende aankondiging is maar geen Discovery op de client, controleer dan het netwerkpad terug naar de client. Voer wijzigingen één voor één uit en herhaal daarna dezelfde test.

De dienst is zichtbaar, maar werkt niet

Leg het toepassingsverkeer afzonderlijk vast en onderzoek een drop aan de hand van hosts, poorten en regelcontext. Vul de vrijgave alleen aan met aantoonbaar benodigde waarden; open niet alle diensten tussen beide VLANs. Ook een aangekondigd adres dat de client niet kan bereiken, kan het gebruik verhinderen; controleer het daadwerkelijke doeladres en het routingpad ernaartoe.

Er verschijnen te veel diensten of er ontstaat extra belasting

Controleer of Services op Any staat, of er ongewenste categorieën zijn geselecteerd en of Allowed interfaces extra segmenten bevat. Zet een onbedoelde uitbreiding terug naar de genoteerde eerdere toestand. Als de storing direct na het activeren begon, schakel de reflector dan gecontroleerd uit en herhaal dezelfde beperkte test. Voer niet op basis van een vermoeden herstarts van diensten uit en voeg geen extra reflectors toe.

Als het probleem blijft bestaan, bewaar dan voor escalatie de build, IP-versie, betrokken interfaces, categorieën, geanonimiseerde hostadressen, tijdstempels en korte opnamen van beide zijden. Klantgegevens en onnodige pakketpayloads horen niet thuis in een openbaar supportvoorbeeld.

Veilig terugdraaien

1. Beëindig de test en documenteer het resultaat en de laatst opgeslagen instellingen.
2. Als de reflector eerder uitgeschakeld was, schakel deze dan onder Network > mDNS weer uit en pas dit toe met Apply. Als de reflector al actief was, herstel dan in plaats daarvan de eerder genoteerde IP-versie, interface- en categorieselectie en pas deze toe; schakel andere afhankelijke diensten niet zonder onderscheid uit.
3. Deactiveer alleen de toepassingsregel die voor deze test is toegevoegd, of draai de gedocumenteerde wijziging aan een bestaande regel terug.
4. Open de instellingen opnieuw en controleer Discovery, bestaande diensten en verbindingen die geblokkeerd moeten blijven met een nieuwe zoekactie.

Bij het uitschakelen blijft de reflectorconfiguratie behouden; bij opnieuw inschakelen wordt de eerdere selectie weer gebruikt. Uitschakelen betekent daarom niet dat de opgeslagen vertrouwensgrenzen worden verwijderd. Controleer interfaces en categorieën opnieuw vóór elke latere heractivering. Reeds aanwezige Discovery-vermeldingen op de client kunnen na het terugdraaien nog worden weergegeven, en een toepassing die al actief is, bewijst niet dat nieuwe Discovery nog steeds wordt gereflecteerd.