You can create a feature request: https://docs.netgate.com/pfsense/en/latest/development/requesting-new-pfsense-features.html

If it needs to be stated, I don't have a collection of devices that won't work with the implementation of DHCP in pfsense, I have a problem that is stopping it from working, likely what I have done by restoring a backup from a non netgate appliance to a netgate appliance, but still a problem im facing.

However many leases are issued per second globally doesn't help me, I can't get the system to work

I have contacted netgate support and have been sent an image to flash onto the 3100 so that I can start again from scratch and not use my backup from the previous device

I will restore each setting from the previous pfsense appliance one by one and I will try to follow the order that you suggest

Good to know on the option code 1027, I haven't a clue what device is chirping about it but all devices worked on the previous appliance and whatever this device is has no problem not getting option 1027 so I will continue to ignore it

It's just a shame that there doesn't seem to be a way to resolve this issue without flashing the device, but again, it was likely inappropriate to try to restore a 3rd party devices config to a netgate appliance

Tried these solutions in order. The last one was the trick. HP OfficeConnect 1820G-24 switch.

Enabled Flow Control - Was off, but didn't help/hurt anything Disabled IGMP Snooping - Was on, same as above Updated firmware from 2.08 to 2.09, even though the changelog contained only a single line item, which was unrelated to the problem. This was the fix.

@Chrisnz said in Split DHCP ranges on Bridge?:

pfSense automatically routes between the subnets if the interfaces are part of the pfSense machine

That is not just pfsense, that is any router or any device at all to be honest... Why would you have tell a device how to talk to a network that its attached to.. The act of attaching it tells it how to talk to that network.. Just blows my mind how often this comes up..

If you have devices you want to filter, yes as jknott mentions it would be better to put them on their own vlan... This way you don't have to worry about assigning specific IPs just so you can filter them. From a security point of view, while I hand out IP address xyz to you, doesn't mean you could use IP address abc instead and now that firewall rule wouldn't block you. Or might not block you, etc. Depending exactly.. So its better to segment devices that will have the same restrictions or allowances to the same vlan. So you really don't have to worry about specifics like that.

But sure if you don't want IP 1.2.3.4 from going somewhere, just block it via a firewall rule.

What AP do you have, what switching - do you have the ability to do vlans on your network... That would be the more secure method of limiting something. Example I put all my iot devices on their own vlan.. This vlan can not talk to any other of my local networks. Except for stuff that I want to allow.. Its always best to block and make exceptions for allow, vs allow all and block specifics.

So from this other vlan would normally block everyone from talking to lan, and only allow specific IPs to talk to specific IPs on the lan, and only the services it needs on those specific IPs in the lan.

I ran the following:

sockstat -46 -P tcp,udp -p 53 -s USER COMMAND PID FD PROTO LOCAL ADDRESS FOREIGN ADDRESS STATE unbound unbound 58092 4 udp4 192.168.1.1:53 *:* unbound unbound 58092 5 tcp4 192.168.1.1:53 *:* LISTEN unbound unbound 58092 6 udp4 10.0.15.1:53 *:* unbound unbound 58092 7 tcp4 10.0.15.1:53 *:* LISTEN unbound unbound 58092 8 udp4 10.0.11.1:53 *:* unbound unbound 58092 9 tcp4 10.0.11.1:53 *:* LISTEN unbound unbound 58092 10 udp4 127.0.0.1:53 *:* unbound unbound 58092 11 tcp4 127.0.0.1:53 *:* LISTEN ? ? ? ? tcp4 <public-ip>:27315 199.249.119.1:53 TIME_WAIT ? ? ? ? tcp4 <public-ip>:3906 199.249.119.1:53 TIME_WAIT ? ? ? ? tcp4 <public-ip>:23285 96.7.49.66:53 TIME_WAIT ? ? ? ? tcp4 <public-ip>:52218 84.53.139.64:53 TIME_WAIT

Looks like it is unbound making the connections, but its not showing as that because they are closing.

All of the external IP's seem to be NS servers on the web.

Today, I had this problem again. I rebooted my modem and pfSense manually... Everything was shown in red. Also all vpn-clients where shown as disconnected... This time I decided to reboot pfSense again, hoping it would solve the problem but it didn't. I manually had to force and update every ddns-client and had to restart all the OVPN-clients.

This looks like a bug to me. A reboot should always check DDNS and stuff I think.

i
I found some posts that honestly, are too professioal for me to understand how - one how to still use someting more comprehensive and lose the leak, the other speicifcally on smart dns.
i can do guides like the nord but this and combining is a bit too much. if anyone is willing to peak and help incorporate this, id be more than grateful.

https://airvpn.org/forums/topic/27460-opinion-best-solution-against-dns-leak-on-pfsense/

https://www.reddit.com/r/PFSENSE/comments/8umvfw/dns_resolver_and_smart_dns/

Finally its working again without a DNS-server in "general config"!
I switched every setting in unbound, reconnected, looked at the state of dyndns and somewhere in that process it began working again. I have again all settings as before.
So i think a bit-swap occured somewhere.
Again a very big thanks to all for your great help, which finally stumped me to the right direction!!!!!

Case closed.

The allow/deny scenarios make sense, didn't occur to me in the first place - appreciate the explanation.
Took a few attempts but finally worked as desired. Thank you for the help, @jimp!

@chamilton_ccn
I know this is a somewhat old thread now, but I think I bumped into the same problem with my architecture which, although different from yours, displayed similar problems. It worked fine for a while and then the resolver would go to the root servers for the forwarded zones.

What worked for me was to mark the forwarded zones as local zones with the "transparent" zone type. So to emulate this you'd be adding something like the following lines to your custom options box:-

server: local-zone: "domain1.local" transparent local-zone: "domain2.local" transparent

Since the zones are local, my (limited) understanding is that they get processed before other zone types. In the transparent case, since you have no local entries in the zones anyway, resolution proceeds as it normally should.

I'm on pfSense 2.4.5-p1, unbound 1.10.1.

I do not believe these entries should be at all necessary, but it works for me. I hope that's useful.

@johnpoz since it started working, after that I just added the static mapping back in and everything seems ok.

Is it possible that maybe it just took a while for the lease to show up in the list?

Maybe just a glitch in the matrix?

I HATE when I don't know why something happened… But I guess I'm gonna have to let that one go. There's too much I need to learn as it is.

Thanks for your help!

@detox said in Loosing internet connection daily:

Almost every day we 'lose' internet
meaning I cannot connect to any FQDN but can ping and to to any site by the IP address.

This sounds like a DNS thing. What are your DNS settings? Are you using DNS Resolver, DNS Forwarder, DNS Resolver in forwarding mode? If so, what DNS servers do you have under System > General Setup page.

For some reason I'm unable to edit my previous post so I just continue here.

For some reason it currently seems that I can now do successful name resolutions from only one device (Ubuntu 18.04) in my LAN behind my two firewalls (pfSense and IPFire). All the name resolutions are now failing from IPFire itself or from any other device in my LAN. This particular Ubuntu device has a static IP settings, but so has many other devices in my LAN also. I find this strange, because I haven't made any changes to DNS settings. IPFire itself is still unable to resolve any names, but seems to successfully forward name resolutions to this particular one Ubuntu device behind it. I haven't figured out why this particular Linux device succeeds when the rest of the devices fail (I have bunch of Windows, Linux and BSD machines in my network).

Oh well, this issue has turned more complicated than I expected and maybe it's now time to give up and find other ways to implement these two firewalls (e.g changing their order). I would still like to thank you for your help @bmeeks.

@Gertjan Wow thats an awesome write up thanks for all of it. I decided to just completly remove the FIOS router and everything is working great now. I would have done it @work but I don't have a job, thanks covid.. lol

Hi @Gertjan , it's been a couple of days and in my logs I can see that "rc.newwanip" has been kicked off a couple of times, but I haven't had the "bind: address already in use" error and hence my automatic restart script has not needed to kick in. This looks likely due to the change of my Dyson fan to a static lease.

Thanks a lot for the suggestion for checking the DHCP log, I believe that has got to the bottom of this issue.

I'm considering this one solved! Thanks everyone for your help and suggestions.

Ah, I didn't realize it was architected that way already, in pfsense. Thanks for filling me in.

This works great, thanks :)