Printer not working across VLANS
-
Hi, I hope I can get some help with this issue. I am at a site have not been to before and am trying to untangle why people can't print from the Wi-Fi and other subnets. There is a floating rule with quick match allowing the different subnets access to the printer on ports (pictured below):
ports allowed:
WLAN has its own block rule from the LAN network, which is where the printer resides. The other is a part of an interface group with a similar rule. My understanding is that floating rules resolve before the interface rules, so those block rules couldn't be the issue (right)?
WLAN:
Other Subnets:
I know the rule matches show zero, but the block rules had hits, I had disabled them in an attempt to get things working with no luck. So, I re-enabled them. I've also migrated the devices on the radio network from an unmanaged switch to the same managed switch the printer is on. My thinking in doing this was that the unmanaged switch couldn't pass VLAN traffic and that is why it didn't reach the printer. Still no luck. I am one of one here, no one else to turn to for help figuring this out. Any help is greatly appreciated.
-
@nohairitguy Why are you trying to use Floating Rules for this? Have you read https://docs.netgate.com/pfsense/en/latest/firewall/floating-rules.html (especially the
"Precautions/Caveats" section)? That's really not the intended use. If you're trying not to have to make redundant rules on every LAN/VLAN interface, use Interface Groups, not Floating Rules...Start simple ... just focus on one network at a time. E.g. RADIO network, make an allow rule to WLAN or LAN subnet. See if that works... then expand from there. Add more interfaces. Enable logging on the rules to help you figure out where things are getting blocked.
-
Do you mean they can't click on a icon? Or even when they have the IP for the printer they can't use it. The first method relies on broadcasts to work, but broadcasts are not passed through a router without help. The second would be a routing or filter problem.
-
@JKnott Initially the printer was not reachable at all, could not add it to any computer on either network. I've been plugging away at this morning so far and have found that nothing from Radio can reach LAN. I've followed luckman's advice and removing the floating rule in favor of interface rules. WLAN network can print now. But Radio group still can't talk to LAN at all.
-
@luckman212 Thanks, I've done so and now have one (WLAN) of the two problem networks printing. The Radio network group can't reach anything on the LAN network though. Still puzzling that one out.
-
@nohairitguy good. not sure if you've tried already, but there may be some stale states lingering around that are blocking traffic -- if you haven't rebooted the entire firewall or at least reset the state table, I would try that first ... if it's still failing then my previous suggestion of enabling logging on your rules wherever you can, and then inspecting the firewall log may reveal where the blocking is happening.
-
@luckman212
Oh Interface Groups, that's such a good idea,I hadn't thought of that. I've some homework to do now
-
I think I may have an idea but I'm not sure. So, the interface group (Radio Group) is assigned to igc1 (named Radio Trunk) that has no IP settings but is enabled.
I enabled logging on the rule for printing from the interface group and do see points where the computer I'm working with is able to contact the printer on 9100. I've been able to add the printer but have to specify it communicate over 9100 (RAW) and also have to manually add the driver. No print jobs get through.
But I also see this:
I know thats mDNS but could it be blocking other traffic? I'm checking the logs now to see that.
Do I need to disable igc1? Is the fact that it is enabled causing this issue and why? Feel like I'm over my head a bit with this.
-
I have to admit without a complete picture (diagram, or at least a full list) I'm struggling to follow along with the network design you've got here. What are RADIOTRUNK, BARIX, and PROPHET?
Big picture, blocking mdns should not prevent you from adding a printer manually, but unless you install something like the mdns-bridge package to proxy that multicast traffic, you won't be able to auto-discover printers across VLANs.
-
@nohairitguy said in Printer not working across VLANS:
Initially the printer was not reachable at all, could not add it to any computer on either network.
Firewall rules will not help with this. Adding a printer requires mDNS forwarding. Are you doing that? Using mDNS-Bridge or Avahi?
-
@dennypage Avahi is being used for mDNS broadcast.
-
@luckman212 I understand. There were two of us where I'm working now and that other person handled stuff like this. They left (a while ago) so I'm trying to pick up things. I'll do my best to detail things. Barix and Prophet are VLAN networks. Prophet hosts some automation and is a member of the Radio network group. Barix network is for a device that has some port forwards, it is completely isolated and does not need printing. All the networks on the firewall cannot communicate with each other except for pass thru rules for things such as printers and only on the ports needed communicate with the device. People do work from the automation computers on the Prophet network though and they also need to print sometimes.
Physically it's not a very complicated configuration. The pfSense box is both the router and firewall for the network. LANs are passed over to a managed switch and distributed from there.
I thought I had this figured out when I first arrived as all the devices on the Prophet network were on their own unmanaged switch. So, I'd assumed that the switch was the issue because it (the unmanaged switch) can't handle VLANs. I moved all the prophet devices to managed switch after tagging/untagging the needed interfaces. That didn't fix things. I'm still puzzling this out but am now handling tickets and other stuff so I may not be as responsive. Thanks again for the help.
-
Hmm. Ok well come back here with specific questions when you've back at it. For now, I suggest ditching Avahi (which is fairly buggy) and replacing it with @dennypage 's excellent mDNS-bridge, which has 0 bugs
-
@luckman212 said in Printer not working across VLANS:
@dennypage 's excellent mDNS-bridge, which has 0 bugs
A bold claim...
-
@nohairitguy said in Printer not working across VLANS:
, I'd assumed that the switch was the issue because it (the unmanaged switch) can't handle VLANs.
you can for sure use a dumb or non vlan aware switch - if its only in 1 vlan.
managed switch (access vlan X untagged port) -- dumb switch -- devices all in vlan X
Odd that a place of work, must be a tiny little business? Would use discovery to find printers. Why would work devices not point to the printers by IP or fqdn. Why would there not be a print server?
Are they trying to leverage devices like IPads or tablet devices or phones as work devices to print with? Any actual OS, windows, linux etc would allow for directly adding a printer vs having to use discovery to find it. Be it directly to the printer or via a print server.
-
@nohairitguy Another interim suggestion I would make is to ditch the port specific list and just allow all ports through to the printer's address. There is little value in trying to restrict individual ports to a printer, but if you want to do that I'd get it working without a port list first and add the port list after.
Privacy Policy · Cookie Policy