WOW that was fast. ☺
Thanks Jim!

-Rico

Thanks for the tip - I've applied it and we haven't had any drops in the 2 hours or so since. Will report back if it stays smoothed out!

Oops.

I never saw that "+" on the top right corner.
That explains why I found code that handles this setting, without finding the GUI part.

Btw :
It shows 60 !
0_1544016161146_a3e12c67-0c4a-4d9b-9ff4-bd802d95be7e-image.png

I think it was a spanning tree problem. I'll do some more testing in a few days.

Thanks for the replies

Another link that may be helpful....

https://forum.netgate.com/topic/112490/how-to-2-4-0-zfs-install-ram-disk-hot-spare-snapshot-resilver-root-drive

You didn't indicate if your manual shutdown was graceful or just you powering it off.

If graceful then you may have a bad disk on your hands. Bad i/o might have caused your original problem where you had to manually intervene.

If dirty shutdown then you were unlucky and managed to corrupt ufs, which isn't uncommon for dirty shutdowns. Have a good config backup (Diagnostics - Backup & Restore) for just such an emergency.

Hmm, OK. That should work.

I'd probably run some packet captures on WAN the OpenVPN interface when trying to ping out to IPs that shoulkd be reachable over each from VLAN 20. See what traffic is actually going where and what replies, if any, are returning.

Steve

If you're that concerned about brute-force attacks then do the sensible thing and don't expose WebGUI/ssh to WAN. Put it all behind OpenVPN and access it through that.

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.