Messages

Good morning, seems the update in my remote opnsense didn't complete properly as the status says
OPNsense 24.1.10_8-amd64
FreeBSD 14.1-RELEASE-p2
OpenSSL 3.0.14

The kernel however seems to be on 24.7 already
root@insharam:~ # uname -a
FreeBSD insharam 14.1-RELEASE-p2 FreeBSD 14.1-RELEASE-p2 stable/24.7-n267758-4ad7ad40bc77 SMP amd64

when I try to update it can't find the version on the mirror and I get a warning
pkg: Warning: Major OS version upgrade detected.  Running "pkg bootstrap -f" recommended
pkg: Repository OPNsense has a wrong packagesite, need to re-create database
pkg: Repository OPNsense cannot be opened. 'pkg update' required

I have tried a ppg update/pkg bootstrap and seeting the packagesite via ENV - no joy so far. Anything I could still try except for driving there and reinstall/update?

Update:
found this thread https://forum.opnsense.org/index.php?topic=27062.msg131362#msg131362
opnsense-update -pA 24.7 seemed to have done the trick

fixed it - the 0.0.0.0/0 routing was set in the wrong peer

I am running a rather complex setup over multiple sites and have a new requirement to use a remote gateway on a different side as gateway for a certain subnet on the local site. The connection is made via wireguard, which runs nicely, but apparently I got a routing issue I can't figure out.

I have tried to work with https://docs.opnsense.org/manual/how-tos/wireguard-selective-routing.html as a baseline.

For simplification reasons:

Site A (local) as 10.1.0.0/16, Site B (remote) as 10.2.0.0/16
A wireguard tunnel has been setup with 10.2.100.1 as remote ip and 10.2.100.2 as local address, I can ping and connect anything on 10.2.0.0/16 from the local network - so that is okay.


Now I want to redirect all traffic from 10.1.144.0/24 via the remote site and as per above mentioned how-to I have set up a ipv4 remote gw 10.2.100.1 on WG7 (which is the interface assigned to the wireguard tunnel and I have an interface VLAN144 which is for the local subnet to be routed. I have added a firewall rule to VLAN144 which basically says: any 2 any gw remotegateway

Now, what happens is: once that rule is in place the opnsense on site A reports back 'Destination host unreachable', so despite the gateway being reachable, the system doesn't route packets there.

Any idea what I am missing?

Ich nutze einen Telegrammbot, der aus dem LAN connectionprobleme mit der API (api.telegram.org) hat, vor der opnsense aber nicht (direkt an der Fritzbox).
Nutze ich den Proxy auf der OPNSense, dann funktioniert er ebenso ohne Probleme.

Da aus dem LAN aber genau nur die Standard LAN 2 any rule gesetzt ist verstehe ich das Verhalten nicht.

Alle anderen Webseitenaufrufe funktionieren problemlos *

Ich habe noch genau einen issue mit einem Netgearswitch wo ein Untermenü über HTTP auch nicht korrekt funktioniert, gehe ich aber über den Proxy schon, aber Netgear ist eh ein Thema für sich.

Da ich den Telegrambot vormals auch im Netz am Laufen hatte - hat da jemand eine Idee was für ein Setting da potentiell reinhaut?

NextDNS provides unique Links for the forwarder and a unique Hostname

ie:
v6 -> prefix::profileID, Hostname profileID.dns.nextdns.io
v4 -> one of the v4 dns adresses they use ->, Hostname profileID.dns.nextdns.io

So, when I do the workaround via DHCP only v6 can be kind of mapped to my ID (profileID), v4 can't be linked to the profile at all.

Thus, the setting would have to be done as in the attached image different per group of vlans.

Not a common problem, but I am using Unbound DNS in connection with NextDNS and I am using DNS over TLS.

The problem is, that as far as I understand, there is only one instance of Unbound I can use for a number of my VLANs - which works rather smoothly, but, as NextDNS allows different filtering profiles, I would like to create groups of VLANs per profile, for now I can only override DNS via DHCP and try to directly provide the NextDNS DNS Servers to the machine, which means losing functionality.

Ideally I could use instances of Unbound that would allow me a DNSoverTLS setting per group of VLAN of to differentiate that within the unbound instance itself.

Does anyone know whether that can be currently done?