My name is Jefferson, from southern Brazil. I’ve been following Tom’s work for many years, and I manage several pfSense deployments in my region. This community has always been a solid source of insights, so I’m hoping to tap into your expertise once again.
Has anyone implemented an effective strategy to block users from connecting their own consumer-grade routers to the network? The environment already has 802.1X enabled, but only on Wi-Fi; the wired network does not use 802.1X yet. Because of this, some users plug in personal routers and create small “NAT islands,” which quickly snowballs into operational issues.
I’m specifically looking for a mitigation that can be applied only on pfSense, without relying on switch or AP features. Has anyone used TTL-based techniques, detection of multiple hosts behind a single MAC, or any other pfSense-only approach that could help identify and block this kind of behavior?
Thanks in advance for any guidance or real-world experience you can share.
Short Answer: pfSense cannot reliably prevent consumer router “NAT islands” by itself. PfSense sits at Layer 3, and the problem you’re trying to solve is primarily Layer 2 access control. Without switch-level enforcement (802.1X, MAC auth, port security, etc.) you have no authoritative way to stop a user from plugging in a private router.
What if he implements static DHCP mappings for known clients and create a firewall rule with alias that has only IP addresses in the DHCP static table? This should, in theory, prevent random devices getting an IP address from pfSense. Also, setting a “Deny Unknown Clients” option under DHCP server to “Allow known clients from only this interface” should help. Along with ticking off the option “Ignore Client Identifiers”. This should prevent devices with spoofed MAC addresses from connecting because DHCP Server will check for UID as well.
yeah, but depending on the network size (and user relationship with IT dept) this is quite probably impossible to manage. You can’t possibly register every device connecting to the network unless they are in the low hunderds or very stable and no computers, laptops, printers are added or replaced frequently.
I know I couldn’t do it in my network and I only service a 4 story building.
Look into running FreeRADIUS on pfSense that will take you some of the way there. However, what you are asking for is actually running PKI (public key infrastructure) to ensure only authenticated devices can connect to the network. You then need to support this !
Thank you all for the responses and perspectives. They are technically solid and absolutely make sense in more controlled environments.
In my specific case, however, the constraints are mostly operational rather than purely technical. I provide internet as a service to multiple independent companies that rent offices across four floors in two separate buildings. Users already authenticate via 802.1X on Wi-Fi, but intentionally without certificates, to avoid increasing support complexity on endpoints I do not manage directly.
Because of this model, approaches like static DHCP mappings, “deny unknown clients”, full MAC registration, or PKI-based authentication quickly become unmanageable at scale. Devices change frequently, users are non-technical, and my goal is to avoid introducing any solution that could cause access friction on either Wi-Fi or wired connections.
My interest in TTL-based techniques comes from RouterOS, where it is possible to manipulate TTL in the firewall mangle rules so that packets effectively expire at the client, preventing downstream NAT or routing without breaking basic connectivity. From what I can see, pfSense does not currently offer an equivalent, clean way to do this.
I fully understand that this is fundamentally a Layer 2 problem and that switch-level enforcement is the “correct” solution. I was mainly exploring whether there is any practical Layer 3 mitigation on pfSense that could reduce the impact of rogue routers without increasing user-facing complexity.
Thanks again to everyone for sharing their experience, and to @LTS_Tom for keeping this forum and community such a valuable resource.