Messages

[pfctl -vvs states | grep rlabel]

Without the -label package, reboot, patch steps Franco posted I get nothing from pfctl -vvs states | grep rlabel.


Once I follow the steps I get a lot of rlabel entries just as seen in your previous post.


The patch is fine. Afaik it's already in the latest BE and will come out in 26.7.3 for anyone who didn't see this thread.


I think you're expecting something different to happen...unsure what exactly.

Which mirror are you using ?

Try changing the mirror. If it fails again post the full health heck output here.

Likely a slow system where unbound takes a while to start and WireGuard depends on it because it is configured with fqdn instead of IP

Ok, this was a bit weird to have on hundreds of servers, so I'm happy to report you're wrong 🤓

Use "public key" = "m0tej5P6pYfBivkJc8yRV4KqQXmM81AChLlzlsOSjSs=" (this happens to be the public key for all NordVPN servers)

To find out the public key for the servers closest in the region the following command should be used:

Code Select Expand

curl -s "https://api.nordvpn.com/v1/servers/recommendations?&filters\[servers_technologies\]\[identifier\]=wireguard_udp&limit=1" | jq -r '.[]|.hostname, .station, (.locations|.[]|.country|.city.name), (.locations|.[]|.country|.name), (.technologies|.[].metadata|.[].value), .load'
With the wrong key the peer will show up in red on WireGuard Status and the logs will show no handshake.

Yeah then I'm not sure what's going on, sorry.

You couldn't possibly have the CA pk unless you were that CA...so I'm not sure what's triggering that error message about the CA key

A few comments on the latest posts.

The GH ticket is not about caching for RRsets.

The Rokus won't be silenced internally, that's not the goal. They can only be silenced by the devs - and clearly the every second telemetry is more important than anything for them.

If the Rokus work without sending logs then dropping the traffic is fine. Caching would only be useful if you still want that traffic to go through but instead of doing dns queries over the internet every second you'd get the replies from the cache and then unbound would refresh the dns information to serve from cache once the cached information is about to expire.

Also there's no need to have cached values for dropped traffic, it's not like those clients obey anything.

Shouldn't the cache TTL of any DNS record be set by the authoritative server for the zone in question?

This and similar threads don't exist because of what should or shouldn't, they do because of poor programming, or malicious sometimes, or simply idiotic if you want to get philosophical (how many queries each minute for the same servers is done by YouTube apps as round trips on the Internet ?).

For all of the reasons above you need these controls

The proper fix for this can be manually applied in the unbound or dnsmasq configuration file-until the functionality has been added to the GUI.

The ticket is already opened for a while...


https://github.com/opnsense/core/issues/10032

Class 3 is the intermediate, issuing CA

You're missing the root CA seen at depth:2

26.7.2 arrives next week.

If you have third party apps like AGH don't forget to retrieve the config files.

Otherwise simply install 26.7 and check for updates, install any plugins then import the config.xml.

I'll take a guess here that one is your default LAN and the other just another network on another port.

While the default lan allows you to go anywhere the additional ones will need specific firewall rules

The other weird part is the apparent lack of dns resolution/internet connectivity and the fact it is repeatable.

If you have IPv6 can you try turning it off before attempting to upgrade?

Also, just to be sure, keep a ping running to 1.1.1.1 while the upgrade happens

> WTF happened?

Most likely you didn't remove the microcode plugin before the major upgrade.

Remove it and try again.

If you don't have the plugin installed on 26.1 then post the health check

A health check on 26.1 may help explain what's going on