Messages

I was indeed wondering which mirror gets used with the default "(default)" setting. That's kind of obfuscated. 😅 But I eventually figured out that opnsense-update reads the "url" value from repos/OPNsense.conf, which does get set to CORE_PACKAGESITE at build time.

Until now, I didn't modify CORE_PACKAGESITE, hence I had to inject my mirror into config.xml.sample. Starting with 25.7.8 I will stop doing this since it's no longer necessary with the correct CORE_PACKAGESITE.

Modifying repositories/opnsense.xml isn't really necessary, correct. I just thought it would make sense to remove the amd64 mirrors while I'm at it.
Going forward, it might make sense to add an "architecture" property to each mirror in repositories/opnsense.xml. Mirrors could offer a single or multiple architectures. The GUI then could only display the mirrors which offer the system's architecture.

Cheers
Maurice

@franco

Looking better? Want to give it a try? Feedback welcome!

https://github.com/opnsense/core/compare/stable/25.7...maurice-w:opnsense-core:stable/25.7

If you use 2a02:898:331:1::/64 for the OPNsense LAN, you'll need a static route on the Proxmox host which routes this prefix to the OPNsense WAN address.

You added the route to vmbr1 (the LAN bridge). You need to add it to vmbr0 (the WAN bridge).

Hey Franco,

Nice!

I don't use maurice-w/opnsense-core for building OPNsense aarch64. When starting the build process, a script locally injects my fingerprints and custom mirror into opnsense/core and makes a plist-fix.

Your patch to opnsense-bootstrap might motivate me to change this. I'll look into it!

Cheers
Maurice

Der FQDN des SIP-Servers lässt sich bei vielen Providern nur über deren eigene DNS-Server auflösen, die OPNsense aber im Normalfall nicht verwendet.

Falls Du Unbound verwendest, dann kannst Du dort ein Query Forwarding für den SIP-FQDN auf einen DNS-Server deines Providers anlegen.

Grüße
Maurice

How Microsoft Windows is flooding the dnsmasq log

This only works for addresses which are on-link on vmbr0. This doesn't apply to the /64 used in the OPNsense LAN, hence Proxmox must explicitly route it to the OPNsense WAN address.

If you use 2a02:898:331:1::/64 for the OPNsense LAN, you'll need a static route on the Proxmox host which routes this prefix to the OPNsense WAN address.

Cheers
Maurice

@patient0 It seems you're correct, thanks for checking. If send host-name isn't specified in the config file, dhclient defaults to sending the system's hostname. Kind of unexpected / undocumented.

To not send a hostname, send host-name "" needs to be explicitly specified in the config file. In OPNsense, you can do this by enabling advanced mode and adding host-name "" to the 'Send Options' field.

Cheers
Maurice

You can create a gateway group which includes the WAN gateway and the WireGuard gateway, but NOT the WAN2 gateway.

Cheers
Maurice

No hostname should be sent if you don't specify one in the DHCP client settings.

Double check
- the generated config file (/var/etc/dhclient_{$interface}.conf) and
- a packet capture of the DHCP handshake.

Cheers
Maurice

Policy routing for traffic originating from OPNsense itself works (with an "out" rule). The issue is source address selection, which happens before policy routing kicks in:

- The IP address of your primary WAN interface gets selected as the source address (because WAN has the default route).
- The policy routing rule routes matching packets to the wg0 gateway.
- The wg peer discards these packets because their source address (your WAN address) isn't an 'allowed IP'.

Workaround: Add an outbound NAT rule to the WAN(!) interface:
- Destination address: The alias you created.
- Translation target: wg0 address

Cheers
Maurice

Grundsätzlich eine gute Idee. Das Memory-Widget bekommt den "belegten" RAM aber schon fertig berechnet von der API (/api/diagnostics/system/system_resources). Daher müsste man erstmal diese erweitern. Die gibt bisher nur total / used / arc aus.

Ich stimme dir zu, aber solche Änderungen sind leider ein ganz heikles Thema. Eine Flut von "The latest update eats all my RAM!!!"-Beiträgen wäre garantiert.

Persönlich würde ich sagen: So what. Aber ich bin ja nicht der, der den Backlash dann abbekommen würde, insofern halte ich mich da zurück.

Kannst Du einfach so anwenden, ja. Wird dann durch das nächste Update wieder überschrieben.

Das ist nur eine winzige Änderung:
https://github.com/maurice-w/opnsense-core/commit/a49dece

(opnsense-patch nutzt automatisch auch Forks.)

Es liegt aber nicht an mir zu entscheiden, ob man inaktive Pages als frei oder belegt betrachtet. Da kommt man ganz schnell in Grundsatzdiskussionen, ob z. B. großzügig dimensionierter Swap überhaupt noch zeitgemäß ist.

Außerdem würde dann bei allen Usern auf dem Dashboard plötzlich deutlich mehr belegter RAM angezeigt. Welche Diskussionen das auslöst kann man sich vorstellen.

Daher sehe ich von einem Pull Request erstmal ab.