@patch Take any IP in the internet, which you know is responding to ICMP requests. You can set it for monitoring in the gateway settings.

@jimp great! Works!

Ouch! That's an ugly error. It means one of two things. Your file system is suffering from possible corruption and the data area where that particular shared library is stored in reading in with errors; You installed some non-standard package from a third-party (non-pfSense) repository, and it pulled in a dependency that overwrote the same library the pfSense-installed components use. In either case, it might be best to reinstall from scratch. Save a configuration backup file offline, then follow the reinstall steps here: https://docs.netgate.com/pfsense/en/latest/backup/restore-during-install.html.

@praveen02 said in DNS not working from OPENVPN connected Machine: The DNS - A record is configured in local winodws DNS server. Well if your pointing your dns to windows - that has nothing to do with unbound. Where do you point your vpn clients for dns - if its unbound, you need to allow for their vpn IPs in your acls.. If your pointing them to windows dns - then you need to make sure your windows box allows them to query, possible windows firewall issue and the vpn IPs. unbound acls can be created here [image: 1637163530508-aclunbound.jpg]

@gertjan Thank you for your help again. It's back to running quite well and blocking properly. I do believe that because only my domain names A records were deleted and replace that it was the built in anti DNS Rebind feature that saved everything inside my network from further attack.

@bmeeks said in Resolve Reverse DNS?: in-addr.arpa Thank you so much, that did the trick

@dono Look in the forum "DHCP and DNS", there is a thread that talks about DHCP issues with his provider. There was a solution : DHCP client unable to get lease from cable provider [solved]

@scilek said in DHCP server listens on all IPs: @bingo600 said in DHCP server listens on all IPs: If i had that issue , I'd prob. end up running the specific DHCP & FreeRadius on a separate server , and connect that to the specific L2 Lan. Or even better, get hold of an old laptop, install Debian on it and move FreeRADIUS and other utilities to that one. I can't think of anything else right now. What would you recommend? That was what i meant with "server" A raspberry-pi could do it , but i'd not use such a "beast" for production , primarily due to the SD card. If it had M2 or EMMC yes , but SD in a prod environment ... Naah. /Bingo

@viragomann yeah it is sad, but i cannot do much about it. I'm going to skip dynamic dns providers entirely. i set up knotd dns server and use rfc2136 client to keep track of my ip's, seems to work pretty well so far. btw, we are still offline on our main isp, it is going for a week already. Always the same pattern, slight packet loss, more packet loss, offline...

@jimfreeze if you need more ports, use a switch.. You could pick up a 8 port gig smart switch for like $40.. https://www.amazon.com/NETGEAR-8-Port-Gigabit-Ethernet-Managed/dp/B07PLFCQVK/ref=psdc_281414_t3_B08P2C2GXF Dumb switch for like $20 What exactly are you doing? https://docs.netgate.com/pfsense/en/latest/bridges/interfaces.html

@patch said in Some domains won't resolve after setting up static IP: Except I think it over looks the fact I think with you, as I tend to agree with your observation. pfSense should behave the same as before, that is, after a factory reset + import backed up config. Because, if not, it means that there are settings that do not depend on what is found in the config file. Or, your issue was resolved doing just that : goto factory, import config .... and situation as not the same, the issue was solved. This shouldn't happen, as it implies something isn't right. There are reasons to explain the behaviour : Modify the config file manually with conflictual settings. Doing an initial interface assignment slightly different as the previous interface assignment. And probably others. Btw : there are (must be) very few differences between : A simple reboot, and a reboot + interface assignment + import config.

@steveits OK. I went back and found most of the other units we've installed were at 2,000,000 and their RAM is OK. I guess it's not really an efficiency to worry about.

@sttwebs If you're able to edit a fie : The file /etc/inc/dyndns.class : [image: 1636632296628-95bd845f-e858-4675-a4e6-e7545e99bec7-image.png] The first test is done for "200" which indicates "OK" or all went went. The test is done with the "$header" variable. The next test looks for any "4xx" return codes. There was a failure, so the header contains a "4xx" error code, which could (example) mention "Page nor found". The final case dumps the $data variable. But, it's empty. A "(Unknown Reponse") is also logged. Can you change this "$data" on line 2473 for "$header" to have the header logged instead of the empty $data variable ? Change also the text string "(Unknown Reponse") for "(Unknown - HERE WE ARE - Reponse") so you know this code gets executed, as it should be logged also. This is what I would do .... I can't really test as I have no godaddy account.

This worked to fix the problem. Is there a way to unblock DNS resolver from blocking boot up? What worked: cp /var/unbound/pfb_dnsbl.conf /tmp rm /var/unbound/pfb_dnsbl.conf touch /var/unbound/pfb_dnsbl.conf

Thank you! I'm not sure how I missed that tab.

@bmeeks said in pfSense DHCP + Windows DNS, Reverse Lookup Problems, No PTR Records Being Created: When DHCP is implemented, by default the PTR Records are registered to DNS by DHCP Server, whereas the Host (A) records are registered by DHCP client. This is due to the fact that client is the source of the hostname and DHCP is the source of the IP address. This is interesting, but I have enabled client PTR registration in all Windows machines, so that is resolved. All other clients are non-Windows and therefore non-Active Directory so not an issue. Despite that, I have exported the host list from DHCP to DNS and created PTR records for my non-Windows clients such as my Android phone, watch, kindle etc. Everything is working fine now. Its all sorted............ Thanks

@stewart rebind has all kinds of serious issues with it https://en.wikipedia.org/wiki/DNS_rebinding It is never a good idea for anything other than a local domain to resolve to rfc1918 space. If you have some fqdn that is going to resolve to rfc1918 space you need to take the appropriate action on unbound config to let it know this is not a rebind issue. Private domain setting for example. Plex users have to do this for their plex.direct domain since it an external dns that resolves to your local IP of your plex server.. The plex example isn't saying that its a good idea to do that - its just a way they are leveraging ability to do SSL with users different dns, etc. Rebind is not the best way to do that - but it is the way they did it - so you have to make exception for it in your overall rebind protection. If you have something else doing something where it returns rfc1918 you just have to let unbound know, so it it doesn't think its a attempt at rebind.