I have this same issue and am using 2.4.4p1. Was just installing a couple pfsense routers yesterday and ran into this.

Glad to hear you got it going.

You could also do this with three NICs and two switches. NIC 1 -> WAN NIC 2 -> LAN NIC 3 -> DMZ Set up your FW rules so that connections can go into the DMZ, nothing can initiate a connection out of it. Then you're done. You'll have the physical segmentation you're looking for, and it's relatively inexpensive and fairly simple to do this.

@stewart I too would like to get to the bottom of why this is occurring. It's my nature to understand all that I can. Currently I have a couple of projects going so for the moment I will leave this be for the next couple weeks as the issue is not a high priority right now.

Looks like https://redmine.pfsense.org/issues/8165 is closed to early. We still see problems with IPv6 fragments, in our case with local created ones which simply disappear. Depending on certificates and keysizes used Strongswan will use "oversized" UDP packets in the IKEv2 connection etsablishment. If the remote side does not support IKEv2 Fragmentation (Windows older than Version 10 /1803) the packet is never leaving the pfsense box if IPv6 is used. A Capture done at the WAN Interface show that this packet is simply missing and therefore the handshake never completes. This is still the case on latest 2.4.4-RELEASE-p1.

@tim-mcmanus said in Auto Config backup.: So your compliance needs are for data to be encrypted while in transit and at rest? What are the additional compliance requirements for data at rest? Sounds a lot like HIPAA or SEC/OCC compliance. yes at rest and as well as in transit. Also methodology used to achieve backup. You could simply get an Amazon CentOS server and put it on S3 storage to pass audits. S3 is encrypted at rest, but the data file itself would not be. Depends on your auditor and their mood. If Netgate had regular audits and could produce/maintain an ISO 27001 document demonstrating compliance, with additional assurances of data encryption at rest, that should also comply with your audit requirements. This is something you will get from any data center provider if they are hosting your stuff. But without knowing what your data at rest compliance requirements are, getting you an exact solution to your compliance needs may be elusive. well I already have external server in place which used git-crypt to store config and generates email for every change done in firewall with source ip and username. it took around 2 months to design this solution using dozens of open source modules. only problem is that keyless ssh is used which is not safe when firewall is in picture.

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 ! [image: 1544016162619-a3e12c67-0c4a-4d9b-9ff4-bd802d95be7e-image-resized.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.