Messages

Hi D,

For best flexibility...


# cd
# pkg install git
# git clone https://github.com/opnsense/core
# cd core
# git checkout 5ad1fa6

And then, depending on your crypto:

# make upgrade FLAVOUR=LibreSSL

or (for default OpenSSL)

# make upgrade

You may have to follow instructions.

If the issue persists, try reloading the GUI using Option 11 from the root menu.

# clog /var/log/system.log

output would be nice, also things that pop into the crash reporter (System: Firmware: Reporter) that you can just send and let us know about this topic so we can trace it.

Try a different browser to confirm that it's not a client/caching issue.


Cheers,
Franco

Hi all,

We all know how i386 has had its best years behind and now there's a big decision for us up ahead.

As you all know HardenedBSD has implemented their ASLR[1] for OPNsense, which brings the possibility of modern security measures into our operating system core. But ASLR by itself is not effective without PIE[2].

PIE allows programs to run in arbitrary address layouts, which is what ASLR provides the framework for. ASLR has virtually no performance impact. For amd64 architectures, enabling PIE does not have any drawbacks as well. For i386, however, the performance impact for additional security is around 12% according to Shawn from HardenedBSD, based on how the architecture was built, so that's not something to work around.

i386 is being abandoned step by step by projects, but we have been discussing options on how to keep i386 a functional part of (our OPNsense) world for multiple years to come. Ideally we will want to deliver a homogenous environment where all components and flavours of packages and images come with the same extent of quality. For that we want to enable PIE for all users in upcoming major releases (likely somewhere in Q3 or Q4 of this year).

So the question is this:

Would you mind a 12% performance impact on your i386 hardware for the sake of security and modernisation?


Cheers,
Franco

--
[1] https://en.wikipedia.org/wiki/Address_space_layout_randomization
[2] https://en.wikipedia.org/wiki/Position-independent_code

So we're stuck in the middle here. There is a patch for StrongSwan that is either

(a) not going to be accepted upstream

(b) not going to be pushed upstream

There's security and maintenance implications we cannot be sure of when there is no peer review and alignment in terms of StrongSwan itself regarding the feature. It is a useful feature, but who takes responsibility? And when the firewall is free, who is going to step in and help bring more professional features in for the benefit of the community beyond the scope that we currently have? There are many more things to takle in all areas. :)

Wouldn't a dedicated IPSec box solve this issue?

Maybe the best option for all of FreeBSD (and likely beyond) would be:

(c) upstreaming the patch to StrongSwan

Well, you can try to restart the webgui from the console / ssh option 11. A dump of

# clog /var/log/system.log

would help.

You can also run

# opnsense-bootstrap

To reapply all packages in order to make sure that there were no install errors. The config settings will be retained...

Check for disk space exhaustion or a corrupted XML config (especially the GUI SSL certificate).

It's a database issue of sorts, you need to reedit and save the entries that say "AAA". After a unbound apply/restart it would work again.

We have a new patch tool for this, but it didn't make its way into 16.1.15, so either editing manually /usr/local/www/services_unbound_host_edit.php:113 or fetching like below should work:

# cd /usr/local/www
# fetch https://raw.githubusercontent.com/opnsense/core/217c0c9b35d/src/www/services_unbound_host_edit.php

Thanks for the feedback. It's still nowhere near as flexible as OpenBSD can be, but we're getting there step by step. :)

Would RFC 2136 be an option for your use case?

The following solves it, queued up for release in 16.1.16 next week.

https://github.com/opnsense/core/commit/217c0c9b35d3


Thanks,
Franco

Here's the current script and vars... https://github.com/opnsense/ports/blob/master/dns/bind910/files/named.in#L12-L27

Hi there,

Likely a bug. Manuel worked on this and does not have time nowadays, but I will look at it. :)

bind is also installed, you can use it like on FreeBSD... https://docs.freebsd.org/doc/6.1-RELEASE/usr/share/doc/handbook/network-bind9.html

Caution, old docs, it's since a port and RC vars/script names may differ.


Cheers,
Franco

I don't understand... How does it differ from what we have in 16.1.15 now?

http://imgur.com/kuZvGif

Is this what you're looking for? https://github.com/opnsense/core/issues/440

That means we'll have to start backing up the package database because we really can't trust UFS at all.

How would that look like?

Hi there,

So the story is that after adding OTP we actually realised that there was an automatic fallback to local auth. We didn't know about it before and it's really obscure although it can save a few people from locking themselves out.

https://github.com/opnsense/changelog/blob/master/doc/16.1.15#L13

;)


Cheers,
Franco

Have you tried pure NAT reflection?

https://doc.pfsense.org/index.php/Why_can't_I_access_forwarded_ports_on_my_WAN_IP_from_my_LAN/OPTx_networks

Whoops, nice catch! Fixed translation splatter for MVC components... Should be in 16.1.15 if review and testing is ok.

https://github.com/opnsense/core/commit/8a72c9704f7bb5