Devices connected via AP given unique IP address range?
-
My LAN is on 192.168.10.0/24, and I have it set to distribute IP addresses between 192.168.10.100-199. I have my UniFi AP set to a static IP on the subnet of 192.168.10.10, and I want to configure my pfSense/UniFi so that all devices connecting wirelessly via AP are given addresses in the 192.168.10.200-254 range. Which is to say, I want wired devices on the LAN to get addresses from 192.168.10.100-199, and wireless devices connected via AP to get addresses from 192.168.10.200-254. How would I go about configuring this?
Thanks!
-
You don't. It doesn't work that way. Break the wifi out into its own subnet via another NIC or a VLAN.
-
As KOM mentioned, there's no effective way to configure that as requested. True AP's just dump the traffic on the wire and you can't have multiple DHCP servers in the same broadcast domain.
Accomplishing your goals would require either a 2nd NIC or implementing a managed switch.
The only completely crude, inefficient and bass-ackwards way of doing what you're asking without changing your design would be manually configuring DHCP static mappings for each and every wireless client.
-
I actually do have two NICs installed on my pfSense machine. Technically, three. It's a Supermicro motherboard with a built-in 2-port NIC that's going unused (and I'd like to leave it unused), and then I have two Intel Pro 1000 quad-port cards. So if this is my avenue towards accomplishing my goal, I'd love more details.
-
Three NICs: WAN, LAN, OPT1. Put your LAN on LAN. Put your Unifi AP on OPT1. Services - DHCP Server allows you to create a server instance on both LAN and OPT1 and configure each accordingly.
-
^^^ Exactly. Simply plug your AP into one of your OPT(X) ports, configure the OPT(X) port with an IP in any reserved range outside of your LAN, create a new DHCP scope, add firewall rules on the OPT(X) interface and you're done. Now all wireless clients will grab an IP from the new scope configured on OPT(X).
-
When configuring the interface I'll be putting the AP on, what kind of IPv4 configuration type would I be selecting?
-
Whatever you want it to be. If your existing LAN is 192.168.10.1/24 then try 192.168.20.1/24 for OPT1 network.
Edit: Yes, static IP as marvosa said. I thought you were asking about the topology.
-
The type would be "Static IPv4".
-
So if I have my AP on 192.168.20.1, how do I get it to assign 192.168.10.200-254 IPs?
-
You can't give it that DHCP range.
The 192.168.10.X subnet is for your LAN segment. You can't make another segment/network on the same firewall with the same scope. You should use 192.168.10.X for LAN, and then use 192.168.20.X for your wifi on your OPT network/interface.
Jeff
-
@marvosa said in Devices connected via AP given unique IP address range?:
Accomplishing your goals would require either a 2nd NIC
Well, that was my original question. And then marvosa said that it could be done with a second NIC, which I have, so I was trying to get more detail about that.
-
So if I have my AP on 192.168.20.1, how do I get it to assign 192.168.10.200-254 IPs?
So, if you're AP is set to 192.168.20.1, then you will need to assign the OPT interface something else in that range. Personally, I would assign 192.168.20.1 to your OPT interface and then give your AP something random, but easy to remember like 192.168.20.10.
Next, enable the DHCP server on the OPT interface and configure the scope.
-
Okay, so let's say I make an OPT interface at 192.168.20.1, and I put my AP on 192.168.20.100. How do I get pfSense to assign addresses on the OPT interface in the 192.168.10.1 range without giving me an error the range is outside of the subnet?
-
@dstarr3 He meant you can have the two different clients getting IPs from different DHCP servers. He didn't mean they would use the same scope because that's impossible. I suspect there are some networking basics that you are not aware of that are causing confusion.
What is the actual problem you are trying to solve? WHy does it matter if LAN and OPT1 DHCP clients are in the same scope but different ranges?
-
@dstarr3 said in Devices connected via AP given unique IP address range?:
Okay, so let's say I make an OPT interface at 192.168.20.1, and I put my AP on 192.168.20.100. How do I get pfSense to assign addresses on the OPT interface in the 192.168.10.1 range without giving me an error the range is outside of the subnet?
Configuring two different interfaces with IP's in the same subnet cannot be done. Which is why I mentioned there was no way to do what you're asking as originally requested. However, the overall, high-level goal is to have your wireless clients grab addresses from a specific DHCP range, which is what you will accomplish by connecting your AP to your OPT interface, but that specific range HAS to be on a different network than your LAN.
-
The problem I'm hoping to solve is that my cell phones can't automatically discover devices that are on a different subnet. For instance, my NAS or my PC. With LAN and WIFI on different subnets, I have to manually enter IP addresses into Android apps to get them to work across subnets. Even with interface rules being wide open and no Windows/etc firewall in between. So I was hoping there was a way to get LAN and WIFI on the same subnet, yet keep the IP addresses distinct by using pools of 100-199 and 200-254. But that being impossible, the real end goal is to configure my network so that my phone can automatically discover the wired devices on the different subnet.
But it occurs to me now that that might be a limitation of Android, not of my pfSense configuration.
-
The problem I'm hoping to solve is that my cell phones can't automatically discover devices that are on a different subnet. For instance, my NAS or my PC. With LAN and WIFI on different subnets, I have to manually enter IP addresses into Android apps to get them to work across subnets. Even with interface rules being wide open and no Windows/etc firewall in between. So I was hoping there was a way to get LAN and WIFI on the same subnet, yet keep the IP addresses distinct by using pools of 100-199 and 200-254. But that being impossible, the real end goal is to configure my network so that my phone can automatically discover the wired devices on the different subnet.
But it occurs to me now that that might be a limitation of Android, not of my pfSense configuration.
It depends on what the application is using for discovery. If the application is using broadcasts for discovery, then the issue you're having is happening by design and is due to a network standard, not an Android limitation or firewall rules.
In order for a device to access a different network, it has to pass through a router and routers drop all broadcast traffic by default.
So I was hoping there was a way to get LAN and WIFI on the same subnet, yet keep the IP addresses distinct by using pools of 100-199 and 200-254.
Unfortunately, there's no simple way to satisfy that request as written with standard gear due to multiple protocol standards. You can absolutely have your WiFi on the same subnet as your LAN and configure two different DHCP scopes, but the 2nd scope will just sit there unused until the first scope fills up. There's no way to force your WiFi clients to grab IP's from the 2nd scope in that scenario.
But that being impossible, the real end goal is to configure my network so that my phone can automatically discover the wired devices on the different subnet.>
If the application uses broadcasts for discovery, there's no way for a device to automatically discover other devices across subnets due to broadcast traffic being dropped by the router. So, you either have to enter IP's manually or hope that the application developer included a way to specify networks to include during discovery.
Your only other recourse would be DHCP reservations or configuring your wireless clients statically. Both of which would be a management nightmare.
If the main priority is keeping the functionality of apps that leverage broadcasts for discovery, then you may end up having to live with all clients mixed in on the same subnet and DHCP scope. It can make auditing and tracking things down a little more difficult, but it's not completely horrible.
Having said all of that, are there some things that can be implemented that may work in theory that involve a more advanced design and adding enterprise gear? Sure, but my guess is that spending a bunch of money on enterprise gear and added infrastructure is probably out of scope for this thread.
