I have a slight issue with a Brother printer which is located on a different VLAN than the devices from which I intend to print from. My setup is quite simple:
VLAN ID10: Home devices
VLAN ID20: Work devices
VLAN ID30: IOT devices and Brother printer
The entire VLAN setup works apart of that I am unable to print from the devices located on VLAN ID10. I therefore made the printer IP static and added the following firewall rule:
add action=accept chain=forward comment=\
"Access Printer on Printing Network from Home Network" dst-address=\
192.168.30.8 in-interface=VLAN-Home out-interface=VLAN-Printer-IOT
This firewall rule allows me to ping the printer from the devices located on VLAN ID10. However I am still unable to print. I tried to add the printer via the dedicated IP directly in windows (“add a printer or a scanner”) and also via the Brother software (the software can initially locate the printer, but is also unable to add it). Does anyone have an idea what I am doing wrong?
The firewall goal is:
As strict as possible firewall rules
VLANs shall not communicate with eachother (exception: VLAN ID10 devices shall be able to send data to the printer located on VLAN ID30 for printing purposes, but not the other way around)
This firewall rule allows me to ping the printer from the devices located on VLAN ID10. However I am still unable to print. I tried to add the printer via the dedicated IP directly in windows (“add a printer or a scanner”) and also via the Brother software (the software can initially locate the printer, but is also unable to add it). Does anyone have an idea what I am doing wrong?
For testing purposes connect one of the devices from VLAN ID10 to the VLAN ID30 (inside the printer subnet) and then try to print. Maybe it’s not a network/firewall issue but more printer/driver thing itself.
You need a second firewall rule that also allows the traffic from IOT / Print as in interface to the out interface home. Basically the “return traffic”.
Simple way to test firewall issue, is to add a dummy accept all rule at the end (before final drop rule) which you enable only for testing purpose (maybe even log that one if traffic is not too heavy).
If it works then, you know you filter some traffic that is needed… and need to tune filter rules.
My suspicion is rather with line of @McGremlin: printer might refuse communication with devices outside its own subnet (some kind of security setting). So either that has to be disabled or changed … or construct a SRC-NAT rule which will masquerade all traffic between VLAN10 and printer to appear to come from router itself, like this one:
/ip/firewall/nat
add action=masquerade chain=srcnat comment="masquerade traffic between normal LAN and IoT" \
in-interface=VLAN-Home out-interface=VLAN-Printer-IOT dst-address=192.168.30.8
Thank you everyone for looking into this, I appreciate all your inputs!
@anav: I am always very grateful for your feedback, however for once I am not entirely sure if I fully understand your response. Neither the printer nor anything else is connected to ether2 - ether5. Could you please elaborate why and how changing ether2 - ether5 may help?
@McGremlin: Good idea. I tried that, if a device is conntected to the wifi network “TestNet-Printer” (VLAN ID30), printing and all other services work without any issues.
@mkx: This may indeed be the issue. I have tried to apply your solution:
/ip/firewall/nat
add action=masquerade chain=srcnat comment="masquerade traffic between normal LAN and IoT" \
in-interface=VLAN-Home out-interface=VLAN-Printer-IOT dst-address=192.168.30.8
Unfortunately I receive the following error message: “failure: incoming interface matching not possible in output and postrouting chains”. Any ideas?
Hi Whussup…
I review the config from top to bottom and thus its what I noticed first off.
Concur it doesnt effect any of the wifi settings. However since you do have those port in /interface bridge ports, it still appears to the reader/reviewer to be in error for them to be disabled!
I know for printers where I need two way talk ( full setup of a printer to one PC) or the ability to send scanned items directly to a PC I will have to allow traffic originated in both directions
What mkx is saying is that if you allow pc user to originate traffic to a printer return traffic will be permitted by the existing rules.
I am saying something completely different in that for some printer functionality, the printer may need to originate traffic to the PC…
I see no reason to monkey with ( or should I say orange tabby with) sourcenat rules for printer case.
I have multiple printers in the house so I have
a. firewall address list for printers
b. firewall address list of users that need access to printer one way ( if not in the same vlan of course )
c. firewall address list of users, printer needs access to. add chain=forward action=accept comment=“users to printer” in-interface-list=LAN src-address-list=PrinterAccess dst-address-list=ListOfPrinters
add chain=forward action=accept comment=“printer to select users” in-interface-list=LAN src-address-list=ListofPrinters dst-address-list=selectUsers
Then just omit the in-interface property from NAT rule definition. You can instead use src-address property (e.g. src-address=!192.168.30.0/24 or something like that) to narrow down the effects of NAT rule if you feel urge to do so.
If you need/want to limit connectivity towards printer, it’s may be actually better to use firewall filter rules (there can be multiple affecting different aspects of connectivity towards printer(s) ) and with firewall rules it’s possible to use both in-interface and out-interface properties.
I have a similar problem with Mikrotik TB5009UPr+S+ with OS 16.2.
VLAN34 - Normal (192.168.34.0/24)
VLAN200 - IOT (192.169.200.40 Brother printer)
I did get it to work by:
Having the printer reside in the VL34 and install it with the Brother full driver and utilities EXE. The printer was found automatically and installed successfully.
Put printer into the IOT vlan
Static DHCP entry for printer inside to IOT VLAN set to 192.168.200.40
Note, that I even had to allow ICMP both ways so I can ping it. I thought that allowing the VLAN34->Printer ICMP would be enough. After I added the return ICMP Rule Printer->VLAN34 the ping started to work and both rules incremented their packet and byte counters. Weird…
Now I wanted to make everything from scratch again. I reinstalled my laptop to Win11 24H2, upgraded Brother firmware. I thought that the printer installation will be easy given all the FW rules were in place. But no. The automatic search feature in the Brother Full driver did not found the printer (I expected that cause they were not in the same broadcast domain). After putting the IP statically - printer was found immediately but installation failed. Even adding a FORWARD rule of allowing ALL from VLAN34->Printer and vice versa ALL from Printer->VLAN34 did not help.
When I tried to install the printer manually inside Windows, that worked, but scanner was always showing an error. Once I put the printer back to VLAN34 - install went smooth and functionality was 100%. Now I am going to add rules:
forward ANY → 192.168.200.40
forward 192.168.200.40 → ANY
to see, if some weird port is being hit. Will get you posted.
I suspect their full driver/app it’s using HTTP/S (443) or some additional to get info. But allowing ALL should work, you can also add a log=yes to rule to see what ports were actually used.
If you want discovery to work, you can likely use in the /ip/dns’s mdns-repeater-iface= using your IOT and main VLANs (and allow udp/5353 for mDNS in firewall too).
.. I was able to find the printer manually in the Brother install wizard:
.. with following FW log outputted:
… i got an immediate Error saying “The installer has detected a connection problem between your computer and the Brother MFC / Printer.”.
.. without having any relevant firewall log being added. It appears to me like it would use some broadcast-type communication before executing the printer installation, which does not hit any forward rules.
Well, at least we have a test of AI’s AGI abilities - if an LLM can figure out RouterOS config, we’re got AGI and domed. But seems were long way from that…
Change the “/interface mdns” to:
/ip/dns/set mdns-repeat-ifaces=LAN-34,IOT-200
And, the firewall rules are likely not optional, but needed.
I should note that the CLI offer “tab completion” - i.e., hitting the after /ip/dns/set or mdns-repeat-ifaces= lets you pick the interface. I find helps figure out options better than ChatGPT…
WORKS! Now I got a working Brother Wi-FI MFP printer, which prints and scans residing in a different VLAN than the client PC. BTW, the most recent firewall rules enabling mDNS UDP 5353 did not increment at all whilst installing the printer nor whilst printing/scanning. Will try to add the MFP on a different Windows 11 and Linux PC without those 2 FW rules to see, if they are needed at all.
One thing I have discovered after using this mDNS approach is, that before all traffic was TCP or UDP with one of these ports 137, 161, 515, 54921, 54925. Now everything runs only on these three combinations:
So obviously the Brother’s well known unicast ports have been replaced with HTTP and WSD.
Actually I do not like the behavior of this printer residing in a different VLAN. I would expect standard and transparent TCP/UDP unicast communication for printer and also for the scanner function, so it is obvious which ports should the traffic be locked down to. Now, one Win11 PC generates UDP traffic whilst printing or scanning and one this weird HTTP and WSD type of traffic. And I am using it only at home. I do not want to imagine what a pain in the ass it must be in an enterprise without using NG L7 firewall services with this kind of printer connected to the infrastructure. Anyway, I will put the printer back to my normal VLAN and lock the communication from/to it as much as possible. Thanx for all help.
@anav: Makes sense, thanks for pointing it out! I will adjust that
@mkx: I tried different nat variants, unfortunately it does not solve the problem. I guess firewall filter rules is the only way to go.
I will need some time figure out if the solutions above work and I will keep this forum updated, so other users have some feedback if they ever face the same issue. Just a quick general question: My goal was to enhance security by creating different VLANs and separating the printer & IOT devices from my home devices. From a strict security standpoint, what exactly is the remaining benefit of having the printer on VLAN30 and my home devices on VLAN10 if anyway need to grant the printer access to VLAN10 by creating e.g. the following rule:
add chain=forward action=accept comment=“printer to select users” in-interface-list=LAN src-address-list=ListofPrinters dst-address-list=selectUsers
Would it not be easier in such a case to simply allocate the printer to VLAN10?
What makes sense is specific to your location.
How is the printer connected to the router, via ethernet jack at specific location, are there managed switches in between etc etc…
Clearly if all users are in vlan10, why put it on its own vlan. If untrusted users are allowed to use the printer, nothing wrong with isolating the printer in its own vlan etc/
