Its possible their device the .121 doesn't answer pings.. Do you see its mac in your arp table?

So I was able to find some information related to my problem. You do have to set the gateway to bridge mode. There is a certificate authentication process that can only be handled by the frontier gateway. Supposedly there is a workaround on pfsense, but it's way over my head. Here is the link on reddit. [https://www.reddit.com/r/PFSENSE/comments/eukg72/is_there_a_way_to_completely_remove_the_att/] The other problem I have with my gateway is that there is no bridge mode. So I ended up disabling everything on the gateway except for dhcp, and set a dmz. I then set it to forward all packets to a mac address I set for the wan on pfsense. Everything has been working perfect, so I guess this is what I have to live with until there is a better solution for certificate authentication on pfsense.

@ddave So internet is working, I mean you can access it but DNS is not working. If you go around the DNS of pfSense (for example use 8.8.8.8 directly on your computer) internet is then working fine. At the point where unbound is not responding anymore, can you check what the status of unbound is? Go to Status -> Services and check if unbound is running. If it is not then I would try and disable pfBlockerNG (even better remove it) reboot pfSense and see if it stays stable. If not then it is time to start enabling unbound logging / debug and try to figure out what is crashing it. I remember unbound being unstable on my 2.5.0 install and from what I read on the internet a lot of people reported that. I then decided to move on to AdGuard Home (or PiHole) for my DNS and DNSBL needs and just hope that Netgate would fix that. Then I found the link about updating unbound and since then my install has been running fine. BUT I do keep my AdGuard Home server running in case unbound decides to quit again because I cannot be bothered to troubleshoot something that basically was running fine in 2.4.5 - p1.

@kiokoman Ok, thanks, will try that.

@nollipfsense said in PFsense Box with 32 gigs or ram: Or one could set it to 192.168.1.1 ... correct? 192.168.1.1 ? The resolver normally listens to all LAN type interfaces, and the local host 127.0.0.1 So, typically, it listens on 192.168.1.1 by default, so it can receive DNS requests from the local LAN clients. It looks for the root servers on WAN type interfaces (the ones that have a gateway), because these interfaces could (should) route a (the) TLD's or "13 root name servers." Setting to 192.168.1.1 means : unbound points (forwards) to unbound (forwards) to unbound (forwards) to unbound (forwards) to unbound (forwards) to unbound ..... and then it crashes. Happily enough, it's protected to ignore such setup errors.

@tagit446 forgot to tell, don't forget to enable log for these rules.

@bob-dig thanks that worked deleting the files there in the db... after deleting it changed everything to .localdomain and then after another 10 min it renamed everything to the localhost names so i dunno why it was going crazy with the number or so.. but deleting fixed it.. i was going crazy shutting off everything refreshing clearing rebooting pfsense 3 times nothing had solved it but deleting thoses files did

@johnpoz I know this is old but THANK YOU! I was seeing a million of these entries on a bunch of interfaces, LAN, S2S_VPNs, etc on ONLY ONE of my pfSense appliances and couldn't figure out what the hell was going on!

@kom I'm learning that. Thanks for your help with this.

@balanga Enter "CSRF check failed" in your favourite search engin, and find articles like this : https://stackoverflow.com/questions/57048799/what-is-csrf-check-failed-when-going-on-a-website-which-doesnt-require-login

Yeah pkg/pkg-static is required to run the upgrade so it must be functional. Reinstalling and restoring the config is often faster and easier if you've ever done it before. Steve

@trickyt I used good old "dd" on my Mac and it does the job every time. balenaEtcher is probably safer from typos however.

Yeah that should be update version, so you were on something previous to 2.4.5p1? And it updated to that? Were you on 2.4.4p3? You have not provided an abundance of information here.. What did it actually update, if it updated packages without upgrading the base version you could have some issues. 2.4.5_1 is not current.. But is supported still, if you would like to stay on that version.. And you have it set in your upgrade settings to stay on that version.. You should be fine.

I'm trying to wake up the whole lan too using this command : php /usr/local/www/services_wol.php wakeall=true But it doesn't work.... Have anyone any idea that could help?

@am-steen Only you installing nmap / ncat / netcat and you trying from the internet yourself.

NAT on non-default routes is fixed in 21.02.2. The Arm7 Snort issue is still outstanding. We are aware of the impact there and are working to address it. Steve

@brucexling said in Printers Not on Current VLAN: I have read some accounts that it can be problematic trying to print to a printer not on the current network. This is the case if your trying to use L2 discovery to find the printer in the first place. Airprint for example will not work across vlans. But printing across vlans is not problematic - if you are printing to the IP or the fqdn that resolves to the IP of the printer. And the appropriate firewall rules are in place to allow the ports your using for your printing protocol.