Hi, I did try that but it still didn't work. However, I have just managed to resolve the issue by upgrading via SSH from 2.4.2 to 2.4.4 and the web interface is now back. Thanks for your help. Regards, Robert.

@johnpoz I'll cross my fingers!

Ok, if your phone is backing up to the QNAP it's likely legitimate traffic rather than something trying to exploit the NAS. However it's running at the wrong time then as it's trying to connect via what the QNAP sees as it's external address and instead hitting the pfSense GUI. It's probably harmless but you could block access to the WAN address on port 443 from the LAN subnet to prevent it. Steve

@nehumanuscrede said in Logon / Performance oddity: even after the auto-update check is disabled, the appliance still attempts to update and / or talk to an external network device I don't recall the location offhand but there is an option somewhere to "do not send the device ID to Netgate" or something like that.

Is your wan going down, is it changing to a different wan connection.. Normal change of a rule will not reset states... Your saying ALL states are being killed? Are you running any sort of schedules?

@beremonavabi said in Reset States In 2.4.4: I'm hoping the message doesn't matter at all. I'm wondering if I've managed to break something since I didn't get the message before (I'm changing a lot of stuff). It doesn't matter. That's nginx failing to write back to your browser, and failing because the state was removed when you reset the state table. Normal and unavoidable.

Sifting through the boot logs and system logs now. When I rebooted it prompted to setup VLAN and assign WAN etc... Once past that all other config items are there, just the interfaces are all unassigned. Ill post once I find something. A separate issue I have found is unable to start radiusd through the GUI, can start it via shell with no problem, just wont start using the GUI. When setting up Freeradius3 in 2.4.3 this issue was not present. Only started in 2.4.4. Looking for log info on that as well.

Looking at this I would initially say you should be solving this at the hypervisor level. Perhaps by configuring the hosts as a cluster. That avoids this issue and makes the setup far more flexible. Steve

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..