Main VLAN to Printer VLAN

johnpoz

@tpickard said in Main VLAN to Printer VLAN:

Firewall rules don't seem to work for this, I'm guessing it is a routing issue.

Firewall rules are not going to work if you trying to discover printers via say like airprint. Nor is it a routing problem.

Printing across vlans is not a problem - you just need to allow the port your printing with.. 9100? 631 IPP?

For discovery of printers with something like airprint you would need to setup Avahi. And allow the proper ports in the firewall.

edit: you have a typo? Your main vlan you list 192.168.2.x and other vlan 192.168.2 as well??

tpickard

@johnpoz I have that installed, but it would appear that I haven't managed to get it setup properly. Is there a good guide for this?

johnpoz

@tpickard I thought I had ran through this with another thread.. Let me see if I can find it BRB.

edit: here is thread where validated avahi setup
https://forum.netgate.com/post/1003226

I thought there was one were actually tested airprint.. Let me look for that one..

edit2: Hmmm be lots of threads about printers over the years.. Maybe I was confusing them with doing the DNS stuff for airprint to work and not running avahi. But the thread I linked to goes over validating avahi is working.

I have a airprint capable printer, and multiple vlans I can test from, etc. Its getting a bit late here now, and want to watch some TV... But sure I will find some time in the morning tmrw to run through it..

But that post I linked to does go over airprint and seeing my printer IP in the sniff, etc. But I can better document setting up everything tmrw.

johnpoz

@tpickard Ok grabbed my phone.. Its on my guest wifi network 192.168.6/24.. It can not find my printer via airprint which is on my 192.168.2/24 network.

So I configure avahi on these 2 interfaces. The network of my guest wifi w_guest, and the network the printer is on wlan.

I configure a firewall rule, using floating so know its going to be before any interface rules, allowing the 224.0.0.251 multicast address, and set it as quick.

I then make sure my guest network is allowed to actually talk to my printer to print.

Now I could limit this to the specific port using for printing - but this was just easier to do a any any rule to the printer IP for this test..

I now on my phone can see the printer

And there you go - printed a test page.. See my link to troubleshooting avahi via sniffing, etc.

If you want to lock down the rule you allow to the printer IP, I would set the rule to log traffic so you can see what ports are used. Or sniff while your doing a print..

tpickard

I’ve been beating my head against this wall again today and not getting to where I need to be. Here’s some of the details of what I’ve tried.
Applying the KISS principle to my troubleshooting (because I’m feeling pretty stupid at this point), I cut the Avahi service and floating rule back to just Guest and Printer networks to start with.
(Note: Canon printer settings confirmed for mDNS “ON”.)

This is the capture on Guest Network (192.168.7.x). From phone to printer using Canon Business Print (CBP works on Main Network (192.168.1.x) when bridged.

This is the capture on Printer Network (192.168.2.x) in a second run.

Here is a capture on the Printer network after adding the other networks I want this for on Avahi only. The other networks are bridged.

Adding the LAN interface on the floating rule gets me this:

Thinking there might be an issue with the Guest firewall rules I added an Any-Any rule and disabled the Any-!VLAN_IPv4 rule. While it still allowed the internet connection it didn’t pass the 224.0.0.251 traffic to the Printer VLAN.

I’m at a loss. What are my next troubleshooting steps?

johnpoz

@tpickard you didn't select quick on your floating.

See on my rule where the 2 little green arrows

And I did state QUICK..

Also the rule guest35 net to guest35 net is pretty pointless, because stuff on guest35 doesn't go through pfsense to talk to other stuff on guest35 net.. Now your ! vlan, I have no idea what is in there, but I doubt it would allow multicast.

You need to allow your network to talk to the actual ports your going to be using to print with.

! rules can be problematic - it is going to be better to be explicit in what you allow or block.

tpickard

Added the Quick and changed to the Any-Any rule for internet.

Still the same thing. The app cannot find the printer even searching that IP.

The Guest to Guest was for DHCP. DHCP is on the pfSense and for some oddball reason without a rule telling it to allow traffic to the gateway clients couldn't get an IP.

johnpoz

@tpickard said in Main VLAN to Printer VLAN:

The Guest to Guest was for DHCP. DHCP is on the pfSense and for some oddball reason without a rule telling it to allow traffic to the gateway clients couldn't get an IP.

No - when you enable dhcp, hidden rules are added to allow for dhcp..

[21.05.2-RELEASE][admin@sg4860.local.lan]/root: pfctl -sr | grep DHCP
pass in quick on igb0 inet proto udp from any port = bootpc to 255.255.255.255 port = bootps keep state label "allow access to DHCP server"
pass in quick on igb0 inet proto udp from any port = bootpc to 192.168.9.253 port = bootps keep state label "allow access to DHCP server"
pass out quick on igb0 inet proto udp from 192.168.9.253 port = bootps to any port = bootpc keep state label "allow access to DHCP server"
pass in quick on igb2 inet proto udp from any port = bootpc to 255.255.255.255 port = bootps keep state label "allow access to DHCP server"
pass in quick on igb2 inet proto udp from any port = bootpc to 192.168.2.253 port = bootps keep state label "allow access to DHCP server"
pass out quick on igb2 inet proto udp from 192.168.2.253 port = bootps to any port = bootpc keep state label "allow access to DHCP server"
pass in quick on igb2.4 inet proto udp from any port = bootpc to 255.255.255.255 port = bootps keep state label "allow access to DHCP server"
pass in quick on igb2.4 inet proto udp from any port = bootpc to 192.168.4.253 port = bootps keep state label "allow access to DHCP server"
pass out quick on igb2.4 inet proto udp from 192.168.4.253 port = bootps to any port = bootpc keep state label "allow access to DHCP server"
pass in quick on igb2.6 inet proto udp from any port = bootpc to 255.255.255.255 port = bootps keep state label "allow access to DHCP server"
pass in quick on igb2.6 inet proto udp from any port = bootpc to 192.168.6.253 port = bootps keep state label "allow access to DHCP server"
pass out quick on igb2.6 inet proto udp from 192.168.6.253 port = bootps to any port = bootpc keep state label "allow access to DHCP server"
pass in quick on igb5 inet proto udp from any port = bootpc to 255.255.255.255 port = bootps keep state label "allow access to DHCP server"
pass in quick on igb5 inet proto udp from any port = bootpc to 192.168.7.253 port = bootps keep state label "allow access to DHCP server"
pass out quick on igb5 inet proto udp from 192.168.7.253 port = bootps to any port = bootpc keep state label "allow access to DHCP server"
pass in quick on igb3 inet proto udp from any port = bootpc to 255.255.255.255 port = bootps keep state label "allow access to DHCP server"
pass in quick on igb3 inet proto udp from any port = bootpc to 192.168.3.253 port = bootps keep state label "allow access to DHCP server"
pass out quick on igb3 inet proto udp from 192.168.3.253 port = bootps to any port = bootpc keep state label "allow access to DHCP server"
[21.05.2-RELEASE][admin@sg4860.local.lan]/root:

You could have zero rules on an interface and dhcp would still work.

As to finding it via IP? What client are you actually using? And are you using airprint... In the link I gave for troubleshooting I show looking at the traffic that is sent and gotten back via the mdns packets forwarded by avahi.. What are you getting back?

If your not using something like a phone or tablet - you can just add the printer. Windows for example I just add the printer via the IP.. As long as your firewall rules allow the traffic.

Another PROBLEM you could have, but you should see be able to see it via discovery if your doing airprint is printer not having a gateway. If the printer has no gateway setup, or its pointing to something other than pfsense.. You wouldn't actually be able to print to it from another vlan.

edit:

The other networks are bridged.

Your not bridging this guest35 and printer7 interfaces?

tpickard

The client is Canon Print Business on an Android smartphone.

It has an Auto Search (WiFi), which I tried but it failed to find the printer.

It also has a Manual Search (WiFi), which involves searching a user specified IP address for a compatible printer. This also fails though it certainly shouldn't. This method does work when a Network Bridge is in place, but my understanding is that a bridge basically defeats the purpose of having the VLANs.

johnpoz

@tpickard said in Main VLAN to Printer VLAN:

This also fails though it certainly shouldn't.

Why is that if only searching the vlan your on..

Avahi allows for mdns to work (airprint).. I have no idea what auto search thing is doing.. You could sniff the mdns traffic your seeing when you sniff..

Yes a "bridge" would work with any sort of L2 discovery because its the same network just using a bridge to connect multiple parts of it.

Sadly I have no android devices phone or tablet to play with - my son has a android phone. Next time he is over - I might grab his phone to do a bit of testing with. Off the top of my head I don't think out of the box android phones do airprint?

Only thing I can suggest as a easy solution to printing.. Is put your printer on the vlan you want to print from on your wifi network. Be this guest or your trusted wifi network - just at a lost to why a "guest" would need to print ;) heheh

Your PC or linux boxes devices would be able to print - because you can manually add the printer and install a driver. All you need to do is point it to the IP. So it really doesn't matter what vlan they are on.

I am not a fan of breaking the L2 barrier. even if just mdns.. My printer sits on my normal wifi network via a wire where my devices connect. Phone, wifes phone, tablets, laptop, etc. Other wifis are for iot and rokus, etc. They have no need to print. So the stuff like phones and tablets (apple devices) can use airprint to find the printer.

My PC on another vlan just has that priner manually configured. Same goes for my laptop so doesn't matter what network its on be it wired or wireless guest or trusted, etc. etc.

Biggest issue is if for some reason has moved her phone over to guest.. I should prob just remove that network ;) But I don't do any sort of dns filtering on that network - so if she wants to see some specific ad or something that I normally would block - she can switch to that. But when she yells she can't print its because she is not on the normal wifi ;)

So I get to keep my isolation of vlans - and wife has to deal with being on the correct wifi if she wants to print.. Its a workable solution with the least amount of pain ;)

Other option is maybe put a cups server on your network you want to print from, where it can share the printer it connects to on different wifi ssid and not have to use discovery or break any L2 boundry.. A pi prob be a good option for that sort of solution.

tpickard

@johnpoz
Thank you for all the time you've spent on this.

I wrote a long reply to you, but dropped it because I think I've been going in the wrong direction with this.

(The Guest network is only being used because there is nothing on it to get messed up. My wife is upset with issues she's had since I started, not realizing more than half were happening because of her phone not my changes. Using the Guest network allows me to experiment until I get it right and keep her from getting pissed.)

Avahi deals with broadcast traffic. Forget the Avahi, it isn't really relevant to the actual problem. In fact the real problem is probably causing the Avahi to fail.

The problem is:
I want to be able to establish a connection or ping from one VLAN into another without the second VLAN being able to do the same in reverse. With pfSense being stateful once established the two devices will remain connected until the session is complete. Currently that will not occur without the bridge. Even when I provide the IP the traffic isn't being routed to the other interface.

When I ping the printer at 192.168.2.10 from a device on the 192.168.7.x subnet, it doesn't get to the 192.168.2.x subnet. This is true for any other connection type. Until I find out why traffic isn't getting to the right subnet and fix this issue, nothing will work without the bridge. On the subnets the bridge is active on, all of this works. I don't want to leave the bridge because it is overkill and allows the 2 way communication I don't want.

What I've been expecting is that when the 192.168.7.1 gateway receives a request for traffic to the IP 192.168.2.10, since it is not on the 192.168.7.x network it will pass it on to the router to send it to the correct network. I thought (because I don't really know what I'm doing) that since the router is also connected to the 192.168.2.x network through the gateway at 192.168.2.1, it would route the request there and the traffic would get to the printer at that IP. They are on the same physical port so it should be easy right, wrong.

So the real question I should be asking is: how do I set up pfsense to send traffic for 192.168.2.10 to the subnet it is on?

johnpoz

@tpickard said in Main VLAN to Printer VLAN:

Avahi deals with broadcast traffic. Forget the Avahi, it isn't really relevant to the actual problem

No it is required if you want airprint to work across vlans.

I want to be able to establish a connection or ping from one VLAN into another without the second VLAN being able to do the same in reverse.

Well then set the rules that way.. Out of the box lan would be able to ping anything in vlan X.. But without rules on vlan X it would not be able to ping anything in Lan.

connected to the 192.168.2.x network through the gateway at 192.168.2.1, it would route the request there and the traffic would get to the printer at that IP

It would if the rules on allowed it.. But again - that is not going to "discover" the printer.. Its just not.. airprint uses mdns to discover a printer. For that to work across vlans you would need avahi setup.

But if you just want to ping the printer IP, that would work out of the box from lan to vlan without zero rules on vlan. As long as the printer gateway pointed back to the IP of pfsense in its own network.

tpickard

@johnpoz said in Main VLAN to Printer VLAN:

@tpickard said in Main VLAN to Printer VLAN:

Avahi deals with broadcast traffic. Forget the Avahi, it isn't really relevant to the actual problem

No it is required if you want airprint to work across vlans.
Airprint isn't required. The Canon app on Apple does the job without broadcast traffic being required.

I want to be able to establish a connection or ping from one VLAN into another without the second VLAN being able to do the same in reverse.

Well then set the rules that way.. Out of the box lan would be able to ping anything in vlan X.. But without rules on vlan X it would not be able to ping anything in Lan.
It isn't working that way. I could ping the 192.168.2.x gateway from 192.168.1.101, but couldn't ping, reach the web interface, or print to the printer. The rule on 192.168.1.x should have allowed it. Same deal with the NASes on 192.168.7.x.

connected to the 192.168.2.x network through the gateway at 192.168.2.1, it would route the request there and the traffic would get to the printer at that IP

It would if the rules on allowed it.. But again - that is not going to "discover" the printer.. Its just not.. airprint uses mdns to discover a printer. For that to work across vlans you would need avahi setup.

But if you just want to ping the printer IP, that would work out of the box from lan to vlan without zero rules on vlan. As long as the printer gateway pointed back to the IP of pfsense in its own network.

It pointed back to the gateway IP on that VLAN.

At this point, I have changed the printer and NASes to the main. I have a new switch arriving today, it's the same model as my current switch. That gives me a backup and something to test with using the backup pfSense appliance. I'll just take my time figuring out which devices to use for testing. I have a pi, several routers, and a few other things I really should have gotten rid of. I should be able to set up a decent test network so I'm not stuck waiting for my wife to be asleep.

I'm going to table this issue for the moment. take my time setting things up and give my patience a rest. I'll come back to this thread in a couple of weeks.

Thanks again for all the help!

tpickard

@johnpoz
The forum is flagging this for spam so I can't edit the post I just did to get the quotes right.