Brother “Scan to PC” button not working across VLANs/separate networks on RB5009 — mDNS RouterOS 7.20.8

Hi everyone,

I'm having a frustrating issue with Brother scanners not working across segmented networks on my MikroTik RB5009. I've tried everything I can think of and nothing has worked. Would really appreciate any help.

**Network Setup:**

- RB5009UG+S+ running RouterOS 7.20.8

- 4 separate interfaces (no VLANs, separate bridges/IPs per interface):

  • ether5 → 192.168.88.0/24 (main LAN)

  • ether6 → 192.168.99.0/24

  • ether7 → 192.168.30.0/24

  • ether8 → 192.168.40.0/24

- Dual WAN load balance (BLESS + LIGGA) with SDWAN failover

**Printers involved:**

- 192.168.88.247 — Brother MFC-7860DW

- 192.168.88.250 — Brother MFC-8085DN

- 192.168.99.231 — Brother MFC-8157DW

**The problem:**

The "Scan to PC" button on the Brother printer panel does not work when the PC is on a different subnet than the printer. Printing works fine via IP. ControlCenter4 scanning from the PC side also works. The issue is specifically when the user presses the physical Scan button on the printer and selects a PC destination — it shows the PC name but fails to connect.

**What I already know:**

- Ping works between all subnets :white_check_mark:

- Routing between subnets is working :white_check_mark:

- The printer initiates the connection back to the PC (port TCP 54921/54925)

- This is a broadcast/registration issue — the PC registers itself on the printer via ControlCenter4, but this registration fails across different subnets

- netstat confirms UDP 54925 is LISTENING on the PC (0.0.0.0:54925) :white_check_mark:

- TCP 54921 is NOT listening — this seems to be the root cause

**What I have already tried:**

- Disabled all inter-VLAN firewall blocks between printer networks and PC networks

- Added forward accept rules for ports 54921 and 54925 (TCP and UDP) in both directions for all subnet combinations

- Enabled mDNS Repeater on all interfaces (ether5, ether6, ether7, ether8)

- Added UDP broadcast relay via NAT dstnat for port 54925 on all interfaces pointing to printer IPs

- Added NAT masquerade (srcnat) for traffic destined to printer address-list — removed after realizing it breaks the return path

- Disabled Windows Firewall completely on test PC — scan still failed

- Added Windows Firewall inbound rules for ports 54921, 54925 (TCP/UDP) with remoteip=192.168.0.0/16

- Verified mangle already has "bypass local traffic" rule at top (dst-address-type=local)

- DHCP servers are on separate interfaces, not bridges

**Current firewall rules (relevant):**

```routeros

/ip firewall filter

add action=accept chain=forward comment="ACCEPT ESTABLISHED/RELATED" \

connection-state=established,related

add action=accept chain=forward comment="PRINTERS TO ALL NETWORKS" \

dst-address=192.168.0.0/16 src-address-list=IMPRESSORAS

add action=accept chain=forward comment="ALL NETWORKS TO PRINTERS" \

dst-address-list=IMPRESSORAS

```

**My theory:**

The Brother ControlCenter4 registers the PC on the printer using broadcast UDP 54925. Since broadcast doesn't cross routers, the registration never completes. TCP port 54921 never opens because registration failed. The printer sees the PC name (cached from before network segmentation) but can't connect because it doesn't know the real IP of the PC on the other subnet.

**What I think the solution is:**

Configuring "Scan to Network" (SMB/FTP) directly on each printer's web interface with fixed IPs for each PC. However, we have 50 PCs on DHCP and users strongly prefer using the physical scan button on the printer panel.

**Questions:**

1. Is there any way to make Brother's "Scan to PC" registration work across different subnets on MikroTik without setting static IPs on every PC?

2. Has anyone successfully configured a UDP broadcast relay that allows ControlCenter4 to register across subnets?

3. Is there a better approach for this specific use case (50 DHCP PCs, multiple subnets, Brother printers)?

Thanks in advance!

**Router:** MikroTik RB5009UG+S+

**RouterOS:** 7.20.8

**Printer models:** Brother MFC-7860DW, MFC-8085DN, MFC-8157DW

**Windows:** Windows 11 (22H2)

Semi-random thought, but if static addresses work, can't you set the DHCP server to assign a given IP to a given MAC (the result would be "dynamically static IP's")?

What did they answer you from "Brother"?

Would love to see your config, looking forward to all the bridges/vlans/firewall rules:

/export file=anynameyoulike

Remove serial and any other private info, post as Preformatted text by using the </> button.

since you mentioned names used on printer’s lcd, propably you need to change them to IP or:

A good write up of the problem, with everything well described. The things which stand out for me:

I just wonder if the Brother scan to network might be layer 2 [MAC addresses] rather than layer 3 [IP addresses]. It ought still to see all devices if they are on the same broadcast domain, but you never know with the network implementation on printers But let's put that thought to one side for the moment

It looks significant to me that the printer sees PC names from before segmentation and I think that what you should do here is, as a trial, try your proposed solution of configuring for just 1 computer by IP address, ideally a computer which is not known to the Brother devices. This is not necessarily as the fix for your problem. It is more to get a handle on whether it is a question of resolving names across your segmented network or if it is more an issue of ports

Hi! Your solution worked perfectly! Thank you so much!

After days of trying everything — firewall rules, NAT masquerade, UDP broadcast relay, mDNS repeater, DHCP2DNS scripts — the fix was exactly what you described: a single input rule allowing mDNS traffic before it got dropped.

The root cause: The MikroTik was silently dropping mDNS packets (224.0.0.251:5353) on the input chain before the mDNS Repeater could even process them. The Repeater was configured correctly all along, but it never received the packets.


Complete solution for anyone facing the same issue:

Environment:

  • MikroTik RB5009UG+S+ — RouterOS 7.20.8

  • 4 separate networks on individual interfaces (no VLANs):

    • ether5 → 192.168.88.0/24

    • ether6 → 192.168.99.0/24

    • ether7 → 192.168.30.0/24

    • ether8 → 192.168.40.0/24

  • Brother printers on 192.168.88.x and 192.168.99.x

  • ~50 Windows 11 notebooks distributed across all networks

Problem: Brother "Scan to PC" button on the printer panel failed when the PC was on a different subnet. Printing via IP worked fine. ControlCenter4 scanning from the PC side also worked. Only the physical scan button failed.

What did NOT work:

  • Forward chain firewall rules between subnets

  • UDP broadcast relay via NAT dstnat on port 54925

  • TCP/UDP rules for ports 54921 and 54925 in both directions

  • NAT masquerade for printer address-list

  • Windows Firewall rules and complete disabling

  • mDNS Repeater alone (without the input rule)

  • DHCP2DNS script for dynamic hostname resolution

What WORKED — the actual fix:

Step 1 — Create an interface list with all LAN interfaces:

/interface list
add name=MDNS-INTERFACES

/interface list member
add interface=ether5 list=MDNS-INTERFACES
add interface=ether6 list=MDNS-INTERFACES
add interface=ether7 list=MDNS-INTERFACES
add interface=ether8 list=MDNS-INTERFACES

Step 2 — Add input rule allowing mDNS BEFORE any drop rule:

/ip firewall filter
add action=accept chain=input comment="allow mDNS" \
    dst-address=224.0.0.251 dst-port=5353 \
    in-interface-list=MDNS-INTERFACES protocol=udp

Step 3 — Enable mDNS Repeater on all interfaces:

Go to IP → DNS → mDNS Repeater Interfaces and add ether5, ether6, ether7, ether8.

Why this works: The mDNS Repeater needs to receive multicast packets on the input chain first. Without the firewall rule, the packets were being dropped before reaching the Repeater. Once the input rule was in place, the Repeater could properly relay mDNS announcements across all interfaces, allowing Brother printers and PCs on different subnets to discover each other — making the physical "Scan to PC" button work perfectly across all networks.

Key insight: This is NOT a forward chain problem. mDNS traffic goes through the input chain on the router itself, not through forward. That's why all the forward rules we tried made no difference.

Hope this helps someone! :bullseye:

@Victor_21 Thanks for such a great example of a great topic.

Your initial post had relevant info, and your followup is what makes this really useful for future people with similar problems. It will probably apply to more than just Brother printers.

Thanks again for taking the time to post your follow up with the solution.

Thanks @Victor_21 ! Luckily I stumbled on this topic. That actually solved my mDNS issue (AirPlay and Chromecast) without need for further investigation (didn’t find time to deal with that) between restricted VLAN and my smart TV on LAN which I noticed after I was upgraded ROS to some version.

When I initially setup mDNS for my scenario (with first ROS version where mDNS feature is implemented) only LAN bridge and VLAN interface was added to mDNS repeater interfaces and somehow it worked without that input rule, not sure how because there was no input rules for VLAN and dst 224.0.0.251:5353 UDP, only TCP and UDP forward rules for some ports from VLAN to smart TV needed for casting protocols. But that stopped working eventually after some upgrade (was that input silently accepted for repeater interfaces and now not, idk), so this helped and saved my time.

It has already helped someone without a Brother printer.

To make it more easy to find for people trying to get mDNS working, perhaps include mDNS in the topic title (if you edit the first post, you can edit the title).

Brother Scanner “Scan to PC” button not working across VLANs/separate networks on RB5009 — RouterOS 7.20.8

possiblly replace with:

Brother “Scan to PC” button not working across VLANs/separate networks on RB5009 — mDNS RouterOS 7.20.8

Since the original is already long, perhaps remove the "Scanner" after Brother, since the scan to PC reference implies a scanner is involved.

edited the title..

Sent solution link to MT, suggesting, they improved documentation with this important information.