VLAN is still passing traffic to local lan? (Solved)



  • OK, so the setup is as follows…

    2 WANs
    2 LANs
    1 VLAN

    Switch:
    Port 47: PfSense (PVID 1, VLAN 2 Tagged)
    Port 39: AP (PVID 1, VLAN 2 Tagged)

    The VLAN is for the wireless and for users to still use the internet but they are NOT to have access to the local network for obvious security reasons
    The wireless device is a Ubiquiti AP
    It is managed via a server on the local LAN

    On the switch I added the port to PfSense to the VLAN by selecting "Tagged" so that the tagged traffic can go down that port. I did the same thing to the port with the access-point.

    In the rules for the VLAN interface I added a block rule to block traffic to the LAN and in the LAN interface I put a rule to block traffic to the VLAN.

    Now when I try and ping any of the machines on the LAN from the VLAN I get a reply. When I check the firewall logs it shows traffic being blocked.

    My question is why? Did I not tag the ports correctly? Why would the VLAN traffic still be able to access the LAN? I can only assume the switch is passing the traffic

    Unfortunately I can't remove the AP from the LAN. I still need to be able to talk to it on the LAN so the server can manage it. I just want the traffic for that SSID to only have internet access. The SSID is set for VLAN 2 and any device on that VLAN is getting the appropriate IP assigned by DHCP from PfSense for that VLAN.

    Everything on VLAN 1 is all untagged



  • The SSID is set for VLAN 2 and any device on that VLAN is getting the appropriate IP assigned by DHCP from PfSense for that VLAN.

    That is good - it indicates that the devices are actually sitting on VLAN2.
    Check the order of the rules - on VLAN2 interface the block rule for destination LANnet needs to be first (before the general pass rule for the internet). It also needs to be for all protocols (you might have accidentally made it just for TCP - so ping gets through). If its not one of those common errors, then post the rules you have and we can look.



  • The block rules are set first.
    IPv4 * source VLAN 2 net, port * destination LAN net port * gateway *

    All IPv6 traffic is blocked and also comes before the pass rule

    Pass rule is

    IPv4 * source * port * destination * port * gateway BalanceGW

    I just tried to ping from the LAN to the VLAN GW and it was blocked as it should be



  • What you have written should work to block from VLAN2 to LAN. So post screen shots of the rule list on VLAN2 and the individual block rule. There might be some setting accidentally different from what you typed.



  • Here ya go…



    ![Wireless VLAN2.JPG](/public/imported_attachments/1/Wireless VLAN2.JPG)
    ![Wireless VLAN2.JPG_thumb](/public/imported_attachments/1/Wireless VLAN2.JPG_thumb)



  • Those rules look like they should block from xxxWIRELESS to LAN (and the reverse). And you already siad that you are seeing the blocks in the firewall logs - so that means the traffic is going to the pfSense xxxWIRELESS VLAN interface.

    Maybe try traceroute - it might show how somehow the traffic is getting redirected to something in the Ubiquiti that is routing between VLAN and LAN, or …??? That should not be the case, because the blocks on pfSsense firewall log confirm that the traffic is coming to pfSense, and pfSense should not be magically sending an ICMP redirect to some other router.

    Then you will need to packet capture at each point along the way, remove cables where possible to test where packets go and don't go.



  • OK, later this week I'll be pulling the firewall and replacing it with a new one and I'll do some network sniffing to see what the heck is going on. I thought maybe it had something to do with the vlan tagging.



  • For the benefit of others, it will be good to know what turns out to be the cause, because traffic should not just "jump" between a VLAN and ordinary untagged network for no good reason.



  • I completely agree. I try and make it a point to always post the end result and/or fix. Not just for my benefit but the benefit of others



  • OK, this is just a update to the replacement firewall.
    I manually setup the new firewall. Meaning I copied all the configurations over by hand, pulled the old firewall out, put the new one in place, did some testing and tuning and it is working GREAT!!!

    Attached are the rules on the VLAN. Before I had similar rules but it was causing ALL traffic on the interface to be blocked so I removed the rules and put a rule on the LAN interface (for example) to block traffic on the LAN from the VLAN interface. This however did not block traffic to the apposing GW address which meant if one scanned the network they could still find the LAN GW and attack the web gui or SSH if the network was compromised.

    With the current rule set there is NO crossing of traffic, no web gui or SSH access on either the phone network or the wireless network where gui and ssh access are currently NOT needed.

    A attempt to scan the LAN from the VLAN (Wireless) did nothing but trigger a lot of blocks in the firewall. No other devices were found (PERFECT!)

    I also incorporated a NTP (port 123) forced redirect as the phone provider had the phones syncing to a Asian address.
    My thought was, "How stupid is that? Yea, let's go over seas, get our time and bring it back?!?!" I don't think so! So since I don't have the login information to the phones I forced a redirect to the firewall, checked the logs and sure enough! Time Sync! OH YEA!
    This should also be handy for any other device on the network not properly configured to sync locally  ;D
    (Credit for the NTP redirect goes to Wheelz for finding the blog. https://forum.pfsense.org/index.php?topic=59505.0 )

    So, in short the installation of the new firewall went VERY well. I'm still tuning snort but it is running well and the CPU doesn't seem to be so much as breaking a sweat.

    The old firewall has yet to hit the bench so as soon as I know more I'll post the results. I plan on doing some stress testing, ect. I may need some assistance in figuring out some of the back end stuff if it comes to that. One of the pictures I took indicated a corrupt config file. This could be caused by dirty power, failing MB, RAM, all sorts of things or maybe it had been broken into, no matter I would like to figure out what happened so as to see it not happen again or at least know why it happened again.

    Further updates to come!

    ![VLAN Config.JPG_thumb](/public/imported_attachments/1/VLAN Config.JPG_thumb)
    ![VLAN Config.JPG](/public/imported_attachments/1/VLAN Config.JPG)



  • Well. Put the old machine on the bench and figured out why it was being so screwy, including allowing traffic to pass vlans. Memory corruption!
    See this post… I posted a screenshot of the memtest.
    https://forum.pfsense.org/index.php?topic=104740.15


Log in to reply