Degraded printer functionality until ICMP enabled on LAN side of firewall

[Lu]

I'm posting this in the hope others benefit from our pain. After a large Toshiba printer/MFC was replaced on our network with a newer model (an e-STUDIO3525AC), it had a great deal of trouble. The previous model had worked fine, and there were no changes to the OPNsense box's config between the two. Despite trying both dynamic and static network configs, IPv4-only, IPv6-only, etc., the new one could not get DNS resolution of any address, could not ping public IP addresses (even directly, like 8.8.8.8), and was generally poor at obtaining and holding onto its network config. It even complained at various points that the network cable wasn't connected. I used OPNsense's Interfaces > Diagnostics > Packet Capture, limited to the printer's MAC, and saw it was fairly chatty. I tested the new printer on a secondary physical network and all was okay, so it was something about the main network.

When I realised I could ping public addresses from my own PC, but not the firewall's, I found this thread about it. I enabled ICMP with this rule on the LAN interface, in order to test ping from the printer again:

Protocol	Source	Port	Destination	Port	Gateway	Schedule
IPv4+6 ICMP	*	*	This Firewall	*	*	*

To my surprise, everything started behaving. I'm not blaming OPNsense; I think the printer was deciding it wouldn't or couldn't do basic communication without the router responding to certain queries, or something. If you're experiencing such issues, they may be being triggered by default firewall policies.

[meyergru]

...which by default allow any to any for any IP protocols on LAN? ;-)

[drosophila]

Would be interesting to know if the printer would also work normally if it had no gateway set at all. IMO a printer has no business outside its local network, anyway, so doesn't need / shouldn't have a gateway.

[meyergru]

Depends on what the machine can do. For example, if it can scan/fax, it needs the time, which is also needed for logging. If that is the case, it could use an NTP server. Of course, it could get the NTP sever IP via DHCP, but as it turns out, there are plenty of devices which use arbitrary cloud NTP servers - like AppleTVs, e.g.

Also, some devices look for firmware updates, can order consumables in advance a.s.o., let alone collect statistics and push that to the manufacturer without anyone knowing.

There are good reasons to put "smart" devices into a separate VLAN.

[drosophila]

Also, some devices look for firmware updates, can order consumables in advance a.s.o., let alone collect statistics and push that to the manufacturer without anyone knowing.

There are good reasons to put "smart" devices into a separate VLAN.

Indeed, that's what I was implicitly hinting at, and rather than ordering consumables I'd rather have it send a mail to the admin instead, and use a local NTP server, but I accept that the default configuration might be catering to the person who plops down the device, pops in some cables and then expects it to work until it's decommissioned. Of course, this affords privacy and security only to those select "elites" who at least know what might be happening and therefore might try to prevent them.