Messages

Kind of a stupid question but figured ask anyway.  I am assuming these patches should work on 21.1 as it is now?  I'm waiting for the issue to be completely figured out but wanted to make sure before trying to apply it.

Switched to the production branch and that indeed fixed the issues.  Thanks.

Just realized there is an r44 version showing available and maybe I didn't update all the way through to the latest.  I can try doing this later and report back.

It's on 21.1r1.

System > General Log:

2021-01-20T08:14:50   opnsense-devel[44539]   /status_services.php: The WAN_PPPOE IPv4 gateway address is invalid, skipping.   
2021-01-20T08:14:50   opnsense-devel[44539]   /status_services.php: Choose to bind WAN_PPPOE on Array since we could not find a proper match.

System > Gateways Log:
2021-01-19T16:46:41   dpinger[27392]   send_interval 1000ms loss_interval 2000ms time_period 60000ms report_interval 0ms data_len 0 alert_interval 1000ms latency_alarm 500ms loss_alarm 20% dest_addr 207.109.2.20 bind_addr 98.115.111.122 identifier "WAN_PPPOE "

This is after upgrading from 20.7.8 to 21.1r1.   Internet and everything else works fine but the dpinger service will not start and the dpinger service won't start.  The WAN_PPPOE gateway is also marked as offline.  I can reach the gateway from the router and a client.  I've tried setting far gateway, upstream gateway, and a monitor IP with no avail.  If it helps, I wasn't getting anything like this on the 20.1 and 20.7 series.  I know this is a beta and issues like this are expected so I'm fine with helping troubleshoot this or being patient.  Just wanted to report it.

It's possible the computer is trying to check something dns related that is being blocked by the backlists.  Have you checked to see if windows determines if you have internet access when the internet is not working?

Yes, this is the one.

https://github.com/opnsense/src/issues/70

20.7.3

This issue was fixed in one of the previous builds.

I don't think this is a ddos vulnerability.  I think this is rather something that is coming from one of the blocklist providers as I found this was due to the same line in the dnsbl.conf file.  I had this over the weekend and I was able to resolve it by SSHing into my system and removing the offending line manually.  I haven't had time to figure out where it came from but this fixed my issue.  Its most likely due to the fact that unbound can't parse the non standard characters in the line (the /).

Figured I'd ask this in here since I'm not sure if others have seen this too.  I'm noticing when I whitelist something or turn off the blacklist for troubleshooting, it takes a long time for the changes to kick in.  Anyone notice this too or know of a way to speed this up?  I wish there was a button in the UI or it would do this by default.

Just chiming in.  I'm having this issue as well. Found this:

https://forum.netgate.com/topic/142363/ipv6-broken-radvd-can-t-join-ipv6-allrouters-on-interface/137
https://github.com/pfsense/FreeBSD-ports/pull/773

@franco does this help narrow it down.

You'll also find this here:

https://downloadcenter.intel.com/download/17509/Intel-Network-Adapter-Gigabit-Base-Driver-for-FreeBSD-?wapkw=i350

I'm not sure the differences between the 2.5.x and the 7.x versions.  Posting this only as this driver seems to be in line with what is already there.

Thanks for posting the fix!  Just an FYI, it looks like snortrules-snapshot-29161.tar.gz also works.

Just reporting that I've installed the last test kernel and enabled IPS on my PPPoE connection with IGB drivers.  All appears to be good and haven't had issues over the weekend.