Hi...
I would like to thank everyone for their help.
I do not know what the problem was, the other day it was working normal, without any changes

We are not mind readers you going to have to post a picture what the rules you created!

@NogBadTheBad
Appreciate it. FreeRADIUS seems to start just fine and will run for many weeks without an issue, until it stops and doesn't automatically restart.

Nope, it's there for amd64, I double checked.

This is not all that uncommon. The Snort portscan preprocessor is very "trigger happy" ... ☺ .

Go to the PREPROCESSORS tab for the impacted Snort interface and set the Sensitivity drop-down selector to Low. Save the change and restart Snort on the interface. That should help.

If the Sensitivity setting is already Low, then you will probably have to disable that particular rule. Click the red X under the SID column on the ALERTS tab to disable it.

I retrive in System Logs many:

swap_pager_getswapspace(32): failed

Look in the firewall's system log around the time you suspect Suricata crashed. Odds are you will find a Signal 10 Bus Error. This is the result of an unaligned access to memory. It is a problem in Snort, Suricata and clamAV as a minimum on ARM hardware such as the SG-3100. I've tried a fix for Snort and Suricata. The Suricata fix was successful for a time, but not anymore.

The issue is complicated to explain, but if you Google "unaligned memory access" you will find some info on what that is. This is only a problem on ARM hardware. Intel CPUs are immune as they will "auto-fixup" instructions that attempt unaligned access.

I looked into this in some detail and found that the main problem in FreeBSD is with the llvm compiler used to create armv6/armv7 binary code. That compiler chooses at times to use an ARM instruction pair that does not support unaligned access. The compiler could choose to use a different pair of instructions to accomplish the same thing, and that different pair will support unaligned access via "auto-fixup" just like Intel CPUs.

While it is technically true the issue lies within the C programming code of the binary packages that are failing on ARM hardware, the practical implication is that since the code works on Intel hardware without issue -- and because the ARM hardware base is very small -- the upstream projects for Snort, Suricata, clamAV and others have no great desire to invest the energy and effort required to find the bugs in the C code and fix them.

I worked with the pfSense team and we turned off compiler optimizations for these packages. It worked initially for Suricata, but now some change has crept into the upstream project and that change is causing unaligned access issues again on ARM hardware.

The problem will appear as a random bug because it takes a particular sequence of data and the resulting program code flow while processing that data to hit the instruction that attempts the unaligned memory access. When the unaligned access occurs, that triggers a CPU hardware interrupt fault and the OS shuts down the application (and logs the Signal 10 bus error).

Your going to have to actually give some details to work with here people!

Where are you forwarding too? What does a query direct to that look like from your client as far as time.. What does the query time look like from client to pfsense?

Example if your forwarding to 8.8.8.8

$ dig www.google.com @8.8.8.8 ; <<>> DiG 9.14.1 <<>> www.google.com @8.8.8.8 ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 34825 ;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1 ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags:; udp: 512 ;; QUESTION SECTION: ;www.google.com. IN A ;; ANSWER SECTION: www.google.com. 285 IN A 216.58.192.132 ;; Query time: 21 msec ;; SERVER: 8.8.8.8#53(8.8.8.8) ;; WHEN: Sat May 18 15:49:17 Central Daylight Time 2019 ;; MSG SIZE rcvd: 59

Here is to unbound on pfsense.

$ dig www.google.com ; <<>> DiG 9.14.1 <<>> www.google.com ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 50496 ;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1 ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags:; udp: 4096 ;; QUESTION SECTION: ;www.google.com. IN A ;; ANSWER SECTION: www.google.com. 257 IN A 172.217.6.100 ;; Query time: 1 msec ;; SERVER: 192.168.3.10#53(192.168.3.10) ;; WHEN: Sat May 18 15:49:41 Central Daylight Time 2019 ;; MSG SIZE rcvd: 59

I think the reboot solved the issue, still working for now.
will monitor it and return if there is something new.
Thank you for your help :)

@egonzalezgdl I would personally install pfsense using the same version the config was created on, then do the upgrade to the latest.

On further thought, I think I understand why it won't work...

Openvpn is connected to the wan and traffic from openvpn unless going to the lan, like dns, isn't going through the lan interface. So it is technically monitoring the data correctly for the interface it just isn't able to do what I want it to do.

It's great information. Thank you.

thanks for all the replies. I will have a look at updating to a newer version ASAP. I was having problems flashing version 8 of the watch guard BIOS but will give it another try.

I did change the Backup Count to 0 but it didn't help!
When I edit/create a rule it actually creates the backup first and then removes it according to the backup count 0.

After setting Backup Count to 0 :

#ls -l total 4 -rw-r--r-- 1 root wheel 6 Apr 30 22:36 backup.cache

While creating a NAT rule:

#ls -l total 3236 -rw-r--r-- 1 root wheel 6 Apr 30 22:36 backup.cache -rw-r--r-- 1 root wheel 3252224 Apr 30 22:36 config-1556647551.xml #ls -l total 4324 -rw-r--r-- 1 root wheel 6 Apr 30 22:36 backup.cache -rw-r--r-- 1 root wheel 4390912 Apr 30 22:36 config-1556647551.xml #ls -l total 7044 -rw-r--r-- 1 root wheel 6 Apr 30 22:36 backup.cache -rw-r--r-- 1 root wheel 7176192 Apr 30 22:37 config-1556647551.xml #ls -l total 8100 -rw-r--r-- 1 root wheel 173 Apr 30 22:37 backup.cache -rw-r--r-- 1 root wheel 8255935 Apr 30 22:37 config-1556647551.xml #ls -l total 4 -rw-r--r-- 1 root wheel 6 Apr 30 22:37 backup.cache

So, it still takes a minute or so to create/modify a rule!!!

No. pfSense is a firewall, not a development platform.

Compile the code on a similar FreeBSD system and then copy the binaries to the firewall.

@woodsod Thanks for the update!

Just a follow up, this is resolved. It was actually an issue with the provider that was not working. They had to update a MPLS record on their side. Once they did that, it worked as expected and fails over automatically.