Sophos Firewall: mDNS reflector for device discovery between VLANs

The mDNS reflector in SFOS 23 enables device discovery between selected internal networks and VLANs. For example, it allows a client to find an AirPlay receiver in another VLAN. The reflector forwards discovery queries and service announcements, not automatically the subsequent application traffic. Access for streaming, printing, or remote access is planned and verified separately.

The quick procedure: Under Network > mDNS, enable mDNS reflector, select IP version, Allowed interfaces, and Services carefully, and save with Apply. Then test discovery, actual use, and the network boundaries that must remain blocked separately.

This guide describes the SFOS 23 interface. An existing SFOS 22 guide for static multicast routing remains a different procedure; it does not replace a reflector. The availability of documentation alone is not evidence of the release status or suitability of a particular firmware build.

Keep discovery and use separate

mDNS, or Multicast DNS, works together with DNS-SD for local service discovery. Bonjour is Apple’s name for the corresponding zero-configuration services. In separate subnets, this discovery normally stays within each segment. The reflector connects the discovery layer of the explicitly selected interfaces without turning the networks into a shared VLAN.

This has two distinct consequences:

• A device can become visible even though the connection to its service is still blocked. Visibility proves neither that a suitable firewall rule exists nor that streaming works.
• The selected networks receive additional information about available services. Even when application traffic is blocked, this visibility may be undesirable, for example between a guest network and an administration network.

Allowed interfaces is therefore a security boundary, not just a technical selection. The dialog defines participating interfaces, not a directional source-and-destination pair. Do not assume that only clients in one VLAN will see devices in the other. Services limits the reflected service categories; however, a category does not grant access to every host or every port used by an application.

WAN and VPN interfaces are not supported. This setting does not automatically make a remote VPN client part of local discovery. Nor does it support another discovery protocol simply because an application also uses mDNS.

Prerequisites and a limited example

Before making the change, you need:

• An SFOS 23 build with Network > mDNS, WebAdmin access, and independent management access.
• Internal interfaces already configured with correctly assigned VLANs and networks. Zones and interfaces must match the actual topology.
• A client and a known service provider whose mDNS discovery already works within the same segment.
• A decision on which service categories may be visible across segments, and the application ports required by the application and device version in use.
• A configuration backup and a record of the previous reflector state, IP version, interfaces, categories, and existing application rules.

For a limited AirPlay test, use the following example:

• Client 10.20.20.50 in the employee VLAN 10.20.20.0/24, firewall interface Port2.20, zone LAN.
• Receiver 10.30.30.20 in the media VLAN 10.30.30.0/24, firewall interface Port2.30, dedicated zone MEDIA.
• IP version: IPv4, because this test uses IPv4 only.
• Allowed interfaces: only Port2.20 and Port2.30.
• Services: only AirPlay.

Replace the addresses, VLAN IDs, interface names, and example zone MEDIA with your own configuration. The reflector selects interfaces, not these two individual hosts: Other devices on the participating interfaces can also take part in discovery within the selected categories. A finer-grained trust boundary requires an appropriate segmentation design, not merely more restrictive application rules.

Guest, management, and other unrelated interfaces remain excluded in this example. An initial successful test with two interfaces is more informative than broad access that makes cause and effect difficult to distinguish.

Configure the mDNS reflector

Record the previous state and select the IP version

1. In WebAdmin, open Network > mDNS and record the current settings. A disabled reflector may retain an older configuration, so check the saved selection before enabling it.
2. Enable mDNS reflector. The documented default state is Off.
3. Under IP version, select the version actually required: IPv4 reflects only IPv4 mDNS, IPv6 only IPv6 mDNS, and Dual both versions.

Keep IPv4 for this example. Dual is not a general-purpose fix: It extends discovery to both IP versions. If IPv6 services are used later, IPv6 reachability and application rules must also be deliberately planned and tested separately.

Limit interfaces and service categories

1. Under Allowed interfaces, select Port2.20 and Port2.30. Only the selected interfaces participate in reflected queries and announcements; a maximum of 16 interfaces is supported.
2. Under Services, select AirPlay.
3. Before applying the settings, check that no guest, WAN, VPN, or management interface has accidentally been included in the planned selection.
4. Click Apply. The firewall immediately reflects supported discovery traffic between the selected interfaces.

In addition to AirPlay, the available categories are AirDrop, Apple File Share, Chromecast, IoT Smart Home, Printer, Remote Desktop, Scanner, Sonos, and Spotify Connect. Adjust the selection to actual requirements. A service category does not replace checking whether the specific application has prerequisites beyond discovery.

⚠️ Any processes all mDNS service categories, including those not listed individually. This can generate additional network traffic and affect system performance. It also expands the services that are visible. Do not switch to Any just because a single device is missing; first check its discovery and the appropriate category.

Allow application traffic separately

For subsequent use, create a targeted firewall rule or verify an existing suitable rule. In the test, the example rule name is AirPlay-Test-Client-zu-Media, the source is host 10.20.20.50 in LAN, and the destination is host 10.30.30.20 in MEDIA. The services correspond to the TCP/UDP ports confirmed for this device and application; enable logging for acceptance testing.

This guide deliberately provides no universal AirPlay port list to copy. Device functions and required connection directions must be established before access is granted. Missing manufacturer information is not replaced with Any. If the application also requires a connection initiated by the service provider, justify it separately and allow it narrowly. A normal reply to an existing connection is not automatically a reason for a broad reverse-direction rule.

It is equally inappropriate to create a general UDP allow rule on suspicion as a substitute for reflector configuration. The discovery selection and application rule serve different purposes. Keep changes limited to the documented test; do not change other rules, NAT, or multicast routes along the way.

Verify success with three separate checks

1. Discovery on the selected interfaces

After Apply, check the saved IP version, interface selection, and categories again. Then restart device discovery in the application on the test client. The expected result is the known receiver from the media VLAN, not merely an entry from an earlier discovery run.

If the result is unclear, start a short, time-limited capture under Diagnostics > Packet capture. The following BPF filter is suitable for mDNS:

udp port 5353

The filter is only an observation aid and does not change any access permissions. For the IPv4 test, expect mDNS traffic using the local multicast address 224.0.0.251. Compare interfaces and timestamps: Does discovery originate in the client network, and is corresponding discovery traffic also visible on the selected media interface? Packet contents and a capture on the client help verify whether the expected service is actually being announced. A single packet or a particular packet status alone does not prove successful discovery. Packet Capture on Sophos Firewall explains the procedure.

2. Use the actual service

Select the discovered receiver and start a short AirPlay test. Success means that the intended function works on the receiver, not merely that its name appears. In the rule log or a separate capture of the host pair 10.20.20.50 and 10.30.30.20, check the destination address, ports, connection direction, and matching rule.

If discovery succeeds but use fails, leave the reflector selection unchanged initially. Now check application rules, actual ports, routing, local device firewalls, and the application itself. A broader reflector does not fix a blocked application service.

3. Check the boundaries that have not been opened

Run a fresh discovery search in an excluded test segment to check that the service does not become visible through this reflector. Also test that connections not explicitly allowed remain blocked. Existing caches and other discovery gateways can distort the result; a displayed entry without corresponding new network traffic is not sufficient evidence of unwanted reflection.

In HA, reflector settings are synchronized between the devices. The SFOS 23 feature also supports discovery during failover. This is not a guarantee of uninterrupted application sessions. Use an already planned HA test to check discovery and use again after the role change; do not trigger a production failover solely for this guide.

Troubleshoot systematically

Network > mDNS is missing, or an interface is missing

Check the installed SFOS version and actual interface configuration. This guide requires the SFOS 23 interface. WAN and VPN interfaces are excluded. Document a missing internal interface or a selection that cannot be saved, including the build, interface type, and exact message; do not exceed the limit of 16 interfaces. Do not work around this with a static multicast route or an undocumented shell change.

The service is not found

First check whether discovery works in the provider’s local segment. If it is already missing there, the device, application, wireless client isolation, or local network filters are the next candidates, not the reflector. If it works locally, check the IP version, both selected interfaces, service category, and the settings actually saved after Apply.

Then compare the short mDNS captures on both sides. If the discovery query is already missing at the client interface, check the client and network path. If the query is present but there is no matching service announcement, investigate the provider. If a matching announcement exists but discovery does not work on the client, check the network path back to the client. Make changes one at a time, then repeat the same test after each change.

The service is visible but does not work

Capture the application traffic separately and investigate a drop using the hosts, ports, and rule context. Add only values that are demonstrably required to the allow rule; do not open all services between the two VLANs. An announced address that the client cannot reach can also prevent use; check the actual destination address and its routing path.

Too many services or additional load appear

Check Services for Any and unwanted categories, and Allowed interfaces for additional segments. Revert any unintended expansion to the recorded previous state. If the disruption began immediately after activation, disable the reflector in a controlled manner and repeat the same limited test. Do not introduce service restarts or additional reflectors on suspicion.

If the problem persists, save the build, IP version, participating interfaces, categories, anonymized host addresses, timestamps, and short captures from both sides for escalation. Customer data and unnecessary packet payloads do not belong in a public support example.

Roll back safely

1. End the test and document the result and the most recently saved settings.
2. If the reflector was previously off, disable it again under Network > mDNS and save with Apply. If it was already active, instead restore and apply the previously recorded IP version, interface selection, and category selection; do not indiscriminately disable other dependent services.
3. Disable only the application rule added for this test, or revert the documented change to an existing rule.
4. Reopen the settings and use a fresh discovery run to verify discovery, existing services, and connections that must remain blocked.

Disabling the reflector retains its configuration; enabling it again reuses the previous selection. Disabling it therefore does not delete the saved trust boundaries. Check interfaces and categories again before any later reactivation. Existing discovery entries on the client may still appear after rollback, and an application that is already running is not evidence that new discovery is still being reflected.