@areckethennu It's possible I "fixed" this simply by rebooting my SB8200 cable modem (I realized it was the only thing I'd not rebooted after updating to pfSense 21.05 and I'm pretty sure it has its own DHCP server (over which I have no control)). I was getting multiple "discarding..." log entries per hour until I did so. In the 4 hours since then, I've gotten none. We'll see.
The solution I've found to fix this is to do the following:
Interfaces > Your Starlink Int. > Tick Advanced Configuration under DHCP Client Configuration > Reject leases from 192.168.100.1 (which is the Dish aka Dishy) and then PFSENSE should stop having issues on reboot or new ip changes.
why it will work after some time (could be weeks, month maybe) anyways.
Well troubleshoot it... When it doesn't work - why doesn't it work... You can instantly tell from a simple ping if it came back by broadcasting when it doesn't come back fully qualified..
Your never going to figure out anything just wondering about it - its not rocket science here there are only so many ways to resolve a name to an IP be it fully qualified or not or dns query..
But no your never going to understand anything on why something does or doesn't work if you don't actually understand the method your using to resolve or not resolve.
If I put in just nas and it doesn't come back fully qualified and the IP I know my name resolution is failing. But until look into not exactly sure why - did my client no longer send the correct domain, did my dns not answer, does my dns not have that record in there and sent back nx, or servfail, etc. etc.
edit: Maybe your trying to hit something up in your browser - and yoru browser decided to F whatever you doing locally and ask xyz dns via doh.. etc.. Because just ask the browser makers - users are too stupid to be able to run their own dns and resolve what they want how they want.. So since they know better and could switch from your local dns to theirs on a whim ;)
Something else to consider if your switches and APs support it might be 802.11x / WAP2 Enterprise using RADIUS.
You could have the clients authenticate before they get an address at all, and the RADIUS server would tell the switches/APs/etc where to put the clients on the network (e.g. a specific SSID, VLAN, or address assignment). That separates the user identification from other parts of the process which are more prone to error.
That may be its own special kind of management headache and end user headache, however. It's much more viable for wireless than wired clients.
At least that way you would know for certain that the clients you want to use a specific network are the correct clients without having to guess by MAC address.
I have tried defining OMAPI (same key & port) for all LAN interfaces, only 1st and only the last one. However OMAPI entry is not written into the DHCP config file and OMAPI port is not listened as the result.
Thanks. I haven't created any rules to port forward traffic from the WAN to Lan (Not sure what the hell I was thinking).
Yes PfSence won't be public facing once I re-set up the lab. I don't see any benefit from having web access to either Esxi or PfSense, so I'll make sure that they are set up on private ip's when I do set it all back up.
I do have to thank you both for helping. I can't believe how dumb I've been with this.
That list, the "Access Lists" is only used when you check :
I've checked that "Disable Auto-added Access Control" so I have to populate the list myself :
Normally, the default is :
will do just fine, as all 'known' interfaces will get included :
By default, IPv4 and IPv6 networks residing on internal interfaces of this system are permitted.
If you have other networks, and these aren't known to pfSense (unbound), you have to use the Access Lists tab.
For IPv4 stuff, this isn't really hard.
Things gets a bit more complicated if you have a double stack (IPv4 and IPv6) - see my image.
@johnpoz Thanks, I see what I was doing wrong. When I clicked on the plus sign to create a static mapping the default hostname carried forward was the IP for the current device. I just assumed that everything filled in was good to go. Thanks again.
I just wanted all on this topic to know that my Netgate has not crashed once since reducing/modifing the pfBlocker geo IP rules as well as changing to Python for Unbound. I'm going to upgrade to the latest OS tonight...21.05. Thanks again all! Franklin p....
If the client sends that as its hostname.. Then ok - but dhcp leases shouldn't be showing a fqdn.. It would only be showing the hostname.
If you want client amazon-random# to show up as alexa-name in your dhcp lease. The correct solution is to either have that specific client send that hostname to the dhcpd, which I don't think you can do on alexa. Or tell the dhcp server to use hostname xyz in the host name when you set a reservation.
If your setting reservations for your clients, and register that in dhcp settings - then all your dns is taken care of.
There you go - once that is done, and the new version becomes available downstream.. If there is just a setting to up it. Then either pfsense can add it to the gui in the form of a number you set, or as with some of the more advanced unbound stuff you can just put it in the option box.
Until that time the domain override should work for domains you run into such an issue with.
@gertjan Well, problem has been solved. My set up involved 2 unmanaged switches. The eero connected to the first switch to provide internet access to wired devices. The error: I had two cables from the first switch connecting to the second switch. When I found this to be the case, unplugging one immediately fixed the problem.
@gertjan I wont update to 2.5.1 since it has the MultiWAN issue.
Normally the same branch of releases has access to package repository
Check your update path under System/Update (should be latest stable 2.5.x).
Also check your internet/DNS connectivity, as
pkg-static: https://files01.netgate.com/pfSense_v2_5_1_amd64-pfSense_v2_5_1/meta.txz: No route to host
"No route to host" clearly is an error that is local to you. Could perhaps be DNS related as the file-servers for packages are resolved via SRV records. Also check out via console:
[2.5.0-RELEASE][firstname.lastname@example.org]/root: pkg-static update
Updating pfSense-core repository catalogue...
pfSense-core repository is up to date.
Updating pfSense repository catalogue...
pfSense repository is up to date.
All repositories are up to date.
pkg-static update should run without problem. I assume it doesn't for you?
pfBlockerNG can restart unbound regularly. Do a manual reload of pfBlockerNG and see for yourself.
This option :
will also restart unbound when a new DHCP lease comes in.
Although, checking that option and using pfBlockerNG will make it complaining about it :
That is : the Python mode doesn't 'like' this "DHCP Registration" setting, so, if set, it (pfBlockerNG ) will default to the older "unbound mode" This mode uses more resources and is slower to restart.
When DNS service drops out, I can wait about 20 minutes for it to come back by itself
This is the real issue : it did not crash, it was just restarting, and this shouldn't take that long.
Or it does so on your system.
Bring your system back to default settings (remove or de activate pfBlockerNG and other packages) and add them back again step by step. Restart unbound with the GUI :
and check with the unbound logs how long it took.
Do this for each step, each feed you add to pfBlockerNG.
The Firewall > pfBlockerNG > Update : Reload > All
also shows you how much time it took for unbound to restart :
We provide leading-edge network security at a fair price - regardless of organizational size or network sophistication. We believe that an open-source security model offers disruptive pricing along with the agility required to quickly address emerging threats.
Subscribe to our Newsletter
Product information, software announcements, and special offers. See our newsletter archive to sign up for future newsletters and to read past announcements.