@stephenw10 The issue is with the WAN—packet loss and loss of internet—but I can still access the system via LAN. Rebooting sometimes resolves it, but only for hours or minutes.

I suspect it’s a settings issue. I’ve had similar issues with this ISP when running pfSense on an old PC. However, the ISP-supplied router runs without issues for months, so the service itself seems fine.

I’m considering a Netgate appliance to remove uncertainties, but I believe the problem lies with the QNAP VM. I’ve experienced the same issue with OPNSense and SOPHOS Home on the VM: internet loss while LAN stays functional.

Swapping the LAN/WAN ports yields the same result, so it doesn’t seem to be a port-specific problem.

@Luca-De-Andreis said in PHP ERROR: Type: 1:

https://redmine.pfsense.org/issues/15907

Yup you can just apply the fix as a patch using the System Patches package.

Thank you, I’ll give it a try and find out.

@Gblenn @stephenw10

Well finally the test work as they should.

Setup a 3 Tier failover and failed the fiber - tested, and then failed one of the ATT Modems - tested
Finally worked as it should - the failover is almost immediate (less than 20 sec).
The recovery after correcting the fail is very quick now , with IPv6 disabled on the fiber. The recovery (coming back online) takes about a minute or 2 with the ATT modems.

The ATT modems require - "Enabling Forwarding Mode" under the Reslover settings (apparently a known issue with various ATT moodems). I do not have a setting anywhere to disable DNS error assist. Haven't heard back from backend support at ATT yet.
Also to re-cap -- apparently if ATT gives you a static IP on one of thier 5G gateway modems they hobble or disable the dhclient (dhcp for a WAN) so it requires entering the static IP if you are using IP passthrough.

Thanks for ALL you guys help so far!!

The graphical tests show the change to the 2 different ATT modems static IP and a speedtest use of data up and down.

Screenshot 2024-12-21 110554.png

Screenshot 2024-12-21 090739.png Screenshot 2024-12-21 090714.png Screenshot 2024-12-21 090509.png Screenshot 2024-12-21 090435.png

@JonathanLee Keep in mind "swapoff" may not immediately free up swap space. I think items in swap need to wind up getting released (basically the VM system recognizes no longer needed) before the swap device is actually taken offline.

@enjawd But the other port (10G) on your pfSense is most probably not in the same LAN as the 1G port...

@mer it’s on a external drive so if someone grabs it and takes it my credit card etc is not on the drive as it’s encrypted non readable. Again it’s not internally stored, FreeBSD forum recommendation was to use Eli for external usb swaps as they can be grabbed and walk off.

TIL about the System Patches package and path strips. Thanks for your help @stephenw10 . We're back in business.

@jra9511 said in Common rules for various interfaces in Suricata with Pfsense:

Thanks for the answer, really what we want is to see how to apply the same file that contains several rules to all the configured interfaces, otherwise we have to edit the rules in each interface and copy them. We try to do it through the MGMT SID but it gives us a warning that the file is found but the rule is not loaded, we clarify that we are not using any of the default rules that suricata comes with, we use one called custom rules to adapt it to our environment and avoid false positives

No, there is no common file. On pfSense, each configured Suricata interface has all of its files contained within a unique subdirectory underneath /usr/local/etc/suricata/. The contents of custom rules are actually stored as Base64 encoded data within the config.xml firewall configuration file and then written out to a text file in the interface's subdirectory when needed. Any changes you might make to those local files will be overwritten by the GUI code the next time any setting is modified within the GUI.

I don't know what your pfSense experience level is, but some new folks are not aware that pretty much every configuration parameter is stored in the config.xml file and then written out to the various text files in /etc/ and /usr/local/etc/ and other locations when the user clicks Save. That means any changes made directly to these system files are not persistent as the files are recreated using the config.xml contents when changes are saved.

@stephenw10 getting it to fit will be a challenge, with the cable I should be able to add nonconductive tape on the bottom of it and Velcro it, the other straight adapters would be too long it would hit the back, and the 90 degree one would work but put the drive directly over the cpu and memory with the added heat that would cause issues. I am thinking about velcroing it to the top side where it is close to the vented area, adding a heat sink or something to it.

@Gertjan So I used both tcpdump and radsniff to look at packet traces, but I can't see any issues. In both cases (working and non-working) the radius server sends back an Access-Accept message with the same set of fields.

@stephenw10 - Excellent! Patch worked. Glad I wasn't imagining things.

Our solution at this point :

Automatically :

Remove unwanted boot environnements Update the train to the stable version Check upgrade availability (pfSense-upgrade -d -c) Prefetch all packages (pkg fetch -u -d -y)

So we want finally launch the upgrade (pfSense-upgrade -4 -d -y) it's faster !

@JonathanLee said in issues with dumpdev in /etc/defaults/rc.conf:

sysctl debug.kdb.panic=1

b9160abf-7a3b-47d4-a8c5-0ace4dae0fe1-image.png

Custom solution

add the cron copy the rc.dumpon to rc.dumpon.old
add the new info

and it works

I'm referring to the recommends patches list in the System Patches package. I can't see anything there that should make any difference to dnsmasq but it's worth trying.

@froussy yeah as long as you connect in on something other than what is being changed you should be fine - if something goes wrong and your change isn't working you can always switch it back, etc.

Over the years I have myself shot myself in the foot a few times, its never fun.. ;)

Always give yourself a backup/backout plan.. When doing change on a cisco router or switch that could be problematic etc, always put in a reload command on a timer.. So worse case if goes wrong - it will reboot say in 10 minutes and your back to the start, if your change worked as you expected and all things working you can cancel the reload and save the config, etc.

I mean the switch/router rebooting might be a shitty outcome and maybe cause a service interruption, but that is far better than being in a broken config for a length of time until you can get to the site to fix, etc.

I mean your switch of interfaces should be no big deal, and work just fine, etc. "But" what if it doesn't and now you can't get in to fix it.. Better safe than sorry..

edit: I once getting cocky after so many eventless upgrades - had just clicked upgrade on a one of the old 2440 netgate boxes while home after work because figured hey nobody is there so they won't notice the few minutes of down time while it upgraded... Well it never came back and had to go into the office early to fix it. Only took a few minutes to restore and get the upgrade done when I was there.. And that was always my back up plan in case of disaster.. But this is why during covid and locked out of the office I didn't upgrade anything remotely ;) heheh

Better safe than sorry is good motto to live by ;)