@throttlenerd well your not sniffing on the correct interface? If your seeing it in the logs that its blocked, then packet capture would capture it.

capture.jpg

You sure the traffic is still being seen when your doing the capture - ie are you still logging those denies?

@Stewart The new BIOS fixed the issue so now all 5 ports run at 2.5Gbe. It also sets much higher default PL1, PL2, and PL4 settings. The temps still stay in normal parameters but isn't the most efficient. I've run 17 different combinations of PL1 and PL2 with the default PL4 of 33W to find the best speed and then started adjusting PL4 to fine tune. Maybe not the best way of doing it but that was my process. Overall I found the best combination of speed and power for iperf over OpenVPN is:
PL1=9
PL2=10
PL4=30

Dropping PL1 to 8 impacts performance about 60Mbps but doesn't reduce heat or power.
Dropping PL2 to 8 also reduces performance but doesn't reduce heat or power.
PL4 default is now 33. Lowering it to 30 reduces temps from 69C to 61-62C and lowers speed from 575Mbps to 550Mbps. Lowering it to 29 reduces speed to 490 and keeps temp at 61C so no real change.

Temp was determined by running iperf -P4 -t 300 and seeing what the temp was just before the end of the run. Everything seemed to idle the same no matter what the settings were at around 45C. Skin of the unit is always warm to the touch. I have a thermometer that I've set on top that generally reads 33C-34C (around 95F). It also doesn't seem to change much whether it is idle or under heavy load. The unit idles around 11W no matter the settings and, depending on PL settings, only goes up to 15-18W (most all settings showed 15W as the load limit for the iperf tests). For reference it does spike into the mid-20's in Windows.

Speed was determined by the average of the last 10 seconds of the 5 minute test. I felt that I had to do this as the tests generally started out very high, in the 1.2Gbps-1.4Gbps range, and then fell over the course of the first minute to settle around the 5 minute average. Sometimes it would hold that for 5-10 seconds, some times for over 40 seconds. No idea unless it's some kind of TAU setting allowing the assigned core to spike for varying amounts of times.

@stephenw10

Hi Steve,

Thanks again! I quickly got the firmware from support!

I was able to reinstall it to the appliance and am back up and running!

Thanks,

Patrick

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.