IP Range and subnet
-
I have PFSense setup to provide some wifi access to customers.
I use the LAN address 192.168.10.1/21
This gives me a range of 192.168.8.1-192.168.15.254
I have the DHCP server setup to use 192.168.11.1-192.168.15.254
I then have the captive portal setup to allow ip pass through for 192.168.8.1/24, the idea being that I can manually put staff and IT kit that needs unrestricted access into this ip range via the DHCP MAC binding (prefer not to pass the MAC through the captive portal as locking the IP makes it easier to log usage in squid).
Question?
I have one piece of kit which does not cope with DHCP very well, it seems to get the IP address, gateway and DNS servers, but just refuses to connect to the internet. (an internet TV). When setting up the IP address manually on this, IP 192.168.8.23, GATEWAY/DNS 192.168.10.1, what should the sub net mask be? 255.255.248.0?
I am more used to your normal range/subnet!
Thanks!
-
Should be the network's real subnet mask, /21, 255.255.248.0.
-
Thanks, that's what I thought.
Out of interest, if the subnet mask was 255.255.255.0, this would just be the 192.168.8.1-182.168.8.254 range? So it could communicate with anything on the 192.168.8.x range, but nothing else? Would it still get out to the net?
The DHCP settings it shows when it uses DHCP are IP: 192.168.8.23, GATEWAY/DNS 182.168.10.1, subnet 255.255.255.0.
I think it assumes the subnet itself? Would this prevent it accessing through the captive portal to the net?
Thanks.
-
The DHCP settings it shows when it uses DHCP are IP: 192.168.8.23, GATEWAY/DNS 182.168.10.1, subnet 255.255.255.0.
The gateway is not on its subnet! How will it reach the gateway?
Do other DHCP clients get the correct network mask?
-
That's what I mean. All other clients get the correct subnet, but the tv always gets 255.255.255.0.
I will set it manually to 255.255.255.248 and see what happens.
If I packet capture, I see 192.168.8.23 requesting DHCP and pfsense ACKnowleging it, but that's it, time and time again. Just two repeating log lines.
-
That's what I mean. All other clients get the correct subnet, but the tv always gets 255.255.255.0.
Can you lodge a problem report? Maybe there is a firmware upgrade (to the TV) to fix this.
If I packet capture, I see 192.168.8.23 requesting DHCP and pfsense ACKnowleging it, but that's it, time and time again. Just two repeating log lines.
Whats the interval? If its very short perhaps its a sign the the TV doen't like the lease and is trying to get something more to its liking.
-
Try specifying your subnet as 192.168.8.1 /21 instead of 192.168.10.1 /21 and use 192.168.8.1 as the LAN address for pfSense. It probably shouldn't matter but you never know.
The DHCP range should be able to stay at 192.168.11.1 to 192.168.15.254 but it might be cleaner to split the /21 subnet in half and just give the top end (192.168.12.1 to 192.168.15.254 or 192.168.12.1 /22) to DHCP. I'm guessing you don't really need to accommodate more than a thousand hosts up there ;)
-
If I packet capture, I see 192.168.8.23 requesting DHCP and pfsense ACKnowleging it, but that's it, time and time again. Just two repeating log lines.
Whats the interval? If its very short perhaps its a sign the the TV doen't like the lease and is trying to get something more to its liking.
It looks like roughly every 1hr 40mins.
DHCP Request from 192.168.8.23 -> 255.255.255.255
DHCP ACK from 192.168.10.1 -> 192.168.8.23This repeats every 1hr 40mins ish.
-
It does look like it is the TV that has issues - Putting it in the same .8 subnet with pfsense sorted the issue and it works as it should.
The TV could not cope with the gateway/dns being in a different subnet to it's IP address. Buggy TV.
I have swapped pfsense to 192.168.8.1, and use the 192.168.8.x subnet for items that want Captive Portal passthrough.
I then use the DHCP range 192.168.11.1 - 192.168.15.254 for the DHCP for captive portal clients. As it is serving free WiFi to a huge pub, and the lease time is set at 3 days, the DHCP status overview can grow quite large, especially at bank holidays etc.
One thing I have not tried, is to see if someone sets a static .8 IP, if they then get unresticted captive portal access…
-
… a huge pub, and the lease time is set at 3 days ...
Must be some pub :D
Glad you got it sorted out.
-
The TV could not cope with the gateway/dns being in a different subnet to it's IP address. Buggy TV.
The gateway being outside its subnet isn't valid, not a buggy TV, you were giving it an invalid network config. It'd probably work fine with a different subnet for a DNS server if it had a valid gateway.
You should really split up that network. Put the public network with captive portal on a VLAN or switch completely separate from the internal network. Especially if that internal network has the pub's point of sale system, otherwise you're just begging someone to own it and steal credit cards (it's not uncommon).
-
The pub as a completely seperate corporate network for the POS tills and server, and the offices. No connection at all to the WiFi system, this has it's own DUAL WAN ADSL load sharing router in front of the Pfsense box.
The only reason the TV is on the WiFi portal is because of it's location. It was not practical to cable it individually to the other network, or the other side of the Pfsense box.
I had read in a post here about using a 255.255.252 subnet to allow a larger DHCP pool, using the single gateway IP - As far as I can see looking at the sarg logs, none of the circa 100-200 clients per day have issues accessing the web? What is the best way to have a large DHCP pool then? Or should I just look to have the one smaller pool?
-
Going to a larger network is the easy way, I went with a base address of 172.16.0.1 for my pfSense LAN and a net mask of /22 so I had plenty of addresses available and I could assign IPs in groups that made sense. I put the DHCP dynamic assignments at 172.16.3.1 with 250 some addresses available it works for now. If I need more space giving DHCP a larger space is no problem, expansion is as easy as changing the /22 mask to something between /21 and /12 and then adding the newly available addresses to the DHCP dynamic range.
Just make sure the base address you pick has enough room above it to meet any future expansion needs, the old class A or B RFC 1918 base addresses work well for that.
10.0.0.0 - 10/8 prefix
172.16.0.0 - 172.16/12 prefixI avoided the whole 198.x.x.x range after I got tired of devices getting a hard reset defaulting to that range or having hard coded addresses in that range and causing conflicts.
