Devices connected via AP given unique IP address range?
-
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.
