Messages

Hi there, thanks, I think you may be looking for this fix which will also be in tomorrow's 15.7:

https://github.com/opnsense/core/commit/cc88a71d78524006f1596a7496881ede58869d73

Let me know whether that helps or not.

We've discussed this a couple more times internally and have come to the conclusion that this issue is not fixable, or at least not in the way it has been presented and discussed. While it's true that "sync" completely circumvents the issue, it seems that UFS has gotten a lot more error prone in FreeBSD 10 because of a yet to be discovered regression. We do not intend to switch our installs to "sync" or use journaling on top of soft updates.

FreeBSD's default for mounting is "noasync" which is a hybrid approach for writing data to disk: metadata is synchronously written, while file and directory data is held in RAM for a while, presenting the writer with a finished write even though the data is still pending a flush to the physical disk. While looking at pw and the supposed fsync() missing (fflush() really, because it doesn't use the open() function call), we've noticed that pw itself uses libc by default, so "fixing pw" does not look like a sensible route. What makes this worse now is that all other utilities using libc with the particular user/group function have this potential corruption issue too. And then, still, while digging deeper, we've found that other files do indeed corrupt as well, especially when pulling the plug on a booting system (e.g. /etc/shells), eventually rendering the installations impossible to be accessed even from a serial console.

So now, we've put in place a mechanism that ensures the system recovers the *important* files on boot so that a login capability is ensured and a fully operational system can also recover, but -- keeping the above it mind -- any unclean shutdown may lead to a file corruption at some point most likely rendering the system unable to recover or start due to missing configuration files or binaries. We've also made sure that the syncer kernel thread has lower timeouts (we went from 30 seconds previously to 5 seconds) for file and directory writes. The latter is a moving target as we monitor and tweak performance.

In all that we do, we try to avoid adding kernel/base patches or reboots or changing the behaviour away from FreeBSD defaults. If that's a problem, please speak up now. Otherwise, enjoy the upcoming 15.7. :)

Our patches for reference:

https://github.com/opnsense/core/commit/81edf54f2afb643800becd8ce231b4d891d97c77
https://github.com/opnsense/core/commit/cc7180222db0dd67fb4857fb43fa28cf4b5c27e9
https://github.com/opnsense/core/commit/7baccb7c42dd812963a931edb2483a25269eaf7a
https://github.com/opnsense/core/commit/f45171e7851b26acbd23b48c8c30d3f35b997e71
https://github.com/opnsense/core/commit/50613a493692ca6f43eb31e52403b1f97523ecb6

But we must hurry to get the fix to you. :)

Squid crashing or being unresponsive has been a known issue for FreeBSD 10.1: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=195802

The kernel patches have been applied for 15.7 and will be available tomorrow. Thanks for the report.

Thank you for your efforts! :)

Yes, you are running OpenSSL. There have been API bumps for both SSL flavours just before 15.1.12 came out that might be related to what you are seeing.

The GUI for firmware is a work in progress. From the command line, you can do:

# pkg info strongswan

This gives you a bunch of strongswan-related information, including the installed version.

It may also be related to the recent OpenSSL/LibreSSL updates. There are still images available for 15.1.11.1, which could help pin down the problem:

https://pkg.opnsense.org/releases/15.1.11.1/

This is the only problem report we've heard of so far. Are you sure there have been no changes in your network regarding routing or firewall rules?

Hi Jonathan,

glad to hear that. :) We were discussing more flexible ways of automatically generating rules as zones security profiles and widening the anti-lockout, but that's something the users will have to help us with and their use cases.

Generally, stuff defaults to "block all" most of the time and you should always be able to find the blocked traffic using the filter log filter (no word play intended). Do you have an idea why that didn't work for you?


Cheers,
Franco

It sounds like the is an IPv6 DNS server missing from your setup. The biggest question is: where do the host names for these IPv6 addresses come from?

/usr/sbin/arp uses gethostaddr() to resolve the names, the only difference here being that it works on IPv4, not IPv6. So either your local config knows the host names or they are resolved via a DNS server from your upstream DNS server (likely your provider).

/usr/sbin/ndp uses getnameinfo().

PHP also use gethostaddr(), so in theory all your host names should light up given the resolvers are set up correctly for IPv6.

From the root shell, do the following:

Please pick the right architecture and SSL flavour from the following links...

# fetch https://pkg.opnsense.org/snapshots/amd64/LibreSSL/strongswan-5.3.0_2.txz
# fetch https://pkg.opnsense.org/snapshots/amd64/OpenSSL/strongswan-5.3.0_2.txz
# fetch https://pkg.opnsense.org/snapshots/i386/LibreSSL/strongswan-5.3.0_2.txz
# fetch https://pkg.opnsense.org/snapshots/i386/OpenSSL/strongswan-5.3.0_2.txz

Afterwards:

# pkg add -f strongswan-5.3.0_2.txz
# pkg lock -y strongswan

This will prevent future firmware updates to the StrongSwan package. To unlock and go back to the latest version do this:

# pkg unlock -y strongswan
# pkg upgrade -y strongswan

Please let me know if that helps your case. :)

PS: You'll need to manually restart StrongSwan (or reboot) for the daemon to run the correct version (e.g. via the GUI)

Hi Rafal,

this most likely happened with 15.1.11.4 when StrongSwan got bumped from 5.3.0 to 5.3.2. I saw related commits in pfSense, e.g.

https://github.com/pfsense/pfsense/commit/29c9e14002b4a1566fa6afc6c4933b384b8e2242

I don't know the full scope of the problem yet, but I can, however, suggest a workaround based on reverting back to StrongSwan 5.3.0 in a little bit. Stay tuned.


Cheers,
Franco

Hi all,

I think we initially missed the opportunity to showcase the work we did before 15.1 went online on January 2nd. A lot has happened since then, but that's for another day. :)

Here is the list of notable changes that we feel made the project unique back then:

o PHP 5.6, Bootstrap GUI and Glyphicons conversion
o FreeBSD 10.0 as the base system
o Removed the quantum-entagled "admin" user, it was pointing to "root" causing inconsistencies
o Introduced code style based on PSR1/PSR2 as well as repository-wide whitespace cleanups
o 2 Clause BSD license approach with all code being available on GitHub
o SHA-512 for password hashes (previously was MD5)
o Packaged core.git to avoid clobbering the actual base system
o Rewrote tools.git from scratch
o Introduced ports.git and src.git
o Brought used parts of ports.git in sync with FreeBSD ports
o Live-mount mode of core.git for development
o Thorough refactoring of the bsdinstaller, pushed into ports.git for easy access
o Introduced Phalcon for upcoming MVC rewrite
o Rewrote parts of the captive portal in MVC
o Introduced pkgng as the core tool for firmware upgrades
o Disabled the legacy packaging system

Feel free to discuss this or ask questions.

Meanwhile, warm greetings to everyone from the initial OPNsense team: Ad, Franco & Jos

I've put in the code for removing the spurious gethostbyaddr() calls: https://github.com/opnsense/core/commit/38235b79b13ed6414584283f03a1c8e1767c25c0

I'm still a bit unsure if using arp to resolve IPv6 to IPv4-assigned hostnames is really the right thing to do. Adding an IPv6 mapping to /etc/hosts seems to resolve fine. Any thoughts from our IPv6 enthusiasts? :)

I've tested bhyve a couple of times and even managed to start an operational OPNsense inside it. Hopefully, we'll use it for testing/QA mid-term, but I can also see use cases for adding a GUI package for managing virtual instances / VMs in OPNsense itself.

FYI, there is a tool called iohyve https://github.com/pr1ntf/iohyve which wraps around bhyve (and ZFS) to make it simple to use...

SSH muss erst konfiguriert werden über die GUI, und auch Nutzer "root" und Password "opnsense" geht nur mit:

System: Settings: Admin Access

• Enable Secure Shell
  
• Enable root user login
  
• Enable password login