Messages

This is the latest one...

[74/74] Upgrading bind920 from 9.20.6 to 9.20.7...
[74/74] Extracting bind920-9.20.7: .......... done
pkg-static: Fail to rename /usr/local/bin/.pkgtemp.named-checkconf.L051g6LB8b9Y -> /usr/local/bin/named-checkconf:No such file or directory

After reboot:

eval: /usr/local/bin/named-checkconf: not found
/usr/local/etc/rc.d/named: ERROR: named-checkconf for /usr/local/etc/namedb/named.conf failed

Had to manually update the bind920 package after OPNsense upgrade finished.

When i block port 53 im loosing dns resolving.

That is super shocking... 😜

I'd say the proper place is /usr/local/opnsense/service/templates/OPNsense/WebGui/php.ini - followed by

Code Select Expand

configctl webgui restart

for changes to have effect.

Reading about the past CrowdSec issue, I know this is probably indicating some service is not cleanly stopping and is holding up the reboot. (Hence why some services stop but it never actually reboots.) With that said, I'm not sure how to identify which service is holding up the reboot.

You can identify those hanging processes with (serial) console. And the crowdsec issue is still there. What I do not understand is why the offending processes are not forcefully killed (SIGKILL) after some timeout period. This is also a long standing issue on OPNsense upgrades.

On another note, I never use the GUI for upgrades or reboots. Just way too unreliable, too many factors that can go wrong there.

Have seen this on multiple boxes. There's something fishy about the dependencies and/or the way pkg resolves them on upgrades.

The purpose is to block doh/dns to be accessed externally from any network on the inside. All resolves should go through internal DNS.

1/ You cannot block DoH (usually port 443) nor DoT (usually port 853) by redirecting port 53.
2/ You cannot redirect DoH/DoT in this way even by redirecting the proper ports - since it breaks the encryption (certificates).

Would suggest reviewing the following, e.g.:
https://developers.google.com/speed/public-dns/docs/dns-over-tls
https://developers.google.com/speed/public-dns/docs/doh

Sigh. So, what is the deal with this change? Regex no longer works at all? "Converting all of my whitelist entries from regex to the actual domain names" is not possible / practical in some use cases, that is the whole point of using the regex in the first place. Or, what's "actual domain name"? Examples - do these still work or not?

Code Select Expand

(.*)?(\.)?akamai.net
(.*)?(\.)?akamaiedge.net
(.*)?(\.)?edgekey.net
(.*)?(\.)?downloads.hpe.com
(.*)?(\.)?gslb-downloads-hpe-com.ext.hpe.com
(.*)?(\.)?gslb-downloads-hpe-com.glb1.hpe.com
(.*)?(\.)?gstatic.com
(.*)?(\.)?api2.branch.io
(.*)?(\.)?cdn.branch.io


I am aware that the point could be made, IPv4 is already one backup, since it's RFC1918...

Do you realize that ULA won't be used at all in dual-stack network?

Might be even the next reboot, not just update. So yes, using the tunables GUI is the way to override those values.

Well, this indeed has been broken upstream. Try with something like

Code Select Expand

hint.uart.0.at="isa"
hint.uart.1.at="isa"


You need a port forward to 127.0.0.1:9200 on the interface where the monitoring host is, not an allow rule on localhost.

Unsure why I would need any port forwarding here, I'm connecting directly to the OPNsense box on the correct port.

Because the packets are not arriving on localhost (loopback) interface at all, as you have observed.

However, when trying from 10.1.1.21, the telnet never connects. Am I missing something obvious here? The 10.1.1.0/24 subnet is in the LOCAL group.

P.S. Making ES listen on wildcard is... crazy. Would really suggest to undo that and do the simple port forward. This post has a proper example of such NAT rule to make services that listen only on loopback accessible over LAN to chosen hosts.  Use 10.1.1.21 for source and 9200 for destination and redirect target ports.

Well, I would suggest undoing your "fixes" and doing a fresh OPNsense re-install.

Another one for your noise...

https://github.com/opnsense/plugins/pull/4228

Well, they have some deal with the signature vendor about telemetry. However, it should be kept within reasonable limits.

Finally did a PR for the original issue which should significantly (~40x) reduce the logs for the stats at least.  https://github.com/opnsense/core/pull/7857

This is the offending line - https://github.com/opnsense/plugins/blob/5a02d3867d5e074837a1de8af7ffbaa46552a89f/security/etpro-telemetry/src/opnsense/scripts/etpro_telemetry/send_telemetry.py#L82

Feel free to file another ticket about it. Should be DEBUG at best. Noone cares about such nonsense.