Messages

Do you use a subnet with dynamic prefix enabled?

It whipes all leases when a new wan event happens cause there could be a new prefix:

https://github.com/opnsense/core/blob/7bbd7a3c4a3d8a91a0c18b2ea203e00c9bc891c5/src/etc/inc/plugins.inc.d/kea.inc#L203

https://github.com/opnsense/core/blob/7bbd7a3c4a3d8a91a0c18b2ea203e00c9bc891c5/src/opnsense/scripts/kea/kea_prefix_renew.py#L46

If there is some issue here please open one in the core repository.

I let AI run over this, take with a grain of salt (could, would...)

Two potential issues in sys/dev/hyperv/vmbus/hyperv_mmu.c:

* In hv_vm_tlb_flush(), (end == 0 || ...) > max_gvas compares a Boolean against max_gvas, making the condition always false and preventing full TLB flushes.
* In hv_flush_tlb_others_ex(), fill_gva_list() receives end, start instead of start, end, potentially invalidating the wrong page.

Both could leave stale TLB entries and explain the crashes.

The above fix is not shipped yet, will probably be in 26.7.6 but unsure.

The earth is our single point of failure, when earth 2 please?

(This is only intended as a joke xD)

Without knowing more it kinda sounds like this we recently found.

It happens on mixed vti and policy based setups and is hard to replicate

https://github.com/opnsense/src/commit/e666a996d5325b10cafe21b67a97c4538deae139

The XMLRPC sync cannot delete the legacy rules if you empty them completely (it cannot sync empty nodes). So its better to delete them on both.

The OPNcentral sync on the other hand can delete empty nodes, cause the sync works a little differently.

I cleaned a lot of stuff up in the frr plugin. The change is planned for 26.7.7

I tested it all in my own test environment, but if somebody who also uses BGP/OSPF/OSPFv3 peering and has some basic development knowledge (aka how to build an opnsense plugin from master, deploy it, and report issues) it would be nice to get some feedback before pushing this out.

Please, test it if you can, its a lot of changes but less so feature wise, mostly corrections.

https://github.com/opnsense/plugins/blob/master/net/frr/pkg-descr

Check out the 2.0 changelog and the migration notes (there are a few migrations happening automatically).

Thank you for any help (and if not brace for impact on community at some point regardless :D)

TESTING STEPS (since I was PMed, I also post them here):

You can stay on the current community edition.

Just do the following in an ssh shell with root rights:

# opnsense-code plugins
# cd /usr/plugins/net/frr
# git checkout master
# make upgrade

Now your plugin will be upgraded to 2.0 and migrations will run. If any errors with the migrations happen please tell me. You most likely don't need a reboot, but for testing could be a good idea.

Rolling back to the normal version, better do a VM snapshot, or use the OPNsense ZFS snapshot.
Otherwise, you can use configuration history to roll back the config.xml and also just remove the os-frr-devel-2.0 plugin in the GUI in firmware plugins and then reinstall the previous version from there as well.

Thank you.

You can build the same kinda topology in dedicated tools for monitoring like CheckMK (also open source).

I did that before for customer networks, but of course its manual work even when using snmp, lldp and the like. No free lunch.

After quite a while of thinking I could come up with a clean prefix responder mode that fits into the current design of the proxy. So NPTv6 should be possible with it too now, tested it with wireguard ULAs.

https://github.com/Monviech/ndp-proxy-go/pull/11

EDIT: Available since Opnsense 26.7.6

If DNS cannot be inspected the next step up is SNI for (most) TLS traffic, which is still unencrypted most of the time (though encrypted SNI is slowly coming too).

Zenarmor might be able to do that style of blocking.

Its not really a beta test component as this page has been around for years, it was a firewall automation plugin page since 2021 or so.

Am einfachsten ist es auch hier die Point to Point session vor der OPNsense zu terminieren, wenn HA benötigt wird.

Vor allem rauchen dann auch keine Sessions ab wenn es schwenkt, da pfsync states auf echten interfaces liegen.

Das läuft bei mir seit Jahren stabil.

Point to point is halt grundsätzlich eher point to point und nicht point to multipoint... das bedeuted HA ist immer etwas feindlich in so Szenarios.

Ja das ist schon sehr viele Jahre bekannt.

Was ich Kunden mit so einem Setup empfehle ist mehrere Router die alle die PPPoE session terminieren, und die OPNsense dahinter. Durch eindeutiges Routing hat dann die OPNsense unique default routen pro Leitung.

Doppel NAT kann man verhindern indem man statisches routing verwendet und bei der Haupt OPNsense das Source NAT/Destination NAT ausmacht.

Beispiel Transitnetze
(macht NAT)                                           (Nur Router/Firewall)
PPPoE Router 1 --- 10.0.1.1/30 --- 10.0.1.2 OPNsense
PPPoE Router 2 --- 10.0.2.1/30 --- 10.0.2.2 OPNsense

No, the documentation is too new. It doesnt exist yet. But we fix that soon. So long you can look at the direct branch here:

https://github.com/opnsense/docs/blob/master/source/manual/how-tos/wireguard-client.rst

Sorry the normalization documentation was merged and updated a bit too early and reflects the upcoming version already. You can move before here in the git repository:

https://github.com/opnsense/docs/commit/79ca2c8b8d60fc82a5d9a76641d31dd836b08133

Since we don't have a versioned docs page, this can happen sometimes. The git repo can go back to earlier commits.