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

    Mac Blacklist without Captive Portal?

    DHCP and DNS
    3
    6
    1.1k
    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.
    • Z
      Zachzaf
      last edited by

      We have a handful of boxes throughout our locations set up with a dual WAN single lan. The actual LAN is a wireless public network for our clients, the wan 1 is the actual wan and the wan2 is a mgm interface on our network for monitoring and administration.

      The LAN is set up with DHCP, and an AP connected that dishes wireless signal. The problem we have is the network is provided for parents whose children are in lessons and want to browse the web mail or whatever, their prerogative. The problem that we end up with is often our locations are near residential areas so we get a bunch of people connecting on free wifi, hooking up pcs and torrenting junk, or hooking up their wii's and sucking down bandwidth.

      Black listing by creating a captive portal and an allow list is ineffective as we have no real idea of who the people using the networks will be throughout the week month year so on. But we always know who the APT are on the network because we monitor the traffic.

      The DHCP Deny list is by prefix only, so we can block all dells, or all of nintendo. But not practical.

      Are there any resources that we can leverage aside form assigning the APT a static and giving null stats to it? (Static IP change is pretty simple. as is a mac spoof but the guy downloading the big boobed blondes torrents isn't going to be as persistent as we are)

      1 Reply Last reply Reply Quote 0
      • DerelictD
        Derelict LAYER 8 Netgate
        last edited by

        Why not just put a WPA passphrase on the network and make that available to those who need to know.

        Or make some 3-month vouchers and hand those out when people need them and run a captive portal.

        Whack-a-mole MAC addresses doesn't sound like fun for anyone.

        Chattanooga, Tennessee, USA
        A comprehensive network diagram is worth 10,000 words and 15 conference calls.
        DO NOT set a source address/port in a port forward or firewall rule unless you KNOW you need it!
        Do Not Chat For Help! NO_WAN_EGRESS(TM)

        1 Reply Last reply Reply Quote 0
        • Z
          Zachzaf
          last edited by

          We have tried the WPA2 pass-phrase and inevitably those interested will wander into he store to get it.

          I dont mind the 3 month voucher, but then again we are having to plug in devices, And having the general public know what their phones name or mac is… Not going to happen, or giving the general public credentials to log into aCP is redundant as well. We are also talking lessons that range from 2 weeks to 15 years.

          It seems more efficient to smack the one or two offenders down enough to deter them, than it is to have to set up a CP dole out certs and or pamphlets notifying people of the changes. We are talking hundreds and hundreds of people on public wifi versus maybe 5 people abusing it in three locations.

          1 Reply Last reply Reply Quote 0
          • DerelictD
            Derelict LAYER 8 Netgate
            last edited by

            Unfortunately blocking by MAC address is a layer 3 function.  If you can't do it in your AP, then I don't think pfSense will do that.

            Anyone determined enough to wander in to get your WPA passphrase is going to know that the reason they can't connect to your Open Wi-Fi is because of a MAC filter and just change it.

            You don't understand how vouchers work.  You give them the voucher and the CP automatically adds the MAC address to the table.

            Again, though, anyone determined enough to wander in to get your WPA passphrase is just going to sniff your traffic to obtain MAC addresses that have been passed through and use one of them.

            Chattanooga, Tennessee, USA
            A comprehensive network diagram is worth 10,000 words and 15 conference calls.
            DO NOT set a source address/port in a port forward or firewall rule unless you KNOW you need it!
            Do Not Chat For Help! NO_WAN_EGRESS(TM)

            1 Reply Last reply Reply Quote 0
            • Z
              Zachzaf
              last edited by

              As far as the filtering goes, that's what I had figured.

              However Vouchers is one way of controlling CP, YOu can also allow an explicit allow list ACL. which would manually be punched. So its not that I am ignorant to how vouchers and CPs integrate, I was covering two bases.

              I would also disagree that some one wanting to walk 30 feet would also be the same person to sniff traffic, or spoof a mac. Is it possible. of course, and I am sure there are a hundred million resources to show you how, but the dud spanking it and laying Wii in our backward is probably not that cat. If he were, he would have bypassed the static IP entry at this point.

              Thanks for your time!

              1 Reply Last reply Reply Quote 0
              • N
                NOYB
                last edited by

                If you insist on operating an unsecure WiFi then well it's going to be unsecure.

                If you could develop a usage profile of the offenders and identify attributes that could be targeted without affecting your legitimate users maybe you could deter the offered enough that they lose interest.  Maybe bandwidth/throughput restriction perhaps.

                Another part of the usage profile might be to block sites that are unique to the offenders.  Some up front work but eventually their access becomes too limited for their purpose.

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