The vast majority of CPUs/boards default to running at maximum speed if there is no cpufreq control running. However some so not, such as our own ADI systems, and require powerd running to see full performance.

The additional 1MHz shown as the maximum speed is the turbo bit used trigger turbo mode. You may need powerd running to see turbo used.

Powerd switches the CPU between P-states to improve efficiency but modern CPUs also switch between C-states which offer even lower power consumption. The result of that is that you won't likely see much reduction in power consumption at idle, P-states only really do much with some CPU loading where C-states are not used.

Steve

Additional noteworthy observations.

There was one strange thing about GIF configuration on pfSense 2.4.3 (and before?). I had to disable Outer Source Filtering on gif0 for the traffic to flow — otherwise even gateway monitoring pings were discarded upon reception: that is, if I remember correctly, ping replies were received on parent interface but rejected at GIF level. Those ping replies had proper source and destination addresses for both IPv4 and IPv6 and came in via proper interface. Of course, the IPv6 network for GIF tunnel itself was not the same as for overlaid network — but that is the case for all tunnels of all brokers. In particular, gif2 to the same broker was functioning well with Outer Source Filtering enabled by default, as well as gif1 to another broker.

Right before upgrading from 2.4.3 to 2.4.4, I noticed that gif2 also needs disabling Outer Source Filtering. I had no idea on why this happened and how long ago — just switched the offending setting, and the tunnel became operational for about a couple of hours until the update took place. Same as earlier, however, gif1 to another broker was functioning with Outer Source Filtering enabled by default, and used proper parent interface even after upgrading to pfSense 2.4.4.

Now that pfSense 2.4.4 is installed, I tried switching Outer Source Filtering back on and then off again — just in case — but observed no effect. That was expected indeed, as the primary issue is not with ingress filtering on local side: outgoing traffic is filtered by remote end because of improper source addresses caused by improper parent interface being used.

I also tried Disable Gateway Monitoring for both gateways corresponding to gif0 and gif2. That allowed the traffic to flow out unconditionally, but only showed that any kind of traffic — not just ICMP pings — chose wrong parent interface. I once again tried changing default gateway settings, and the outcome was equally negligible. That is, sometimes I saw small bursts of legitimate traffic pass out and then in (such as my NTP server making a request and receiving a reply), but it is hard to correlate to settings change as those bursts stop soon. The other times I see legitimate inbound traffic entering proper parent interface, but somehow filtered on local side — such as incoming NTP and DNS requests with no reply from my home server [because pfSense filtered those requests out]. :puzzled:

Solved the issue needed to update the kernel.

No. They are enumerated by the operating system. Why do you care what the physical name is?

If you have, for example, LAN on re0 and want it on re2, you can make that change in Interfaces > Assignments as long as re2 is not assigned to anything else.

Figured it out!

Under DHCP, I had ARP Table Static Entry ticket when assigning a static IP. I disabled that and now it works.

Thanks for the help

Well we need to see what it's actually failing to do. The output you posted above looks like there is no problem.

Steve

What sort of connection is it?

Restarting packages is expected is the WAN goes down. You can limit some unnecessary actions if you only have one WAN by setting Disable Gateway Monitoring Action on the WAN gateway in System > Routing > Gateways, edit the WAN gateway.

Steve

If you have removed the gateway from the LAN you should switch outbound NAT rules back to automatic.
The rule you have there currently has source 'any' which is almost always wrong. It will NAT even traffic from the firewall itself which can cause all sorts of odd issues.

Steve

What WAN IP is pfSense getting (if it is getting one)?

It must be in a different subnet to the LAN or routing will break.

If it does have an IP and it's in a different subnet try to ping out from the pfSense console. Try to ping an IP like 8.8.8.8. Try to ping an named host like google.com. What errors do you see if those fail?

Steve

Stealth means the packet is being dropped and their crap scan isn’t getting a rejected packet notifying them that it’s blocked.

Steal or blocked, it’s working properly.

I log the interesting traffic... So for starters I want to know what my IOT stuff is doing.. So I log their vlans for outbound traffic.

On the wan - yeah it can be noisy.. But I do like to see directed unsolicited traffic, so I log just that SYN's to my wan IP.. Its more just curiosity sort of thing... Like for example when all those routers got taken offline like a million of them in DE alone shitton of noise being seen on 7547.. Yeah I was seeing that as well ;)

Your typical noise ports are the common 22, 23, 3389, 1433, etc.. All well known script/bot traffic looking for shit to exploit.. Its noise - but it is interesting to see how much of it gets dropped..

yeah were are using the little ones with no fans that work really actually well.(j1900) started out with some pc that had pfsense on them but they just offered more for less for as having a appliance firewall, i cant have any complaint they have been great and have worked for years without problems. I am guessing i now have to learn kubernetes. It seems like a solution to the problem.

Local is the host (source or destination) in the same subnet as the firewall on that interface. Remote is the host that it is talking to. If you access a web site, the IP address of that web site would show when in that mode.

See this recent thread for additional detail.

https://forum.netgate.com/topic/137939/bypass-su-sorry-on-pfsense

Thank you for your input Grimson and mhertzfeld.
The reason for removing the switch was twofold.
I am trying to minimise energy consumption and I was curious to see what could be achieved using just the pfSense box without a switch. I tend to always try to find ways of improving things, sometimes more successfully than others.
I might just use the switch again.
I actually didn't want to implement vlans at all, but the switch is a layer 3 3com/HP switch and perfectly capable of doing that.

Kind regards

Thx! Yea, did what you suggested and you're exactly right. It's the card.

Never mind. Found the problem.

I'm trying to NAT to a host that's also used in HAProxy. Under HAProxy/Backend/advanced setting, I have turned on Transparent Proxy (So that my logs shows the correct incoming IP).

This messed up NAT. Turn Transparent Client IP off and NAT works again.

@stephenw10 says I can't start a chat with you unless you initiate it.

OpenNMS is easy to install and set up on a CentOS image. I use it all the time. If you set up SNMP on all of your devices, you'll get a lot of good data from it.

Any open source NMS package will do this, a few have been mentioned already on this thread. OpenNMS will also pull some fantastic metrics from pfSense once you set up SNMP on it.