With the patch, they should always be placed on the bottom when copying/moving to another interface.

See: https://docs.netgate.com/pfsense/en/latest/backup/zfsbe/status.html Yes the patch should have been applied against whatever BE you booted from. Which I assume was 'default'.

Any of those. I would start with ping to a local IP, then to some remote IP.

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