Recent posts

#1

German - Deutsch / Re: SSD Killer gesucht

Last post by HBerger - Today at 09:54:59 AM

Gibt es schon weitere Erkenntnisse?
Für mich höchstwahrscheinlich auch interessant!

nach 2 Jahren Dauerbetrieb hats mir die SSD nun auch gehimmelt. laut Smart tonnenweise moved blocks, und das zRoot war unwiederbringlich zerstört ...
Ich hab weder auf Netflow noch ZenArmor geachtet (glaub ZenArmor ist nicht an).
Allerdings hab ich ein:
"außer bei den allerkleinsten Heimnetzen mit wenig Traffic." :-)

Allerdings meine die allwissende KI, das es vielleicht nicht nur dran gelegen haben kann, das die SSD eine absolute billig Noname SSD aus China sei, sondern auch das die Temperaturen nicht optimal sein (permanent 68-78°) das muss ich auch mal verfolgen ...

#2

26.7 Series / deinstallation of Suricata

Last post by sternchen45 - Today at 09:40:50 AM

Hello,

i checked for the deinstallation of suricata and Google AI said, disable Intrusion Prevention on Services which i did.

I cannot seem to find a deinstall or minus button to remove suricata from the installed packages in 26.7_11.

Can you advise?

#3

German - Deutsch / Re: Umstieg auf Kea DHCP

Last post by meyergru - Today at 09:32:51 AM

https://github.com/meyergru/iscdhcp_to_kea

(wenn da nicht bereits ein CSV-Export für ISC DHCP existieren sollte)

#4

German - Deutsch / Re: Umstieg auf Kea DHCP

Last post by chemlud - Today at 08:43:29 AM

Moin,

und das ganze Gerödel muss man von HAND übertragen? Jede einzelne reservierte IP für MAC?

Mir ist eigentlich nicht langweilig...

#5

26.7 Series / Re: SOLVED: Transparent Filter...

Last post by lmoore - Today at 08:23:43 AM

There are however a few popular youtube videos pushing that scenario, which I disapprove ;) .

After reading your comment, I did a search for articles relating to the set up of an OPNsense Transparent Firewall.

Of the few articles I viewed, written and videos, they all mentioned disabling the anti-lockout rules for the LAN interface. None of them addressed the initial installation of OPNsense.

If one desires using LAN & WAN descriptions for the bridge members, there is no need to disable the anti-lockout rules. All that is needed is to spend a couple of minutes more, either during the installation phase or at the end if the system is left to its own decisions to assign the interface, and to use the console (video or serial) to re-assign the interfaces per the steps earlier in this thread, including assigning the management IP address on the nominated interface.

The OPNsense anti-lockout rules will be assigned to the interface above which had the IP address assigned to it, therefore there is no need to create new rules to access the management interface. Furthermore, should you decide to enable SSH in the Administration page, the automatically generated anti-lockout rules will be updated to include SSH.



At this point the only cleaning up is the two preinstalled LAN rules, which will become defunct with this configuration and can be deleted.

My preference is to use the LAN interface for management and assign interfaces for the bridge members and describe them as INGRESS & EGRESS.

#6

26.7 Series / Re: Confused by 26.7 upgrade

Last post by franco - Today at 07:35:18 AM

I'll make this short:

I looked for "harmless" and "easy" in the release notes, but I don't see any reference to firewall rules migration...

Code Select Expand

% git grep -i -e easy -e harmless community
community/15.1/15.1:interface.  Developers are invited to check out our easy-to-use build tools.
community/15.1/15.1.10:o installer: omit swap and add noatime to root partition in quick/easy install when available space is under 30GB, fixed faulty exit on importer cancel
community/15.1/15.1.2:continue with the Easy/Quick install.  This way makes sure all of the base
community/15.1/15.1.4:quick/easy install (or a custom one if you did that previously).
community/15.1/15.1.7.1:o bsdinstaller: work towards embedded installations, e.g. Quick/Easy disk selection
community/15.1/15.1.7.2:o configd: added a standard rc.d script for easy daemon control
community/15.7/15.7:import configuration tool coupled with a quick and easy installation can help
community/15.7/15.7.25:o ports: sqlite 3.10.0[10], easy-rsa 3.0.1[11], openssh 7.1p2[12]
community/15.7/15.7.25:[11] https://github.com/OpenVPN/easy-rsa/releases
community/16.1/16.1:No, we would not say it was easy getting here, but booting into 16.1
community/16.1/16.1:o backend: fix harmless error message caused by a sample template
community/16.1/16.1.3:o services: add background daemon to known services for easy reload
community/16.1/16.1.3:o services: add captive portal to known services for easy reload
community/16.7/16.7.r1:o Firewall rules category tags for easy filtering
community/18.1/18.1:o Easy-to-use update cache support for Linux and Windows in web proxy
community/19.1/19.1.r1:[5] https://hardenedbsd.org/content/easy-feature-comparison
community/21.1/21.1:open source dedication.  The last 6 years were not always easy, but we
community/26.1/26.1.4:for reporting issues and testing the fixes with us to allow for easy and fast
You are constructing a straw man out of your case and make it a point to elaborate on anything but the actual issue you've seen saying we should fix it but you don't know what it is because you expect someone else to figure it out. Someone else may figure it out, but likely not today or tomorrow. Not with this report if you want to call it that.

Nobody burdened you to update or migrate, but you're still here defending what you did, also ignoring https://forum.opnsense.org/index.php?topic=52859.msg274061#msg274061

And, to be blunt, on the microcode issue: you don't know what a microcode is but you install it causing all the problems in the first place? Or are you playing it safe by claiming you don't know which plugin carries microcode with "microcode" being in the name of the plugin you can search for in your installed plugins? This is not a serious proposition.

You're just looking for scapegoats. Please do it elsewhere, because people in this forum have helped you and they want to continue to help others. Not do whatever this is now. This is still friendly advice.


Cheers,
Franco

#7

German - Deutsch / Re: Umstieg auf Kea DHCP

Last post by spooner.arthur - Today at 05:51:14 AM

Ah, OK, ja sieht doch nicht so schlecht und unübersichtlich aus :-)

Das mit dem DNS ist bei mir etwas anders, wenn ich einen Domaincontroller habe, der von den unterschiedlichen VLans erreichbar sein soll.
Aber das ist natürlich nicht die regel.

OK, dann werde ich den KEA DHCP mal einrichten.

#8

26.7 Series / Re: Confused by 26.7 upgrade

Last post by defaultuserfoo - Today at 02:09:09 AM

> IIUC, someone created this thread when he found that he can not
  enable or disable firewall rules after an upgrade anymore, and was
  advised to install a plug-in to fix that.

Which is correct, but that's in the release notes. You don't need the
plugin to use and/or migrate the rules, but you need the plugin to
administrate them.

It's kinda in the release notes: 'Kinda' because it's very well
hidden.  I think it would be something that should be pointed out in
the 'Migration notes, known issues and limitations' section.

If someone doesn't read that section it's his fault.  I wouldn't blame
anyone for not reading the long list of items most or all of which
don't tell users anything.

> but I made the experience that the firewall rules didn't work after
  the migration and had all to be redone

Which is entirely different.  It may be because of FreeBSD 15.1 or
something else.  It looks like we don't know?

Different from what?

It's not because of FreeBSD.  It's because things work differently
with the new rules so that the old ones can not easily be converted
into new ones.  I guess that there may be configurations for which the
migration works: That's only when no conversion is needed.  That
doesn't mean it would work for everyone, and it means that a big fat
warning is needed.

I'm basically using a configuration that goes as described in this post:
https://forum.opnsense.org/index.php?topic=28447.msg138309#msg138309

If you want to use IPv6 and don't have a static prefix, what other
solution is there?  It's working great, and it doesn't migrate.

> Don't continue to pretend that it is an easy and harmless migration
  that wouldn't even require a big fat warning.  It is not.

I never pretended it was easy and harmless for you.  This is the core
of the issue.  It is your experience.  Not everyone else's.

I'm sure I'm not the only one to find out that the migration wasn't
easy and harmless.  Even if I'm the only one to experience that it
wasn't, it does warrant a big fat warning because there can always be
other users for which it won't be harmless and easy.

The core issue is that the migration was made to appear as being
harmless and easy and that the GUI suggested that we better do it
soon, and that we were not informed that we might have to redo our
firewalls and that we don't need to do the conversion anytime soon.

You right now still deny that it is not harmless and easy by
claiming that I'd be the only one for whom it wasn't.  Even if I am
the only one, it proves that your assumption that it is harmless and
easy is wrong.

> I wonder why that is.

Because you don't know what the problem is, but feel entitled to raise
your concern in advance?  If I know your exact problem I can probably
help or point to the right bits of documentation.

I'm not raising my concern in advance.

I did the migration because it was made to appear easy and harmless a
while after there was the entry for the new rules in the GUI,
suggesting that I better migrate my rules as long as it is
possible. Living in the past seldwhen is a good idea, meaning that
things like software keep moving on, and when you don't keep up you
can get so far behind that you eventually find that updating isn't
possible anymore. I've had that happen and it's a situation I really
don't want to be in again.

I'm raising my concern only after I know what the problem is.  The
problem is that the migration can easily go wrong, and my concern is
that there needs to be a big fat warning about it instead of making it
appear easy and harmless.

I don't know exactly in detail what causes the problem, just see
above.  I don't expect you/the developers to fix the cause(s) so that
the problem doesn't exist anymore.  The big fat warning would suffice,
so everyone who planning to do the migration can make backups and set
aside time to try it out and do whatever they deem necessary
beforehand.

The user's approach needs to be 'the migration may go wrong and is
not necessary' instead of 'the migration is harmless and easy and
should be done as soon as possible'.

> However, if you use the Community Edition, I believe you also bear
  some responsibility for regularly reading forum posts; otherwise,
  you might find yourself facing a problem eight months down the line
  that has already been thoroughly discussed and addressed. This
  applies equally to experienced forum members and OPNsense newcomers.

I did that until you drove me away.

Besides, users would have to not only read every post just in case
they might have a problem some months later but also remember it all.
I think that is demanded way too much.

It's like saying that every user of whatever software needs to read
everything about it in case he encounters a problem.

It doesn't work that way.  When I'm encountering a problem, I try to
solve it myself.  Asking questions anywhere is a last resort when
everything else fails.  The internet has mutated from a rather
friendly and helpful domain into the most hostile environment I
know. I don't want to ask questions because it almost always only
stirrs up useless and stupid discussions in which people try to insult
me, call me a troll and censor me.

Even if I wanted to read everything just to keep up to date, every day
would have to be at least a week long.

What if someone uses the business edition?

> Sometimes perhaps, but I'm surprised at the trivial questions that
  are being raised seeing the code that was touched and people not
  realising how many technical issues they would never notice because
  a) they don't have the setup or b) changes are handled in a way that
  few regressions arise to begin with.

And yet you expect these people to read every forum post to be
informed and to remember all the technical issues, regressions and
setups they never encounter or have.

Maybe if the 'Migration notes, known issues and limitations' section were
more exensive and there were only a link to the (rather irrelevant)
long list of items, then people wouldn't have so many trivial
questions.

> A great example is the Intel microcode plugin that if I had read the
  forum properly would have known I should have removed it before
  upgrading to 26.7.

> It's a very complex issue involving the microcode updates and the
  operating system that has been going on for years now -- and both
  are not under our immediate influence.  And here, also, it was
  clearly in the release notes:

https://github.com/opnsense/changelog/blob/b0be678d6235cb8da05446df7ea233c38cdcd0a7/community/26.7/26.7#L101

I guess you mean this:


"The CPU microcode early loading has been known to be flaky on some
setups.  A fix is in the FreeBSD 15.1 boot loader code, but can only
be reached by reinstall or manually updating the boot code of your
system after the upgrade succeeded.  If you want to be on the safe
side during the upgrade itself please remove the plugin before
proceeding."


I still don't know which plug-in this is referring to and how I would
update the boot code.

I can only guess that 'boot code' means the boot manager.  What
exactly am I supposed to do after reading this when I'm about to
update?  Why isn't the boot manager being updated automatically during
the update?

What I might do is figure out how one updates the boot manager of
FreeBSD.  But then, it would be pretty pointless because OPNSense
might be different from FreeBSD, so that might not work.  I wouldn't
take that chance.

I'm finding this also unclear.  It says I should manually update the
'boot code' (boot manager?) *after* updating.  That doesn't make sense
because if this goes wrong, booting wouldn't be possible.  So
obviously, I would need to update the 'boot code' before updating.

So maybe I better remove a plug-in first.  But which one?

Trivial questions?  Maybe, maybe not.  It's certainly not trivial when
I update and the router doesn't boot anymore.

The update shouldn't even start before that issue is somehow resolved
first.  Or perhaps I'm understanding this wrong and nothing can go
wrong when I update because the information is entirely unclear?

Why are the release notes not starting with the important section?

#9

26.7 Series / Traffic through VIP is roughly...

Last post by dispo2 - Today at 12:03:35 AM

I have two opnsense (26.7.3_8) running on different tin as a HA pair (active / standby)

I have a 500/50 Mbit internet connection and I have noticed (via speedtest.net) that my test results when using the real IP address as gateway are full 500Mbit but when I use the VIP as gateway the test speed max'es out at roughly half that.

I am trying to understand why as I did not think running a VIP / running traffic through a VIP added any major layer of additional processing.

tl;dr

These are proxmox hosted VM's with all of the recommendations (that I can find) enabled, cpu=host, hardware offloads disabled, hw.ibrs_disable=1, vm.pmap.pti=0, 8Gb RAM.

Hardware is quadcore Intel(R) Celeron(R) J6412 @ 2.00GHz and quadcore Intel(R) Pentium(R) N6415 @ 1.20GHz
Network is 4xIntel i226-V 2.5GbE, interfaces are configured as virtIO

LAN and WAN interfaces are their own NIC, not bridges

I have a virtual IP configured on the LAN via CARP, this is used for the gateway address in DHCP for seemless failover for LAN devices.
I have a virtual IP configured on the WAN for outbound NAT

These were originally 2 vCPU running the default v86-64-v2-aes profile with the default cpuunits. I have changed these to 3 vCPU type host with cpuunits=2048. This has helped a bit but has not significantly increased throughput through the VIP.

Using the real IP as the gateway address for a LAN device gets full internet speed so the hardware is obviously capable of it.
I cannot understand why, when using the VIP as gateway address, I get roughly half that.

When running the speed tests with the real ip of the active opnsense as gateway I can see traffic on the active firewall (as expected) and no traffic on the standby firewall (as expected).
Changing the gateway to the standby firewall reverses which firewall shows traffic (as expected).
Changing the gateway to the VIP shows the traffic via the active (CARP master) firewall (as expected).

In the above changes the only difference is the target gateway IP on the LAN side, all required NAT (at the WAN) is the same, all required firewall rule matching is the same, all hardware abilities and settings are the same.

So I cannot understand why the VIP is a bottleneck. Increasing cpu helps which implies an additional overhead for the VIP path but never solves it.

Any suggestions / ideas / tuneables I have missed ?

#10

Tutorials and FAQs / Re: How I updated my I226-V NV...

Last post by Lucid1010 - September 09, 2026, 10:30:22 PM

👍