Netgate Discussion Forum
    • Categories
    • Recent
    • Tags
    • Popular
    • Users
    • Search
    • Register
    • Login

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

    Scheduled Pinned Locked Moved General pfSense Questions
    11 Posts 2 Posters 2.8k Views
    Loading More Posts
    • Oldest to Newest
    • Newest to Oldest
    • Most Votes
    Reply
    • Reply as topic
    Log in to reply
    This topic has been deleted. Only users with topic management privileges can see it.
    • V Offline
      Visseroth
      last edited by

      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

      1 Reply Last reply Reply Quote 0
      • P Offline
        phil.davis
        last edited by

        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.

        As the Greek philosopher Isosceles used to say, "There are 3 sides to every triangle."
        If I helped you, then help someone else - buy someone a gift from the INF catalog http://secure.inf.org/gifts/usd/

        1 Reply Last reply Reply Quote 0
        • V Offline
          Visseroth
          last edited by

          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

          1 Reply Last reply Reply Quote 0
          • P Offline
            phil.davis
            last edited by

            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.

            As the Greek philosopher Isosceles used to say, "There are 3 sides to every triangle."
            If I helped you, then help someone else - buy someone a gift from the INF catalog http://secure.inf.org/gifts/usd/

            1 Reply Last reply Reply Quote 0
            • V Offline
              Visseroth
              last edited by

              Here ya go…

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

              1 Reply Last reply Reply Quote 0
              • P Offline
                phil.davis
                last edited by

                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.

                As the Greek philosopher Isosceles used to say, "There are 3 sides to every triangle."
                If I helped you, then help someone else - buy someone a gift from the INF catalog http://secure.inf.org/gifts/usd/

                1 Reply Last reply Reply Quote 0
                • V Offline
                  Visseroth
                  last edited by

                  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.

                  1 Reply Last reply Reply Quote 0
                  • P Offline
                    phil.davis
                    last edited by

                    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.

                    As the Greek philosopher Isosceles used to say, "There are 3 sides to every triangle."
                    If I helped you, then help someone else - buy someone a gift from the INF catalog http://secure.inf.org/gifts/usd/

                    1 Reply Last reply Reply Quote 0
                    • V Offline
                      Visseroth
                      last edited by

                      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

                      1 Reply Last reply Reply Quote 0
                      • V Offline
                        Visseroth
                        last edited by

                        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)

                        1 Reply Last reply Reply Quote 0
                        • V Offline
                          Visseroth
                          last edited by

                          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

                          1 Reply Last reply Reply Quote 0
                          • First post
                            Last post
                          Copyright 2025 Rubicon Communications LLC (Netgate). All rights reserved.