Messages

Gibt es keinen echten Crash Report? Mir fehlt der Stack-Trace, wenn der Kernel nicht tut.

Don't use DEBUG=1 anymore, it crashes the FreeBSD kernel build. ;)

CSRF: the style enforcer we use works pretty well on PHP, but it introduced a JavaScript Syntax error. I did not expect this to break, but that's what devel is for some times. Oh, well, nobody expects the Spanish Inquisition. :)

As for crypto I haven't looked at this but I will try to see if I can reproduce when I'm back home.

SMTP Notifications: Gateway down messages, CARP (HA) messages, Config loading errors, some filter messages. Very disorderly and hard to trace to be honest.

Ein schöner Artikel. Erinnert ein wenig an systemd, einer für alle, alles im Eimer. ;)

Das FreeBSD Paket ist fix und fertig mit Binaries, Installationsaufwand praktisch null. Das soll nicht heißen, dass man es benutzen sollte, aber es ist da, wenn es sein muss. Auswahl ist gut. Und wenn es in FreeBSD ist, warum nicht aufnehmen bevor jemand zu sehr mit basteln beginnt an seiner OPNsense.

Zum Thema doppelte Verwaltung: Solange man sich auf Services Beschränkt (Ports auf TCP/UDP) muss man sich nicht um Unterscheidung von IPv4 oder IPv6 kümmern, es sei denn die Unterscheidung ist explizit gewünscht. Die bekannten IPs und Netzwerke können so oder so direkt vom Interface angewählt werden ohne die Addresse explizit kennen zu müssen, es ändert sich also im ersten Moment nicht viel. Natürlich gibt es IPv6 Feinheiten, die dann auftreten können, aber grundsätzlich hat man dann schon viel eingerichtet und zum Laufen gebracht. :)

Die Standardinstallation soll wieder kleiner werden. Mit Plugins lässt sich ab 16.1 alles nachladen was fehlt. Support gibt es wenn es ein offizielles Plugin ist natürlich auch.

Wir haben jemanden der es manuell baute und benutzt auf OPNsense. Mit 15.7.12 ist das brandneue FreeBSD Paket auch mit OPNsense bereitgestellt. Ich hoffe es gibt bald ein Tutorial zur Benutzung die dann als Grundlage für dein richtiges Plugin dienen kann. Es kommt also nicht in die Standardinstallation, aber kann genutzt werden wenn es denn so gewollt ist. :)

That's a little better, I see, but might still give you trouble on larger updates (normally the updates are applied except the base/kernel).

Our recommendations for the nano image are here: https://opnsense.org/users/get-started/#hardware-requirements

What do you mean by "crypto" status?

I tracked down the CSRF issue last night (it's only on opnsense-devel fortunately), can be fixed via:

# cd /usr/local/www/csrf
# fetch https://raw.githubusercontent.com/opnsense/core/master/src/www/csrf/csrf-magic.js

This is the likely cause for the diagnostics pages misbehaving.

Also not sure what you mean by SMTP... do you mean the notifications?

I'm going to push proper amendments for 15.7.12 (both release and devel) on Monday or Tuesday at the latest.

Yup, it is. :)

256 MB and IDS are really not meant to go together. The fact that it works is miracle. It also explains your low tmpfs capacity when suricata is running in the background. My advice: don't use Intrusion Detection or Proxy Server on the hardware, or replace it, or switch off those services when you upgrade (might be a tad quicker). We cannot afford to strip down OPNsense like other distributions, because it is one of ours strengths. If anything, others should step in and do a lightweight version of OPNsense if there is much demand.

Moving the pkg fetch location only shifts the problem, it doesn't solve it. Especially for nano images, space is always scarce and only RAM in newer devices offers enough space for future upgrades. The main issue is that FreeBSD and in turn OPNsense have outgrown certain older hardware.

The keys changed since OpenSSH 7.1 doesn't have support for SSHv1 anymore, so the keys were rotated by our scripts. This won't happen again any time soon though. :)

I only know of changes to the opnsense-devel package WRT firewall pages.

Reports are fine either here or GitHub, that's where others can pick them up as well. Keeping track of the forum isn't easy at times, but we can always pick up issues from here and move them to GitHub for traceability. Generally speaking, just let us know and keep prodding until good things happen. ;)

Running the beta/devel version shouldn't be hard or very much notable. Things tend to run smoothly apart from the few corners we're working on. Should you find something odd it's great to have a head start before the actual release of a feature (or regression). If you want to do more, join the GitHub discussions, skim the tickets, dump your ideas there or here in the forum. If you are a programmer, there may be a few tiny tickets that have the "help wanted" tag. But in any case testing is the most important thing for us.

Discussions and involving others, asking questions is a great way to come up with ideas, minor improvements that make a big difference or new features that help incorporate more use cases, which can pull in more interested parties and then go back to step one: discussions and start again. :)

I lied. I think I got all of them... https://github.com/opnsense/core/commit/27e5ef1c33ca81a10d5e5542033f1794882245ef

Cool, I'll correct the string you mentioned earlier along with a few other obvious candidates. Won't be all of the spots, but at least the most prominent will be named more accurately then. Thanks. :)