<![CDATA[Providing a "single host" subnet mask via DHCP to isolate clients]]>Background: I've a guest wifi network provided via Captive Portal over several WAPs, with the guest subnet being a class C. I'd like to isolate users connected to the wifi from each other (because it's feasible that a user could be simultaneously connected to our wired LAN and thereby form part of a "man-in-the-middle" attack, and besides I ought to try to protect guests where possible).

Problem: enabling client isolation within the WAPs only isolates clients connected to that particular WAP - clients on different WAPs can see each other, because they're all part of the same subnet, and I can't use pFsense to firewall the traffic as the traffic doesn't go through the firewall. I had thought that the only solution was to replace all of my WAPs with very expensive ones that feature blacklisting and/or packet forwarding.

However, I seem to have stumbled upon an easy solution, and initial testing (a couple of XP hosts) shows that it works, but I'm concerned that what I'm doing breaks the rules and that some operating systems may not handle it well. I'd tried to research the concept (ie Google!) but I'm still not sure, and I can't test everything that might end up using the system.

What I'm doing is to override the class C subnet mask provided by default by DHCP, with a mask of all ones. It's easily done in the pFsense DHCP server - just go to additional options and specify option 1, IP address or host, 255.255.255.255. This forces all traffic through pFsense, where I can firewall off any access to the rest of the calls C subnet.

So ipconfig on the host is -

         Dhcp Enabled. . . . . . . . . . . : Yes
         Autoconfiguration Enabled . . . . : Yes
         IP Address. . . . . . . . . . . . : 172.28.25.23
         Subnet Mask . . . . . . . . . . . : 255.255.255.255
         Default Gateway . . . . . . . . . : 172.28.25.1
         DHCP Server . . . . . . . . . . . : 172.28.25.1
         DNS Servers . . . . . . . . . . . : 172.28.25.1

and routing on the host is -

Network Destination        Netmask          Gateway       Interface    Metric
           0.0.0.0          0.0.0.0      172.28.25.1    172.28.25.23	  10
         127.0.0.0        255.0.0.0        127.0.0.1       127.0.0.1	  1
      172.28.25.23  255.255.255.255        127.0.0.1       127.0.0.1	  10
    172.28.255.255  255.255.255.255     172.28.25.23    172.28.25.23	  10
         224.0.0.0        240.0.0.0     172.28.25.23    172.28.25.23	  10
   255.255.255.255  255.255.255.255     172.28.25.23    172.28.25.23	  1
Default Gateway:       172.28.25.1

So, can anyone here see anything wrong with this method? If this is valid then it might be a very useful tip to others out there who are using pFsense for guest networks.

]]>https://forum.netgate.com/topic/56714/providing-a-single-host-subnet-mask-via-dhcp-to-isolate-clientsRSS for NodeSun, 11 Oct 2026 21:37:25 GMTSun, 26 May 2013 06:46:27 GMT60<![CDATA[Reply to Providing a "single host" subnet mask via DHCP to isolate clients on Wed, 26 Jun 2013 06:49:45 GMT]]>Apologies wallabybob - I've just realised I never got back to this thread. You were absolutely right - I got as far as testing against FreeBSD and a few mobile phones, and none of them worked. As this has to work with potentially any device I've had to abandon this idea. Damn.

@wallabybob:

Though this apparently works with Windows clients I think it won't work with FreeBSD clients and might not with MAC OS, Linux or Android (the client is not in the same subnet as the default gateway).

]]>https://forum.netgate.com/post/402588https://forum.netgate.com/post/402588Wed, 26 Jun 2013 06:49:45 GMT<![CDATA[Reply to Providing a "single host" subnet mask via DHCP to isolate clients on Sun, 26 May 2013 20:14:31 GMT]]>Though this apparently works with Windows clients I think it won't work with FreeBSD clients and might not with MAC OS, Linux or Android (the client is not in the same subnet as the default gateway).

]]>https://forum.netgate.com/post/397400https://forum.netgate.com/post/397400Sun, 26 May 2013 20:14:31 GMT