Menu

Show posts

This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.

Show posts Menu

Messages - Monviech (Cedrik)

#1
If it's about ACME issued certificates, e.g. with the os-acme-client plugin, it's best if you open an issue here so the Maintainer of the plugin can see it.

Right now it's unclear if the ACME client persists these certificates wrong to the trust store, or the trust store fails to parse them correctly.

https://github.com/opnsense/plugins/issues

It could also be a core issue here:

https://github.com/opnsense/core/blob/f95e81516ee0e2fb184f06bb7f858d3dd45da9cc/src/opnsense/mvc/app/library/OPNsense/Trust/Store.php#L417-L440

If ECDSA only has a Digital Signature, "cert_type" could stay empty I assume.

Elliptic Curve secp384r1 makes the certificate use an ECDSA key.

extractPurpose() logic expects Digital Signature plus either Key Encipherment or Key Agreement, so the ECDSA cert probably through without a cert_type.

You can try an issue here: https://github.com/opnsense/core/issues
#2
I wouldnt recommend using a syn proxy as it can silently break some services/websites from working correctly.
#3
Now that sounds more like it.

It means that for IPFW dummynet shaping it needs an additional tunable.

But that also means without that tunable, shaping via PF should also work (which is available in the new Rules, you can attach pipes via PF there so PF sends it to dummynet, IPFW is not needed then. But its still a bit wonky probably)
#4
26.7 Series / Re: New Source NAT page
August 19, 2026, 09:44:23 PM
Can you share what you have configured in /conf/config.xml (your config backup) for these Source NAT rules?

Also what is your NAT mode?
#5
Im sure you can get the setup working eventually.

Please don't post so much, it's a forum and not a chat.

We also have an IRC chat here:
https://libera.chat/
Channel: #opnsense

Just have to be a bit patient, most of the time somebody replies and helps.
#6
German - Deutsch / Re: Two Factor Authentication (2FA)
August 19, 2026, 07:58:48 PM
Das Problem ist das der Scope von sowas recht groß werden kann damit es sicher implementiert ist und dann auch noch hier durch geht:
https://docs.opnsense.org/security.html#framework-type-of-testing-lince

Für drive-by PR ist das nicht so gut geeignet. Lieber issue aufmachen und diskutieren.
#7
Yes there is a way, Migration Assistant in the Firewall menu.
#8
You seem to be using the old rules menu.

Try the new rules in version 26.7.x
#9
I ran this whole thread through Chatgpt and it says this (didnt fact check)

-----

FreeBSD actually documents this quite clearly.

A bridge does not need IP addresses to transparently forward traffic, and FreeBSD explicitly supports using a bridge as a traffic shaper with Dummynet. (FreeBSD Dokumentation)

The interesting part for your issue is if_bridge(4): bridged traffic can be filtered on the member interfaces or on the bridge itself, controlled by net.link.bridge.pfil_member and net.link.bridge.pfil_bridge. For Dummynet specifically, FreeBSD also documents net.link.bridge.ipfw as the Layer-2 filtering path and explicitly says it "needs to be enabled for dummynet(4) support." (FreeBSD Manpages)

FreeBSD if_bridge(4)
FreeBSD Handbook — Bridging

So I don't think Proxy ARP or VIPs are the solution here. If bridged packets bypass your shaper rules, the interesting question is which bridge filtering hook the packets and Dummynet rules are traversing. That's exactly what the FreeBSD bridge filtering knobs control.

https://man.freebsd.org/cgi/man.cgi?query=if_bridge&sektion=4

https://docs.freebsd.org/en/books/handbook/advanced-networking/#network-bridging
#10
Why do you need a bridge at all if you are routing in the end?

This is all going in circles.
#11
OPNsense has rule separators. You use categories for that. And then you can select the button "Show categories as folders" to show all rules with their Categories as separatos.
#12
Very cool, thank you.

All three neighboring cases:

VLAN over bridge with normal interface MAC works.
CARP directly on the bridge works.
CARP on VLAN over a normal epair works.
-> Only CARP on VLAN over bridge fails.

This is definitely freebsd bug territory now as Patrick also suggested:
https://bugs.freebsd.org/bugzilla/

If you have opened one you can also backlink it here:
https://github.com/opnsense/src/issues

Thank you for your help!
#13
Please prove it with jails:

https://github.com/opnsense/core/pull/10584#issuecomment-5025745485

Example in this comment. You can extend my baseline jail scripts, if you have a reproducible case please share the updated jail scripts.

Thank you.
#14
If you use one of these importers, this will happen:

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

Pfsense and OPNsense are too different than a few years ago. You better start new or you will always have a partially broken setup.
#15
Maybe it's time to move on to a supported setup and not an accidental side effect.

If it cannot be explained properly and everybody is confused occam's razor makes it look like this:
https://xkcd.com/1172/