Stomped in stopping inter-VLAN traffic
-
I've been using pfSense for quite a while for our small business network, and just added a VLAN to the network. It is going to carry guest-network traffic, so I want it to route to the Internet, but NOT to the regular LAN network that has our PCs and such. No matter what rules I try, I can't seem to stop it from routing between LAN and VLAN though.
The switches were by default routing between VLANs, I've already switched that off, so they are just layer 2 switches now.
The VLAN rules are attached, the VLAN has ID 5 and runs on 192.168.5.XXX.
For simplicity I've disabled most, just a few rules are in effect.
I've checked that packets are actually coming into this interface by enabling a blanket rule that blocks every packet originating from VLAN5, and that does indeed block everything.
With the rules as listed here I can access the pfSense GUI on 192.168.0.254, which should be blocked by the first three (enabled) rules. I can also access our Web server that's at 192.168.0.14, two of those rules should be blocking that.
At this point I'm stomped. I've read everything I can find on blocking and allowing inter-VLAN traffic, or the pfSense GUI, tried everything I could find, with no luck. Suggestions would be very welcome!
Thank you!
-Rob-
-
Did you try trace routing from a device on VALN5 to LAN? Make sure it's actually going through PFSense and not some other strange route.
-
Thanks Harvy!
I will do so first thing Monday when I get back at the office.However, I did add a test rule (you can still see it disabled in the list, just above the enabled rules) that blocks all traffic on VLAN5, and when that's active it blocks all inter-LAN traffic as well. That told me it IS in fact going through pfSense.
I will double-check on Monday though. In particular after seeing how unexpected things like bridges are doing routing too.
-RoB-
-
Been working on this some more this Sunday afternoon, and found what's causing it:
Doing a tracert showed no connection to anything on the LAN, so no information there.
After enabling that "block everything" rule, pulling up an internal Web site (which then gets blocked), and looking at the log I noticed lots of packets blocked coming from VLAN5 and destined for 127.0.0.1:3128. That's the Squid (package) transparent proxy port. Sure enough, unbinding Squid from VLAN5 made all the rules behave as they should. Re-bind VLAN5 to Squid and all the internal Web addresses are reachable, including the pfSense GUI.
I would have hoped that the firewall rules come before Squid gets its tentacles on the packets, but it seems the firewall rules come after Squid rewrites all those packets to local-loopback, 127.0.0.1.
That raises more, new, questions: I would dearly love to have Squid and SquidGuard with transparent proxy going for the VLAN as well as the LAN, but in doing so I can't see a way to write meaningful firewall rules for port 80 (and there are internal Web interfaces I don't want to expose on the guest network). Is there a way to make this work?
The corollary to this same issue concerns the LAN: With Squid and SquidGuard binding to the LAN, where we definitely do want transparent proxying, I can't keep the LAN port 80 packets from accessing the VLAN, and I would very much like to separate those two.
Anyone any ideas?
Thanks!-RoB-