system vs interrupt load. 3 cores there are pegged though. The loading from pf itself appears as interrupt load. Check the NICs are using more than one queue. Try testing between different NICs rather than VLANs on the same NIC, which share the same queues.

@bigtfromaz said in pfSense Certificate Manager's Revocation list (CRL) is unavailable: Why not just expose it in the configuration dialog? Well they prob want you to use certs from their CA, etc. But yeah I hear yeah.. But then - this would of never been brought up, and I wouldn't of learned something new ;) Part of the reason I have stuck around here for so long and love helping people. Is helping someone figure out something almost always leads to people on both sides of the problem learning something.. And it brings up a possible feature request to expose being able to add a crl distribution uri in the gui, which would be win everyone using pfsense cert manager for more than just openvpn ;) or the webgui of pfsense. I use it for all my local certs.. I have not run into needing to publish the crl, but I can see how it would be a bonus addition to the cert manager. Even if not hosting the crl off pfsense, but just being able to easy add the uri for the distribution point.

ah it was a dumb mistake. I took that NAT out, and then realized on my client it was set for socks not https and now im in business, thanks!!

Yes, you would create a VLAN 911 on the WAN NIC and then create the PPPoE connection on that VLAN. Should work fine. Steve

Hmm, that all look good. I can see that NDI chekcing in and it's being validated. After running that pkg-static update still fails? Try pkg-static -d update to see more error output.

@michmoor I believe that is for clients IPs.. I don't currently have squid or squid reports or anything installed, guess I could to take a look. But anything you google for squid PTR all comes up talking about the client IP. from back in the day, when I ran proxies for living ;) we almost always blocked direct IP access, and only specific ones were whitelisted. Not sure why a proxy would want to look up PTRs when you normally block direct IP access, etc. ;) But for clients, you could use client names in rules that allow, deny etc. So since client IPs might change you might want to do ptr on client IPs to know if its specific client based on its name.

@Remember said in Kernel keeps throwing messages: @bmeeks Any update on if/when this will be fixed so we can start using it? This problem was fixed back in August of 2021. If you are running the current Suricata package on pfSense you should not be seeing this errror. The current package version is 6.0.13 on RELEASE versions of pfSense CE and Plus, and version 7.0.0 on the DEVELOPMENT snapshots of pfSense CE and Plus.

@homeauto Mikrotik has nothing to do with your problem and I'll agree with Bingo600 that your issue(s) seem to suggest or related to NAT.

I use a new activation key from netgate and that helped get past this.

The location of the module installed by the package is the same. You should not have to change the loader values. The version of the pkg in 2.7 is 1.98.

https://docs.netgate.com/pfsense/en/latest/troubleshooting/logs-arp-moved.html

@stephenw10 OK I see ... This is slightly different from the rate limit I use in UFW or Firewalld ... In which the state auto resets. One assumes that as long as the limit of 4 in 30 seconds isn't exceeded the host isn't written and therefore will never require deletion with the Chron Job. I suppose maybe set the limit a little higher to resolve accidents - but leave the 1 hour Chron job - I did think of using my usual Fail2Ban - but I think this will work well as the SSH is protected with MFA any robot will immediately be blocked after hitting it so fast, and the times taken after lock to unlock will make any brute force practically beyond impossible - the MFA would stop em when they don't have the second device which is push notification so --- impossible. virtually. Thanks for your input

Check the pfSense DHCP status or logs. If there's a link there it can be handing a lease to itself.

@stephenw10 i just went ahead and reinstalled this morning. i appreciate the reply.

@BassStation70 yep. PfB can’t spoof HTTPS certs with valid certs so your browser will show the warning. Re: still working, could be DNS caching on your device, or a list update, etc.

Ah, it looks exactly like this: https://redmine.pfsense.org/issues/14685 So try a few rounds of fsck as mentioned there. Or switching to ZFS would also prevent it. Steve

Did you try the known fix for that? https://redmine.pfsense.org/issues/14207#note-2 https://docs.netgate.com/pfsense/en/latest/hardware/tune.html#rate-limiting Steve

@Gertjan @stephenw10 Yes, to both of you guys. I was tired and just trying to get things done. I made a backup in the UI and it was larger than I had thought it would be. Wanted to thank all of you for your help, and let you know I was/am not meaning to be rude. I wasn't able to get on yesterday, as my central air went out and as I don't have just over $12k to replace it, I had to do what I could to get it running again. Took about 7 straight hours. As for my firewall, I have not messed with it anymore, as I just haven't had the time. I cannot reproduce the issue, so I cannot submit it as a bug report. I am sure it is something stupid I did, while up all night after playing COD or something like that. When I first got my box, I had only the basic understanding of python, very basic, and had forgotten most of php, and the networking I did was 20 plus years ago. So it's been a bit of a challenge for me. You all have been VERY helpful, and again, thank you!

Hmm, so it tries to connect via em0 before it has an IP and fails. Then retries successfully?

That's what you would see if the device loses it's default route or has an invalid default route. Check Diag > Routes when it happens. Make sure the default gateway in System > Routing > Gateways is set to WAN and not automatic. Steve