Messages

Since I recently experienced the same issue, I just wanted to throw in my data points.  My situation is a bit different in that I haven't really changed my config since 17.x.  However, recently I decided to turn off suricata (for no reason other than it was causing my system to run about 7C higher on average).  For two hours it worked fine.  Then the WAN link started to go up and down.  I came across this post in the past but I didn't put the two together right away.  Instead, I called my ISP and swapped out my cable modem, which solved the issue for about 18 hours, then it started to flap again.  I eventually had to enable suricata again and it has been fine ever since.  so for me, if i disable suricata the WAN starts to act up.

Current version: OPNsense 22.1.10
Interfaces: Intel pro 1000
MAC Spoofing: YES
IDS: LAN
IPS: YES

by any chance, have you tried using SSL?  I too noticed the same thing and simply entering https solved the issue.

I am not sure if I am the only one encountering this issue, but off a fresh reboot the blacklist within unbound does not seem to automatically download the blocklist.  I have to go in manually and trigger a manual download each time.  Am I missing a step somewhere?

I am having some delays with blacklist within unbound and was hoping for some clarification.  When I select a new list, hitting save doesn't seem to pull an immediate download and update.  Do I also need to restart unbound?  What would trigger an immediate download?

In addition to what has already been stated, is the Deny PIA_Traffic to WAN really necessary?  Don't see that you have any logging enabled and that would be the same as default deny all traffic, no?  If you change the source to LAN Net instead of your alias does it work?

I'm not sure then.  I run the same set up except a few differences not worth mentioning.

Okay, it should be your LAN subnet, whatever it is.

Under Manual Outbound Nat Rules, the source should be the subnet, in this case 10.10.3.0/24.

Interface PIA_OVPN
Source 10.10.3.0/24

Then in your firewall rules, use PIA as the gateway under the LAN rule allowing traffic out.  In other words PIA_VPN_Traffic as the source, destination any, and set the gateway to use PIA.  This rule should be above the default allow all.

So I am not sure if it is related, but I was also having problems when rules were being reloaded every night via cron.  At first I thought it was the abuse.ch rulesets, so I loaded smaller groups of rulesets at a time, it would only fail on the ET rulesets.  So I am not sure if this an issue on ET's end but in the meantime I've just learned to live with it.  Sometimes it works some nights it doesn't.

You actually have to go through all the versions so 20.7.1 -> 20.7.2 -> 20.7.3.  20.7 has generally been buggy for me compared to previous upgrades which went much smoother.  I ended up having to do a clean install of 20.7, then restored the backup and went to 20.7.2, and this week 20.7.3.  I'm still having issues with suricata and the rules not updating on cron, but that's a different story.

That is pretty cool.  What kind of NIC chipset?

You're 100% right. 

If what dinguz doesn't work, write the nano version onto a USB drive.  Then run the installer off the USB from shell after it loads.  You can find more instructions below:

Should the installer user not work for any reason, log in as user "installer", select option 8 from the menu and type "opnsense-installer".

https://docs.opnsense.org/manual/install.html

*Edited user to installer

In the past, usually after an update, I have had this happen to me twice.  Usually a quick restore of the latest config and reboot cures the problem.  Another time I had to perform a clean install and then restore the backup config.  Usually after taking these steps, everything is good. 

When the clients lose their connection, can you go to services -> DHCPv4 -> log file and post it here?

Have you tried it without opendns?  Try just barebones config.