Can print to printer on VLAN correctly but not open status webpage
-
Hi everyone, I've set up separate VLANS for Guests and IoT devices, all seems to be working correctly. I have Avahi installed as well so that the printers / devices on the IoT VLAN are broadcast to the rest of the network.
With the printers on the IoT VLAN, I can add them and print to them without any issues. I can query the ink / toner levels from the drivers as well without issue. However on the laser printer which has a built in webserver for status / config information, if I try to access it via bonjour or IP address, I get nothing - the page eventually times out with "The server stopped responding". I can ping the printer successfully and if I join the IoT VLAN, I can open the web-page without issue.
Any idea what is going on? I've posted my firewall rules below but if I disable them all (apart from the 'allow everything rules'), it still doesn't work…
:o


 -
Either:
-
One of the pfB rules on LAN is blocking the traffic
-
You are attempting to access from 192.168.0.246 host and it is being policy routed out WAN_DHCP
-
The printer has some sort of mechanism/firewall for only allowing same-subnet web admin connections
-
Perhaps it is a default gateway issue in the printer. You might be able to print to it if only one-way communication is necessary to do so but I doubt it. The printer's default gateway needs to be the pfSense interface.
Packet capture on the IoT interface on the printer's web admin address and port and try a connection. Stop the capture and post the results.
-
-
Here we go:
21:17:33.170273 IP 192.168.0.249.64848 > 192.168.20.30.80: tcp 0 21:17:33.172057 IP 192.168.20.30.80 > 192.168.0.249.64848: tcp 0 21:17:33.176584 IP 192.168.0.249.64848 > 192.168.20.30.80: tcp 0 21:17:33.180270 IP 192.168.0.249.64848 > 192.168.20.30.80: tcp 408 21:17:33.182011 IP 192.168.20.30.80 > 192.168.0.249.64848: tcp 0 21:17:33.182780 IP 192.168.20.30.80 > 192.168.0.249.64848: tcp 23 21:17:33.183368 IP 192.168.20.30.80 > 192.168.0.249.64848: tcp 145 21:17:33.186671 IP 192.168.0.249.64848 > 192.168.20.30.80: tcp 0 21:17:33.186779 IP 192.168.0.249.64848 > 192.168.20.30.80: tcp 0 21:17:33.186803 IP 192.168.0.249.64848 > 192.168.20.30.80: tcp 0 21:17:33.188655 IP 192.168.20.30.80 > 192.168.0.249.64848: tcp 0 21:17:33.276062 IP 192.168.0.249.64849 > 192.168.20.30.80: tcp 0 21:17:33.277657 IP 192.168.20.30.80 > 192.168.0.249.64849: tcp 0 21:17:33.280256 IP 192.168.0.249.64849 > 192.168.20.30.80: tcp 0 21:17:33.282917 IP 192.168.0.249.64849 > 192.168.20.30.80: tcp 417 21:17:33.284620 IP 192.168.20.30.80 > 192.168.0.249.64849: tcp 0 21:17:33.285526 IP 192.168.20.30.80 > 192.168.0.249.64849: tcp 49 21:17:33.287638 IP 192.168.0.249.64849 > 192.168.20.30.80: tcp 0 21:17:33.287836 IP 192.168.20.30.80 > 192.168.0.249.64849: tcp 1411 21:17:33.289557 IP 192.168.20.30.80 > 192.168.0.249.64849: tcp 1370 21:17:33.291626 IP 192.168.0.249.64849 > 192.168.20.30.80: tcp 0 21:17:33.292573 IP 192.168.0.249.64849 > 192.168.20.30.80: tcp 0 21:17:52.273755 IP 192.168.20.30.80 > 192.168.0.249.64849: tcp 0 21:18:27.179301 IP 192.168.0.249.64849 > 192.168.20.30.80: tcp 0 21:18:27.181234 IP 192.168.20.30.80 > 192.168.0.249.64849: tcp 0
I hit cancel eventually on the browser before letting it time out.
-
Looks like it should be working. Good two-way traffic there.
Next step would probably be to capture the same traffic on the 192.168.0 interface.
-
And now captured on the LAN interface:
22:13:16.239640 IP 192.168.0.249.65255 > 192.168.20.30.80: tcp 0 22:13:16.290553 IP 192.168.20.30.80 > 192.168.0.249.65255: tcp 0 22:13:16.293276 IP 192.168.0.249.65255 > 192.168.20.30.80: tcp 0 22:13:16.295753 IP 192.168.0.249.65255 > 192.168.20.30.80: tcp 408 22:13:16.297446 IP 192.168.20.30.80 > 192.168.0.249.65255: tcp 0 22:13:16.299002 IP 192.168.20.30.80 > 192.168.0.249.65255: tcp 23 22:13:16.299070 IP 192.168.20.30.80 > 192.168.0.249.65255: tcp 145 22:13:16.303231 IP 192.168.0.249.65255 > 192.168.20.30.80: tcp 0 22:13:16.303326 IP 192.168.0.249.65255 > 192.168.20.30.80: tcp 0 22:13:16.303374 IP 192.168.0.249.65255 > 192.168.20.30.80: tcp 0 22:13:16.305279 IP 192.168.20.30.80 > 192.168.0.249.65255: tcp 0 22:13:16.373411 IP 192.168.0.249.65256 > 192.168.20.30.80: tcp 0 22:13:16.375426 IP 192.168.20.30.80 > 192.168.0.249.65256: tcp 0 22:13:16.377846 IP 192.168.0.249.65256 > 192.168.20.30.80: tcp 0 22:13:16.380481 IP 192.168.0.249.65256 > 192.168.20.30.80: tcp 417 22:13:16.382150 IP 192.168.20.30.80 > 192.168.0.249.65256: tcp 0 22:13:16.383144 IP 192.168.20.30.80 > 192.168.0.249.65256: tcp 49 22:13:16.385477 IP 192.168.20.30.80 > 192.168.0.249.65256: tcp 1411 22:13:16.387004 IP 192.168.0.249.65256 > 192.168.20.30.80: tcp 0 22:13:16.389458 IP 192.168.0.249.65256 > 192.168.20.30.80: tcp 0 22:13:16.390411 IP 192.168.20.30.80 > 192.168.0.249.65256: tcp 1370 22:13:16.393147 IP 192.168.0.249.65256 > 192.168.20.30.80: tcp 0 22:13:35.372605 IP 192.168.20.30.80 > 192.168.0.249.65256: tcp 0 22:14:16.562504 IP 192.168.0.249.65256 > 192.168.20.30.80: tcp 0 22:14:16.564134 IP 192.168.20.30.80 > 192.168.0.249.65256: tcp 0
-
Looks like good two-way traffic there too. Not sure what to tell you. You'll probably have to download those into wireshark and see what's up with the TCP session. Might have to compare one that works with one that doesn't.
-
It's very strange. Perhaps as you say he printer won't allow an admin login if not on the same subnet..
Thanks for your help anyway! -
Looks like good two-way traffic there too. Not sure what to tell you. You'll probably have to download those into wireshark and see what's up with the TCP session. Might have to compare one that works with one that doesn't.
The mystery deepens. Today I'm out and connecting in via VPN. My IP is 10.8.0.2, gateway is 10.8.0.1.. And I'm able to access the printer status page by IP.. Avahi forwarding isn't working to this interface however so I can't access the printer by its .local domain…
Anywhere else I should be looking?

 -
Right.. I've figured it out. Basically I'm committing some sins which are causing unpredictable behaviour. I'm not too stressed about them now as I'll be moving away from this setup relatively soon and I have tested with a new, working setup.
For anyone else reading, my sins are:
- Mixing VLAN and untagged traffic on the same interface
- That interface is a VirtIO (which doesn't really work with VLANs I believe)
Once I tested a new build running under ESXi, with VMXNET3 drivers and all separate interfaces (so to pfSense), problems went away and behaviour was as expected.