Printer (Brother/Epson) support for IoT VLAN

I have succeeded in getting a Brother HL-2135W laser printer working across VLANs.  I assume this solution will work for most if not all Brother network printers.  Subsequently, I've found that the same protocols are used by an Epson WF-3640 inkjet printer and the solution also works for that printer.

I quickly worked around Windows printer discovery by entering the static IP address in to the printer Port configuration.

But I had struggled to get the Brother Print Services (Android) plugin working.  The solution required some firewall rules and a utility to send broadcasts between VLANs.

My network is split into multiple VLANs for security.  An Ubiquiti EdgeRouter is used for routing between networks and firewalling communications that should not be allowed.

In the diagram I have these networks:

1. Guest Network.  These are user devices - and include most phones and laptops.  These are devices that need controlled access to other things, but do not need to host services themselves.
2. Core Network.  Small set of trusted devices and servers.
3. IoT Network.  The untrusted devices.  Smart devices and printers that generally only need access to the Internet.  Clients from other networks (including from Guest and Core) can access devices in the IoT Network.

I had used the Brother Print Services plugin prior to setting up VLANs, but with VLANs in-place I could not print from my phone unless I connected to the IoT Network.

I used tcpdump on the EdgeRouter to analyse the communication and discovered that 3 protocols were involved.

• Multicast DNS (mDNS).  I had already enabled the mDNS repeater on my EdgeRouter for Chromecast so this was functioning between the VLANs.
• Simple Network Management Protocol (SNMP).
• Internet Printing Protocol (IPP).

IPP/mDNS problems

On further investigation I believe the mDNS/IPP protocol requests come from the Default Print Service plugin and are not part of the Brother Print Services plugin.

The IPP communication immediately highlighted a problem.  The Get-Printer-Attributes request gets an error (404) response.  The request contains this URI:

printer-uri (uri): 'ipp://<PrinterIP>:631/duerqxesz5090'

Tracing it back, I can see an mDNS response from the printer containing this "resource path":

rp=duerqxesz5090

There appears to be no way to override this behaviour in the Brother Print Services plugin, though you can probably edit the CUPS configuration on Mac OS X or Linux.  On further investigation I can see exactly the same problem when my phone is on the same VLAN.

SNMP problems

The Brother Print Services plugin sends SNMP discovery messages to the printer using UDP broadcasts.  These were not crossing the VLANs, so the printer didn't even get a chance to respond.

Basically broadcast packets are only sent to devices in the same LAN segment and are specifically not routed.

However since the Brother Print Services plugin does not have any means of configuration, I had to find a way to forward these SNMP packets to the printer.

UDP Broadcast Relay for SNMP

Turns out there is a utility UDP Broadcast Relay written by Joachim Breitner that does this forwarding or relaying of UDP broadcasts.  This has been ported to EdgeOS (Ubiquiti EdgeRouter OS) and can be downloaded from ubnt-bcase-relay GitHub.

With this utility installed, it is necessary to list all network interfaces that will participate in the relaying.  The address setting is not used because I want the original source address used in the forwarded request.

With this configuration active, I can see that UDP broadcasts to port 161 on one network (e.g. 192.168.1.255/32) will then be broadcast on the other network(s) (e.g. 192.168.10.255/32).  The printer is seeing these requests and responding.

Local Firewall rule for SNMP Broadcast Relay

However the UDP request and only getting through from the Core network to IoT, but not from the Guest network to IoT.  The difference is that Core does not have firewall rules in-place, but Guest does.

The problem is that for the Guest network I'm specifically blocking requests directed to the router itself.  The only packets I'm allowing through are DNS, DHCP and mDNS requests.  So, on the "local" firewall rule on the Guest network, I added the following rule:

• Accept UDP
• State = New
• Destination = Broadcast IP port 161

Now requests are reaching the router and getting relayed from the Guest network too.

Inbound Firewall rule for IoT SNMP Responses

SNMP responses are not getting back to the client VLANs.  This surprised me because in other cases the Established/Related firewall rule has successfully allow replies through the IoT router interface.

Research indicated that Established/Related should also work for UDP request/response.  I tested this, and found the responses were not coming back when using the broadcast address.

The problem is twofold.  Firstly, the request packet is sent to the router directly, then bcast-relay duplicates that packet and broadcasts it from the router on the new network.  Effectively it is not going through the routing firewall, hence a reply packet cannot match up as part of an established session.

Secondly the response packet uses a different (source) IP address for the reply, giving another reason why the firewall cannot detect this as being part of an established session.

Basically the UDP response from the printer is being seen as an entirely new session.  Hence I need a firewall rule for the IoT network to initiate routable SNMP requests.  This is the "in" firewall rule I configured for the IoT network:

• Accept UDP
• State = New
• Source = Printer IP port 161
• Destination = All RFC1918 LAN networks

With that, printing now works from my phone.

Summary

I hope you find this useful if you are having VLAN problems with your printer.

As mentioned at the start, I have successfully used this solution with:

• Android Brother Print Service plugin connecting to Brother HL-2135W laser
• Android Epson Print Service plugin connecting to an Epson WF-3640 inkjet

Please message me in the comments if you have success with your printer - particularly if it is a different brand.