OPNsense Forum
Archive => 21.7 Legacy Series => Topic started by: 134 on July 14, 2021, 06:31:49 pm
-
I'm currently using this feature in Opnsense (and previously with pfSense) to achieve split-horizon DNS with Unbound. It just came to my attention that 21.7 onward will no longer support it. May I ask why? I'm afraid this would be the deal breaker for me and some other users.
-
You can still use the config directory mentioned in the release notes. It's just removed from the UI. If you absolutely must use this feature, you probably know how to use ssh?
-
I can. But this would defeat the goal of using single configuration file to restore everything. In my opinion it should be moved to Advanced section rather than removing entirely.
-
Open a feature request in GitHub about the config lines, I can add the to misc submenu
-
Hi I am also wondering about this. Im not clued up to what has happened so am hoping someone can explain to me. Sorry I just dont know much about why it was removed and how to make the changes going forward without it that it all. Im happy to change if there is an easy method to follow that performs the same thing.
"Does anyone know why this has been removed. Im sad it has been removed because I used that page when setting up unbound. Will it still be easy to set the options that were on that page for me? I ask out of ignorance as I dont know why it was removed or how to configure the same options going forward. Im hoping it will be easy."
P
-
1. Ever since the OpenVPN custom options privilege escalation debacle in 2019 that affected *sense and prior widespread use of "just let us have custom configuration fields for all services" we decided to remove these ticking time bombs proactively and block their inclusion... slowly but steadily.
https://github.com/opnsense/changelog/blob/17ab9aee2c11fcaf811245b0b9a5e23a7c48a34f/community/19.1/19.1.8#L36
2. From a product perspective advanced users will add their custom glue and deprive meaningful use cases from the not so advanced users. It's better to work together and find GUI-driven solutions to problems everybody has.
3. For anyone saying "The GUI can't do this but when I edit the config file it gets overwritten" we usually advise to avoid using the GUI (core or plugin) and just use the service like anyone would on FreeBSD. Most decline, hence (2) is better in the long run anyway.
4. For everyone else and our plugin infrastructure pluggable services are the greatest thing we could possibly offer. Custom blob in the config.xml has no meaning, no structure and nobody wants to write a plugin for that, but imagine you can build (your private if you insist) plugin to do your current tasks more effectively and transparently. Hell, you can even write a plugin that retains custom options if that's the sort of thing that solves all issues.. at least locally.
5. For Unbound in particular only a handful of people improved the code we have over the last 6 years. It sort of goes back to problem (2) and how improvements have been lacking for having custom options that squelch most valuable feedback.
6. Most of what I just said has been said countless times before over the years and most recently we removed Dnsmasq custom options and also put Unbound custom options on the roadmap and the 21.1 release notes. If you don't take this seriously I'm not sure how we can be of help anymore than we've done.
https://github.com/opnsense/changelog/blob/17ab9aee2c11fcaf811245b0b9a5e23a7c48a34f/community/21.1/21.1#L24-L26
Cheers,
Franco
-
Quick question on this. If I restore a full backup config from OPNsense 21.1 and I'm using Unbound Advanced options for DoT, will these import to a 21.7 install?
-
We had a threat on the DoH option in the first half of Q1 2021. It never happend, unfortunately. I will not update to 21.7 if it breaks DoH in unbound....
-
Ticket for missing options is still open and will be done come 21.7. Nobody is being forced to upgrade and I think that's common knowledge...
https://github.com/opnsense/core/issues/4327
If there is something missing let me know.
Obviously custom options can't be migrated to any meaningful model which is part of the original problem.
Cheers,
Franco
-
4. For everyone else and our plugin infrastructure pluggable services are the greatest thing we could possibly offer. Custom blob in the config.xml has no meaning, no structure and nobody wants to write a plugin for that, but imagine you can build (your private if you insist) plugin to do your current tasks more effectively and transparently. Hell, you can even write a plugin that retains custom options if that's the sort of thing that solves all issues.. at least locally.
If someone is interested, I can add such a plugin to my community repo, this is really easy
-
We had a threat on the DoH option in the first half of Q1 2021. It never happend, unfortunately. I will not update to 21.7 if it breaks DoH in unbound....
You mean DoT? Yes, there is no grid for adding cert checks, to me, personally, I'd just allow a hash sign in the validation and dont migrate to grid. Franco, what do you think?
-
Yes, there is no grid for adding cert checks, to me, personally, I'd just allow a hash sign in the validation and dont migrate to grid. Franco, what do you think?
This sounds like a great solution and would cover my use case (and I suspect most others). It's the only reason I can't use the built-in DoT function in OPNsense. We aren't getting the full benefit by just forwarding queries to ipaddress@853. Using the additional validation that the answers coming back are actually coming from our chosen DoT provider is worth it, IMHO. That's why I continue to use a custom config just for basic DoT forwarding. FWIW, pfSense implemented something similar in the General Settings if you specify the IP and domain name of the DNS entries, and check the box to "enable forwarding mode" and "encrypt DNS outbound over TLS" it automatically converts those entries to IP@PORT#provider.name in the running unbound config.
Also a side note, I installed 21.7RC2 on a VM and it's quite easy to just create a new .conf with my same custom options from the Unbound config in 21.1. So if this isn't added to the GUI it isn't the end of the world, I'll even post a quick guide in the HOWTO section here. Just trying to get an idea if the .conf is the only available option or if there's a plan to add IP@PORT#provider.name in the DOT syntax.
It's good to know about a migration plan. For people like me that rely on DoT, I'll need to do some additional work to replicate the existing functionality from 21.1 that I am relying on.
-
This is worth nothing so don't waste time reading it.
I'm not interesting in protecting the incompetent from themselves by concealing functionality. I have screwed my self in the router department many times over the years; it's how I learned. What I am interested in is a highly configurable router, which is why my WRT54G was my last off-the-shelf router.
1) It's not as if someone can type gibberish into the custom options field and hit save and their internet stops working. They're going to have to research actual options and enter something correctly formatted to have any effect. That's a far greater barrier to damage than having check boxes and drop down menus that can be scrambled like a Rubik's Cube.
2) They had to elect to use Unbound in the first place. If they break it, they can fix it or switch back on the default resolver.
3) There's already an marvelous undo button in the form of the System > Configuration > History page which lets one very effectively roll back the clock.
A GUI enhances the accessibility and usability of the underlying services; where does the mandate to curtail and conceal functionality come from?
Given these points, I find the given reason of trying to protect the incapable from themselves to be irrational.
edit: I forgot about reading this shit two weeks ago and hit the upgrade button. 2 seconds later I remembered. Now I wish I could set something on fire. You just culled functionality in the name of user friendliness. FUCK. THAT. fuckyoufuckyourmom.
-
Hi again all,
@franco thank you for your detailed explanation for why this feature is being removed. Makes sense to me :) I am happy to roll with the change however I also think I misunderstood what was changing exactly.
From the changelog you posted on the announcement post you wrote:
"Unbound advanced configuration has been removed. Local override directory /usr/local/etc/unbound.opnsense.d exists."
From this I took this to mean the page in "Services - Unbound DNS - Advanced" is being removed. However in reading the above comments I believe that the only thing being removed is actually "Services - Unbound DNS - general - Custom options" which is quite different.
In fact this section does not even affect me which if is the case is quite a different section being removed than what I took the announcement to mean. If thats the case, sorry for the misunderstanding :)
P
-
We had a threat on the DoH option in the first half of Q1 2021. It never happend, unfortunately. I will not update to 21.7 if it breaks DoH in unbound....
You mean DoT? Yes, there is no grid for adding cert checks, to me, personally, I'd just allow a hash sign in the validation and dont migrate to grid. Franco, what do you think?
Yes, I mean DNS-over-TLS. DNS-over-HTTPS is malicous. :-)
https://forum.opnsense.org/index.php?topic=21153.msg98892#msg98892
We started early (January!), could we please have the necessary check boxes in the GUI, please... ;-)
-
From the changelog you posted on the announcement post you wrote:
"Unbound advanced configuration has been removed. Local override directory /usr/local/etc/unbound.opnsense.d exists."
From this I took this to mean the page in "Services - Unbound DNS - Advanced" is being removed. However in reading the above comments I believe that the only thing being removed is actually "Services - Unbound DNS - general - Custom options" which is quite different.
Oh, I was also under the impressions that the whole section of Services/Unbound DNS/Advanced is being removed... Thanks for the clarification :D
I think this should be changed in the OPNsense Roadmap, from "advanced" to "custom"...
-
Would be very nice to get some offical ffedback before the relase of 21.7
Quite painful to see that nothing happend since January.
-
https://forum.opnsense.org/index.php?topic=23941.0
-
> Oh, I was also under the impressions that the whole section of Services/Unbound DNS/Advanced is being removed...
I can see some of the confusion surrounding the loose terminology in day to day speak and similar names in the GUI. I adjusted the release announcement accordingly:
https://github.com/opnsense/changelog/commit/5d0f92d7e58e
> Quite painful to see that nothing happend since January.
Why does it matter when things are worked on when eventually they will be there and working ok? 21.1.9 is still around the corner giving us an opportunity to release enhanced support in 21.1.9.
In general, the best change we get is the one that is coming since we got no other contribution since then. It's not the end of the world as we know it. :)
FWIW, I pushed all your requirements from January into the ticket mentioned earlier so nothing was lost.
> Given these points, I find the given reason of trying to protect the incapable from themselves to be irrational.
I don't follow here, sorry. Can you try to explain this for me?
Cheers,
Franco
-
Thanks! From my perspective all makes perfect sense now and there is no real problem :)
Stay safe all!
P
-
https://forum.opnsense.org/index.php?topic=23941.0
Many, many thanks! I guess no problem to use on LibreSSL, as no crypto involved, or? :-)
> Oh, I was also under the impressions that the whole section of Services/Unbound DNS/Advanced is being > Quite painful to see that nothing happend since January.
Why does it matter when things are worked on when eventually they will be there and working ok? 21.1.9 is still around the corner giving us an opportunity to release enhanced support in 21.1.9.
Many thanks for clarification, I stay tuned and can't wait to see what's arround the corner :-D
Will it be necessary to remove all custom entries to unbound in the GUI before updating to 21.1.9? Or will it automagically fill the GUI with the data from the custom field?
-
Work has been concluded and DoT now is a grid view with room for individual on/off toggle, server address, port (optional) and hostname verification (optional). Strict Q-NAME is also available in the advanced settings.
I'll have a single patch backport for testing ready tomorrow.
Cheers,
Franco
-
Thank you Franco! This + the new ZFS installer make 21.7 a really nice release!
-
Thanks, I hope so too. :)
I am having a little difficulty with the backport of the new DoT grid page... A larger number of changes in the Unbound area need to be cut from the backport but I hope to be done later today.
Cheers,
Franco
-
Sorry, no, I'm unable to pull this over in one separate patch as it amounts to pulling in almost everything in the development branch regarding Unbound. The best approach for testers would be:
(switch to development release in firmware settings, check for updates and update)
(from the console)
# opnsense-code core
# cd /usr/core
# git checkout master
# make upgrade
Of course the development release shipped with 21.1.9 will have the changes included and the console upgrade is not required.
Cheers,
Franco
-
Sorry, no, I'm unable to pull this over in one separate patch as it amounts to pulling in almost everything in the development branch regarding Unbound. The best approach for testers would be:
(switch to development release in firmware settings, check for updates and update)
(from the console)
# opnsense-code core
# cd /usr/core
# git checkout master
# make upgrade
Of course the development release shipped with 21.1.9 will have the changes included and the console upgrade is not required.
Cheers,
Franco
Hello again!
In 21.1.9
https://forum.opnsense.org/index.php?topic=24089
I don't find anything related to unbound?!?
What is state of the union on this?
-
Of course the development release shipped with 21.1.9 will have the changes included and the console upgrade is not required.
-
Quote from: franco on July 15, 2021, 08:03:06 pm
> Oh, I was also under the impressions that the whole section of Services/Unbound DNS/Advanced is being > Quite painful to see that nothing happend since January.
Why does it matter when things are worked on when eventually they will be there and working ok? 21.1.9 is still around the corner giving us an opportunity to release enhanced support in 21.1.9.
-----
Hmmm, but 21.7 tomorrow is going to remove the custom options?
-
I repeat: switch to development, use the new code, do the upgrade, switch back to community.
(I don't want to force hundreds of lines into an EoL release for maximum convenience.)
-
Sorry for the noob question but trying to get ahead of the eventual upgrade to 21.7, but currently my Unbound has the following in custom:
server:
do-not-query-localhost: no
forward-zone:
name: "."
forward-addr: ::1@5353
forward-addr: 127.0.0.1@5353
It's forwarding to the DNSCrypt-Proxy service.
Will I be able to do this with 21.7 and the new standard menu? Currently still on 21.1.8 as I am not on-site to attempt the upgrade to 21.1.9
-
I repeat: switch to development, use the new code, do the upgrade, switch back to community.
(I don't want to force hundreds of lines into an EoL release for maximum convenience.)
OK, switched to DEVELOPMENT in the GUI and had a look for updates:
***GOT REQUEST TO CHECK FOR UPDATES***
Fetching changelog information, please wait... done
Updating OPNsense repository catalogue...
Fetching meta.conf: . done
Fetching packagesite.txz: .......... done
Processing entries: .......... done
OPNsense repository update completed. 681 packages processed.
All repositories are up to date.
Checking integrity... done (0 conflicting)
Your packages are up to date.
Checking for upgrades (29 candidates): .......... done
Processing candidates (29 candidates): .......... done
The following 29 package(s) will be affected (of 0 checked):
Installed packages to be UPGRADED:
ca_root_nss: 3.63 -> 3.68
curl: 7.77.0 -> 7.78.0
filterlog: 0.4 -> 0.4_2
nspr: 4.31 -> 4.32
nss: 3.67 -> 3.68
opnsense: 21.1.8_1 -> 21.1.9
opnsense-installer: 0.10 -> 21.7
php74: 7.4.20 -> 7.4.21
php74-ctype: 7.4.20 -> 7.4.21
php74-curl: 7.4.20 -> 7.4.21
php74-dom: 7.4.20 -> 7.4.21
php74-filter: 7.4.20 -> 7.4.21
php74-gettext: 7.4.20 -> 7.4.21
php74-json: 7.4.20 -> 7.4.21
php74-ldap: 7.4.20 -> 7.4.21
php74-mbstring: 7.4.20 -> 7.4.21
php74-openssl: 7.4.20 -> 7.4.21
php74-pdo: 7.4.20 -> 7.4.21
php74-session: 7.4.20 -> 7.4.21
php74-simplexml: 7.4.20 -> 7.4.21
php74-sockets: 7.4.20 -> 7.4.21
php74-sqlite3: 7.4.20 -> 7.4.21
php74-xml: 7.4.20 -> 7.4.21
php74-zlib: 7.4.20 -> 7.4.21
py37-cffi: 1.14.5 -> 1.14.6
py37-sqlite3: 3.7.10_7 -> 3.7.11_7
python37: 3.7.10_1 -> 3.7.11
syslog-ng: 3.32.1 -> 3.33.2
Installed packages to be REINSTALLED:
monit-5.28.0 (options changed)
Number of packages to be upgraded: 28
Number of packages to be reinstalled: 1
31 MiB to be downloaded.
pkg: No packages available to install matching 'opnsense-devel' have been found in the repositories
***DONE***
Problem with LibreSSL flavor?
-
My bad, let me fix that.
-
It's there now.
Cheers,
Franco
-
Looks good now!
***GOT REQUEST TO UPDATE***
Updating OPNsense repository catalogue...
OPNsense repository is up to date.
All repositories are up to date.
Updating OPNsense repository catalogue...
OPNsense repository is up to date.
All repositories are up to date.
Checking for upgrades (29 candidates): .......... done
Processing candidates (29 candidates): .......... done
The following 29 package(s) will be affected (of 0 checked):
Installed packages to be UPGRADED:
ca_root_nss: 3.63 -> 3.68
curl: 7.77.0 -> 7.78.0
filterlog: 0.4 -> 0.4_2
nspr: 4.31 -> 4.32
nss: 3.67 -> 3.68
opnsense: 21.1.8_1 -> 21.1.9
opnsense-installer: 0.10 -> 21.7
php74: 7.4.20 -> 7.4.21
php74-ctype: 7.4.20 -> 7.4.21
php74-curl: 7.4.20 -> 7.4.21
php74-dom: 7.4.20 -> 7.4.21
php74-filter: 7.4.20 -> 7.4.21
php74-gettext: 7.4.20 -> 7.4.21
php74-json: 7.4.20 -> 7.4.21
php74-ldap: 7.4.20 -> 7.4.21
php74-mbstring: 7.4.20 -> 7.4.21
php74-openssl: 7.4.20 -> 7.4.21
php74-pdo: 7.4.20 -> 7.4.21
php74-session: 7.4.20 -> 7.4.21
php74-simplexml: 7.4.20 -> 7.4.21
php74-sockets: 7.4.20 -> 7.4.21
php74-sqlite3: 7.4.20 -> 7.4.21
php74-xml: 7.4.20 -> 7.4.21
php74-zlib: 7.4.20 -> 7.4.21
py37-cffi: 1.14.5 -> 1.14.6
py37-sqlite3: 3.7.10_7 -> 3.7.11_7
python37: 3.7.10_1 -> 3.7.11
syslog-ng: 3.32.1 -> 3.33.2
Installed packages to be REINSTALLED:
monit-5.28.0 (options changed)
Number of packages to be upgraded: 28
Number of packages to be reinstalled: 1
31 MiB to be downloaded.
[1/29] Fetching syslog-ng-3.33.2.txz: .......... done
[2/29] Fetching python37-3.7.11.txz: .......... done
[3/29] Fetching py37-sqlite3-3.7.11_7.txz: .... done
[4/29] Fetching py37-cffi-1.14.6.txz: .......... done
[5/29] Fetching php74-zlib-7.4.21.txz: ... done
[6/29] Fetching php74-xml-7.4.21.txz: ... done
[7/29] Fetching php74-sqlite3-7.4.21.txz: ... done
[8/29] Fetching php74-sockets-7.4.21.txz: ..... done
[9/29] Fetching php74-simplexml-7.4.21.txz: ... done
[10/29] Fetching php74-session-7.4.21.txz: ..... done
[11/29] Fetching php74-pdo-7.4.21.txz: ...... done
[12/29] Fetching php74-openssl-7.4.21.txz: ........ done
[13/29] Fetching php74-mbstring-7.4.21.txz: .......... done
[14/29] Fetching php74-ldap-7.4.21.txz: .... done
[15/29] Fetching php74-json-7.4.21.txz: ... done
[16/29] Fetching php74-gettext-7.4.21.txz: . done
[17/29] Fetching php74-filter-7.4.21.txz: ... done
[18/29] Fetching php74-dom-7.4.21.txz: ....... done
[19/29] Fetching php74-curl-7.4.21.txz: .... done
[20/29] Fetching php74-ctype-7.4.21.txz: . done
[21/29] Fetching php74-7.4.21.txz: .......... done
[22/29] Fetching opnsense-installer-21.7.txz: ... done
[23/29] Fetching opnsense-21.1.9.txz: .......... done
[24/29] Fetching nss-3.68.txz: .......... done
[25/29] Fetching nspr-4.32.txz: .......... done
[26/29] Fetching monit-5.28.0.txz: .......... done
[27/29] Fetching filterlog-0.4_2.txz: ...... done
[28/29] Fetching curl-7.78.0.txz: .......... done
[29/29] Fetching ca_root_nss-3.68.txz: .......... done
Checking integrity... done (0 conflicting)
[1/29] Upgrading python37 from 3.7.10_1 to 3.7.11...
[1/29] Extracting python37-3.7.11: .......... done
[2/29] Upgrading py37-cffi from 1.14.5 to 1.14.6...
[2/29] Extracting py37-cffi-1.14.6: .......... done
[3/29] Upgrading php74 from 7.4.20 to 7.4.21...
[3/29] Extracting php74-7.4.21: .......... done
[4/29] Upgrading nspr from 4.31 to 4.32...
[4/29] Extracting nspr-4.32: .......... done
[5/29] Upgrading ca_root_nss from 3.63 to 3.68...
[5/29] Extracting ca_root_nss-3.68: ...... done
[6/29] Upgrading php74-session from 7.4.20 to 7.4.21...
[6/29] Extracting php74-session-7.4.21: .......... done
[7/29] Upgrading php74-pdo from 7.4.20 to 7.4.21...
[7/29] Extracting php74-pdo-7.4.21: .......... done
[8/29] Upgrading php74-mbstring from 7.4.20 to 7.4.21...
[8/29] Extracting php74-mbstring-7.4.21: .......... done
[9/29] Upgrading php74-json from 7.4.20 to 7.4.21...
[9/29] Extracting php74-json-7.4.21: .......... done
[10/29] Upgrading nss from 3.67 to 3.68...
[10/29] Extracting nss-3.68: .......... done
[11/29] Upgrading curl from 7.77.0 to 7.78.0...
[11/29] Extracting curl-7.78.0: .......... done
[12/29] Upgrading syslog-ng from 3.32.1 to 3.33.2...
[12/29] Extracting syslog-ng-3.33.2: .......... done
[13/29] Upgrading py37-sqlite3 from 3.7.10_7 to 3.7.11_7...
[13/29] Extracting py37-sqlite3-3.7.11_7: ........ done
[14/29] Upgrading php74-zlib from 7.4.20 to 7.4.21...
[14/29] Extracting php74-zlib-7.4.21: ....... done
[15/29] Upgrading php74-xml from 7.4.20 to 7.4.21...
[15/29] Extracting php74-xml-7.4.21: ........ done
[16/29] Upgrading php74-sqlite3 from 7.4.20 to 7.4.21...
[16/29] Extracting php74-sqlite3-7.4.21: ........ done
[17/29] Upgrading php74-sockets from 7.4.20 to 7.4.21...
[17/29] Extracting php74-sockets-7.4.21: .......... done
[18/29] Upgrading php74-simplexml from 7.4.20 to 7.4.21...
[18/29] Extracting php74-simplexml-7.4.21: ......... done
[19/29] Upgrading php74-openssl from 7.4.20 to 7.4.21...
[19/29] Extracting php74-openssl-7.4.21: ....... done
[20/29] Upgrading php74-ldap from 7.4.20 to 7.4.21...
[20/29] Extracting php74-ldap-7.4.21: ....... done
[21/29] Upgrading php74-gettext from 7.4.20 to 7.4.21...
[21/29] Extracting php74-gettext-7.4.21: ....... done
[22/29] Upgrading php74-filter from 7.4.20 to 7.4.21...
[22/29] Extracting php74-filter-7.4.21: ........ done
[23/29] Upgrading php74-dom from 7.4.20 to 7.4.21...
[23/29] Extracting php74-dom-7.4.21: .......... done
[24/29] Upgrading php74-curl from 7.4.20 to 7.4.21...
[24/29] Extracting php74-curl-7.4.21: ....... done
[25/29] Upgrading php74-ctype from 7.4.20 to 7.4.21...
[25/29] Extracting php74-ctype-7.4.21: ....... done
[26/29] Upgrading opnsense-installer from 0.10 to 21.7...
[26/29] Extracting opnsense-installer-21.7: .......... done
[27/29] Reinstalling monit-5.28.0...
[27/29] Extracting monit-5.28.0: ....... done
[28/29] Upgrading filterlog from 0.4 to 0.4_2...
[28/29] Extracting filterlog-0.4_2: .... done
[29/29] Upgrading opnsense from 21.1.8_1 to 21.1.9...
[29/29] Extracting opnsense-21.1.9: .......... done
Stopping configd...done
Resetting root shell
Updating /etc/shells
Unhooking from /etc/rc
Unhooking from /etc/rc.shutdown
Updating /etc/shells
Registering root shell
Hooking into /etc/rc
Hooking into /etc/rc.shutdown
Starting configd.
>>> Invoking update script 'refresh'
Keep version OPNsense\Monit\Monit (1.0.9)
Keep version OPNsense\Firewall\Alias (1.0.0)
Keep version OPNsense\Firewall\Category (1.0.0)
Keep version OPNsense\OpenVPN\Export (0.0.1)
Keep version OPNsense\CaptivePortal\CaptivePortal (1.0.0)
Keep version OPNsense\Core\Firmware (1.0.0)
Keep version OPNsense\Interfaces\Loopback (1.0.0)
Keep version OPNsense\Interfaces\VxLan (1.0.1)
Keep version OPNsense\Unboundplus\Dnsbl (0.0.1)
Keep version OPNsense\Unboundplus\Miscellaneous (0.0.2)
Keep version OPNsense\Cron\Cron (1.0.2)
Keep version OPNsense\IPsec\IPsec (1.0.0)
Keep version OPNsense\Backup\NextcloudSettings (1.0.0)
Keep version OPNsense\TrafficShaper\TrafficShaper (1.0.3)
Keep version OPNsense\Syslog\Syslog (1.0.0)
Keep version OPNsense\IDS\IDS (1.0.6)
Keep version OPNsense\Proxy\Proxy (1.0.4)
Keep version OPNsense\Diagnostics\Netflow (1.0.1)
Keep version OPNsense\Diagnostics\Lvtemplate (0.0.1)
Keep version OPNsense\Routes\Route (1.0.0)
Keep version OPNsense\Wol\Wol (1.0.0)
Keep version OPNsense\Wireguard\General (0.0.1)
Keep version OPNsense\Wireguard\Server (0.0.2)
Keep version OPNsense\Wireguard\Client (0.0.6)
Writing firmware setting...done.
Writing trust files...done.
Configuring login behaviour...done.
Configuring system logging...done.
You may need to manually remove /usr/local/etc/ssl/cert.pem if it is no longer needed.
You may need to manually remove /usr/local/openssl/cert.pem if it is no longer needed.
You may need to manually remove /usr/local/etc/syslog-ng.conf if it is no longer needed.
=====
Message from opnsense-21.1.9:
--
What are you looking at?
Checking integrity... done (0 conflicting)
Nothing to do.
Checking all packages: .......... done
The following package files will be deleted:
/var/cache/pkg/syslog-ng-3.33.2~6c376e7982.txz
/var/cache/pkg/py37-sqlite3-3.7.11_7.txz
/var/cache/pkg/syslog-ng-3.33.2.txz
/var/cache/pkg/python37-3.7.11~024bceafdb.txz
/var/cache/pkg/python37-3.7.11.txz
/var/cache/pkg/py37-sqlite3-3.7.11_7~0d8e85655e.txz
/var/cache/pkg/py37-cffi-1.14.6~c4813eb4af.txz
/var/cache/pkg/py37-cffi-1.14.6.txz
/var/cache/pkg/php74-zlib-7.4.21~4f9b486419.txz
/var/cache/pkg/php74-zlib-7.4.21.txz
/var/cache/pkg/php74-xml-7.4.21~4594992ca8.txz
/var/cache/pkg/php74-xml-7.4.21.txz
/var/cache/pkg/php74-sqlite3-7.4.21~1087a6de8e.txz
/var/cache/pkg/php74-pdo-7.4.21~9d780ce64e.txz
/var/cache/pkg/php74-sqlite3-7.4.21.txz
/var/cache/pkg/php74-sockets-7.4.21~318a593065.txz
/var/cache/pkg/php74-sockets-7.4.21.txz
/var/cache/pkg/php74-simplexml-7.4.21~dda830ced1.txz
/var/cache/pkg/php74-simplexml-7.4.21.txz
/var/cache/pkg/php74-session-7.4.21~2e0763e575.txz
/var/cache/pkg/php74-session-7.4.21.txz
/var/cache/pkg/php74-openssl-7.4.21.txz
/var/cache/pkg/php74-pdo-7.4.21.txz
/var/cache/pkg/php74-openssl-7.4.21~a69b02fae2.txz
/var/cache/pkg/php74-mbstring-7.4.21~b8f22e462d.txz
/var/cache/pkg/php74-ldap-7.4.21.txz
/var/cache/pkg/php74-dom-7.4.21~02da277685.txz
/var/cache/pkg/php74-mbstring-7.4.21.txz
/var/cache/pkg/php74-ldap-7.4.21~91fae3e20d.txz
/var/cache/pkg/php74-json-7.4.21~a92fc4043f.txz
/var/cache/pkg/php74-json-7.4.21.txz
/var/cache/pkg/php74-gettext-7.4.21~87373c9611.txz
/var/cache/pkg/php74-gettext-7.4.21.txz
/var/cache/pkg/php74-filter-7.4.21~6afc3f9d7a.txz
/var/cache/pkg/php74-filter-7.4.21.txz
/var/cache/pkg/php74-dom-7.4.21.txz
/var/cache/pkg/php74-curl-7.4.21~1645fc8853.txz
/var/cache/pkg/php74-curl-7.4.21.txz
/var/cache/pkg/php74-ctype-7.4.21~e77813bd37.txz
/var/cache/pkg/php74-7.4.21~c40f688ed7.txz
/var/cache/pkg/php74-ctype-7.4.21.txz
/var/cache/pkg/nss-3.68~a578c55368.txz
/var/cache/pkg/php74-7.4.21.txz
/var/cache/pkg/opnsense-installer-21.7~73cdb1077f.txz
/var/cache/pkg/opnsense-21.1.9~9135bb9250.txz
/var/cache/pkg/opnsense-installer-21.7.txz
/var/cache/pkg/opnsense-21.1.9.txz
/var/cache/pkg/monit-5.28.0.txz
/var/cache/pkg/nss-3.68.txz
/var/cache/pkg/nspr-4.32~c6d3c30cb5.txz
/var/cache/pkg/nspr-4.32.txz
/var/cache/pkg/monit-5.28.0~506ff4319e.txz
/var/cache/pkg/filterlog-0.4_2~24277c303c.txz
/var/cache/pkg/curl-7.78.0~51364ee8df.txz
/var/cache/pkg/filterlog-0.4_2.txz
/var/cache/pkg/curl-7.78.0.txz
/var/cache/pkg/ca_root_nss-3.68~4366694f46.txz
/var/cache/pkg/ca_root_nss-3.68.txz
The cleanup will free 31 MiB
Deleting files: .......... done
All done
Updating OPNsense repository catalogue...
OPNsense repository is up to date.
All repositories are up to date.
The following packages will be fetched:
New packages to be FETCHED:
opnsense: 21.1.9 (4 MiB: 50.00% of the 8 MiB to download)
opnsense-devel: 21.7.b_134 (4 MiB: 50.00% of the 8 MiB to download)
Number of packages to be fetched: 2
The process will require 8 MiB more space.
8 MiB to be downloaded.
Fetching opnsense-21.1.9.txz: .......... done
Fetching opnsense-devel-21.7.b_134.txz: .......... done
Updating OPNsense repository catalogue...
OPNsense repository is up to date.
All repositories are up to date.
The following 2 package(s) will be affected (of 0 checked):
New packages to be INSTALLED:
opnsense-devel: 21.7.b_134
suricata-devel: 6.0.3
Number of packages to be installed: 2
The process will require 29 MiB more space.
2 MiB to be downloaded.
[1/1] Fetching suricata-devel-6.0.3.txz: .......... done
Checking integrity... done (2 conflicting)
- opnsense-devel-21.7.b_134 conflicts with opnsense-21.1.9 on /boot/brand-opnsense.4th
- suricata-devel-6.0.3 conflicts with suricata-5.0.7 on /usr/local/bin/suricata
Checking integrity... done (0 conflicting)
Conflicts with the existing packages have been found.
One more solver iteration is needed to resolve them.
The following 4 package(s) will be affected (of 0 checked):
Installed packages to be REMOVED:
opnsense: 21.1.9
suricata: 5.0.7
New packages to be INSTALLED:
opnsense-devel: 21.7.b_134
suricata-devel: 6.0.3
Number of packages to be removed: 2
Number of packages to be installed: 2
[1/4] Deinstalling opnsense-21.1.9...
Stopping configd...done
Resetting root shell
Updating /etc/shells
Unhooking from /etc/rc
Unhooking from /etc/rc.shutdown
[1/4] Deleting files for opnsense-21.1.9: .......... done
[2/4] Deinstalling suricata-5.0.7...
[2/4] Deleting files for suricata-5.0.7: .......... done
==> If you are permanently removing this port, run rm -rf /usr/local/etc/suricata to remove configuration files.
[3/4] Installing suricata-devel-6.0.3...
[3/4] Extracting suricata-devel-6.0.3: .......... done
[4/4] Installing opnsense-devel-21.7.b_134...
[4/4] Extracting opnsense-devel-21.7.b_134: .......... done
Updating /etc/shells
Registering root shell
Hooking into /etc/rc
Hooking into /etc/rc.shutdown
Starting configd.
>>> Invoking update script 'refresh'
Keep version OPNsense\CaptivePortal\CaptivePortal (1.0.0)
Keep version OPNsense\Core\Firmware (1.0.0)
Keep version OPNsense\Cron\Cron (1.0.2)
Keep version OPNsense\Diagnostics\Netflow (1.0.1)
Keep version OPNsense\Diagnostics\Lvtemplate (0.0.1)
Keep version OPNsense\Firewall\Category (1.0.0)
Keep version OPNsense\Firewall\Alias (1.0.0)
Keep version OPNsense\IDS\IDS (1.0.6)
Keep version OPNsense\IPsec\IPsec (1.0.0)
Keep version OPNsense\Interfaces\VxLan (1.0.1)
Keep version OPNsense\Interfaces\Loopback (1.0.0)
Keep version OPNsense\Monit\Monit (1.0.9)
Keep version OPNsense\OpenVPN\Export (0.0.1)
Keep version OPNsense\Proxy\Proxy (1.0.4)
Keep version OPNsense\Routes\Route (1.0.0)
Keep version OPNsense\Syslog\Syslog (1.0.0)
Keep version OPNsense\TrafficShaper\TrafficShaper (1.0.3)
Migrated OPNsense\Unbound\Unbound from <unversioned> to 1.0.0
Keep version OPNsense\Wol\Wol (1.0.0)
Keep version OPNsense\Wireguard\General (0.0.1)
Keep version OPNsense\Wireguard\Server (0.0.2)
Keep version OPNsense\Wireguard\Client (0.0.6)
Writing firmware setting...done.
Writing trust files...done.
Configuring login behaviour...done.
Configuring system logging...done.
You may need to manually remove /usr/local/etc/suricata/classification.config if it is no longer needed.
You may need to manually remove /usr/local/etc/suricata/reference.config if it is no longer needed.
You may need to manually remove /usr/local/etc/suricata/suricata.yaml if it is no longer needed.
=====
Message from suricata-devel-6.0.3:
--
If you want to run Suricata in IDS mode, add to /etc/rc.conf:
suricata_enable="YES"
suricata_interface="<if>"
NOTE: Declaring suricata_interface is MANDATORY for Suricata in IDS Mode.
However, if you want to run Suricata in Inline IPS Mode in divert(4) mode,
add to /etc/rc.conf:
suricata_enable="YES"
suricata_divertport="8000"
NOTE:
Suricata won't start in IDS mode without an interface configured.
Therefore if you omit suricata_interface from rc.conf, FreeBSD's
rc.d/suricata will automatically try to start Suricata in IPS Mode
(on divert port 8000, by default).
Alternatively, if you want to run Suricata in Inline IPS Mode in high-speed
netmap(4) mode, add to /etc/rc.conf:
suricata_enable="YES"
suricata_netmap="YES"
NOTE:
Suricata requires additional interface settings in the configuration
file to run in netmap(4) mode.
RULES: Suricata IDS/IPS Engine comes without rules by default. You should
add rules by yourself and set an updating strategy. To do so, please visit:
http://www.openinfosecfoundation.org/documentation/rules.html
http://www.openinfosecfoundation.org/documentation/emerging-threats.html
You may want to try BPF in zerocopy mode to test performance improvements:
sysctl -w net.bpf.zerocopy_enable=1
Don't forget to add net.bpf.zerocopy_enable=1 to /etc/sysctl.conf
=====
Message from opnsense-devel-21.7.b_134:
--
Carry on my wayward son
Your system is up to date.
Starting web GUI...done.
Generating RRD graphs...done.
***DONE******GOT REQUEST TO UPDATE***
Updating OPNsense repository catalogue...
OPNsense repository is up to date.
All repositories are up to date.
Updating OPNsense repository catalogue...
OPNsense repository is up to date.
All repositories are up to date.
Checking for upgrades (29 candidates): .......... done
Processing candidates (29 candidates): .......... done
The following 29 package(s) will be affected (of 0 checked):
Installed packages to be UPGRADED:
ca_root_nss: 3.63 -> 3.68
curl: 7.77.0 -> 7.78.0
filterlog: 0.4 -> 0.4_2
nspr: 4.31 -> 4.32
nss: 3.67 -> 3.68
opnsense: 21.1.8_1 -> 21.1.9
opnsense-installer: 0.10 -> 21.7
php74: 7.4.20 -> 7.4.21
php74-ctype: 7.4.20 -> 7.4.21
php74-curl: 7.4.20 -> 7.4.21
php74-dom: 7.4.20 -> 7.4.21
php74-filter: 7.4.20 -> 7.4.21
php74-gettext: 7.4.20 -> 7.4.21
php74-json: 7.4.20 -> 7.4.21
php74-ldap: 7.4.20 -> 7.4.21
php74-mbstring: 7.4.20 -> 7.4.21
php74-openssl: 7.4.20 -> 7.4.21
php74-pdo: 7.4.20 -> 7.4.21
php74-session: 7.4.20 -> 7.4.21
php74-simplexml: 7.4.20 -> 7.4.21
php74-sockets: 7.4.20 -> 7.4.21
php74-sqlite3: 7.4.20 -> 7.4.21
php74-xml: 7.4.20 -> 7.4.21
php74-zlib: 7.4.20 -> 7.4.21
py37-cffi: 1.14.5 -> 1.14.6
py37-sqlite3: 3.7.10_7 -> 3.7.11_7
python37: 3.7.10_1 -> 3.7.11
syslog-ng: 3.32.1 -> 3.33.2
Installed packages to be REINSTALLED:
monit-5.28.0 (options changed)
Number of packages to be upgraded: 28
Number of packages to be reinstalled: 1
31 MiB to be downloaded.
[1/29] Fetching syslog-ng-3.33.2.txz: .......... done
[2/29] Fetching python37-3.7.11.txz: .......... done
[3/29] Fetching py37-sqlite3-3.7.11_7.txz: .... done
[4/29] Fetching py37-cffi-1.14.6.txz: .......... done
[5/29] Fetching php74-zlib-7.4.21.txz: ... done
[6/29] Fetching php74-xml-7.4.21.txz: ... done
[7/29] Fetching php74-sqlite3-7.4.21.txz: ... done
[8/29] Fetching php74-sockets-7.4.21.txz: ..... done
[9/29] Fetching php74-simplexml-7.4.21.txz: ... done
[10/29] Fetching php74-session-7.4.21.txz: ..... done
[11/29] Fetching php74-pdo-7.4.21.txz: ...... done
[12/29] Fetching php74-openssl-7.4.21.txz: ........ done
[13/29] Fetching php74-mbstring-7.4.21.txz: .......... done
[14/29] Fetching php74-ldap-7.4.21.txz: .... done
[15/29] Fetching php74-json-7.4.21.txz: ... done
[16/29] Fetching php74-gettext-7.4.21.txz: . done
[17/29] Fetching php74-filter-7.4.21.txz: ... done
[18/29] Fetching php74-dom-7.4.21.txz: ....... done
[19/29] Fetching php74-curl-7.4.21.txz: .... done
[20/29] Fetching php74-ctype-7.4.21.txz: . done
[21/29] Fetching php74-7.4.21.txz: .......... done
[22/29] Fetching opnsense-installer-21.7.txz: ... done
[23/29] Fetching opnsense-21.1.9.txz: .......... done
[24/29] Fetching nss-3.68.txz: .......... done
[25/29] Fetching nspr-4.32.txz: .......... done
[26/29] Fetching monit-5.28.0.txz: .......... done
[27/29] Fetching filterlog-0.4_2.txz: ...... done
[28/29] Fetching curl-7.78.0.txz: .......... done
[29/29] Fetching ca_root_nss-3.68.txz: .......... done
Checking integrity... done (0 conflicting)
[1/29] Upgrading python37 from 3.7.10_1 to 3.7.11...
[1/29] Extracting python37-3.7.11: .......... done
[2/29] Upgrading py37-cffi from 1.14.5 to 1.14.6...
[2/29] Extracting py37-cffi-1.14.6: .......... done
[3/29] Upgrading php74 from 7.4.20 to 7.4.21...
[3/29] Extracting php74-7.4.21: .......... done
[4/29] Upgrading nspr from 4.31 to 4.32...
[4/29] Extracting nspr-4.32: .......... done
[5/29] Upgrading ca_root_nss from 3.63 to 3.68...
[5/29] Extracting ca_root_nss-3.68: ...... done
[6/29] Upgrading php74-session from 7.4.20 to 7.4.21...
[6/29] Extracting php74-session-7.4.21: .......... done
[7/29] Upgrading php74-pdo from 7.4.20 to 7.4.21...
[7/29] Extracting php74-pdo-7.4.21: .......... done
[8/29] Upgrading php74-mbstring from 7.4.20 to 7.4.21...
[8/29] Extracting php74-mbstring-7.4.21: .......... done
[9/29] Upgrading php74-json from 7.4.20 to 7.4.21...
[9/29] Extracting php74-json-7.4.21: .......... done
[10/29] Upgrading nss from 3.67 to 3.68...
[10/29] Extracting nss-3.68: .......... done
[11/29] Upgrading curl from 7.77.0 to 7.78.0...
[11/29] Extracting curl-7.78.0: .......... done
[12/29] Upgrading syslog-ng from 3.32.1 to 3.33.2...
[12/29] Extracting syslog-ng-3.33.2: .......... done
[13/29] Upgrading py37-sqlite3 from 3.7.10_7 to 3.7.11_7...
[13/29] Extracting py37-sqlite3-3.7.11_7: ........ done
[14/29] Upgrading php74-zlib from 7.4.20 to 7.4.21...
[14/29] Extracting php74-zlib-7.4.21: ....... done
[15/29] Upgrading php74-xml from 7.4.20 to 7.4.21...
[15/29] Extracting php74-xml-7.4.21: ........ done
[16/29] Upgrading php74-sqlite3 from 7.4.20 to 7.4.21...
[16/29] Extracting php74-sqlite3-7.4.21: ........ done
[17/29] Upgrading php74-sockets from 7.4.20 to 7.4.21...
[17/29] Extracting php74-sockets-7.4.21: .......... done
[18/29] Upgrading php74-simplexml from 7.4.20 to 7.4.21...
[18/29] Extracting php74-simplexml-7.4.21: ......... done
[19/29] Upgrading php74-openssl from 7.4.20 to 7.4.21...
[19/29] Extracting php74-openssl-7.4.21: ....... done
[20/29] Upgrading php74-ldap from 7.4.20 to 7.4.21...
[20/29] Extracting php74-ldap-7.4.21: ....... done
[21/29] Upgrading php74-gettext from 7.4.20 to 7.4.21...
[21/29] Extracting php74-gettext-7.4.21: ....... done
[22/29] Upgrading php74-filter from 7.4.20 to 7.4.21...
[22/29] Extracting php74-filter-7.4.21: ........ done
[23/29] Upgrading php74-dom from 7.4.20 to 7.4.21...
[23/29] Extracting php74-dom-7.4.21: .......... done
[24/29] Upgrading php74-curl from 7.4.20 to 7.4.21...
[24/29] Extracting php74-curl-7.4.21: ....... done
[25/29] Upgrading php74-ctype from 7.4.20 to 7.4.21...
[25/29] Extracting php74-ctype-7.4.21: ....... done
[26/29] Upgrading opnsense-installer from 0.10 to 21.7...
[26/29] Extracting opnsense-installer-21.7: .......... done
[27/29] Reinstalling monit-5.28.0...
[27/29] Extracting monit-5.28.0: ....... done
[28/29] Upgrading filterlog from 0.4 to 0.4_2...
[28/29] Extracting filterlog-0.4_2: .... done
[29/29] Upgrading opnsense from 21.1.8_1 to 21.1.9...
[29/29] Extracting opnsense-21.1.9: .......... done
Stopping configd...done
Resetting root shell
Updating /etc/shells
Unhooking from /etc/rc
Unhooking from /etc/rc.shutdown
Updating /etc/shells
Registering root shell
Hooking into /etc/rc
Hooking into /etc/rc.shutdown
Starting configd.
>>> Invoking update script 'refresh'
Keep version OPNsense\Monit\Monit (1.0.9)
Keep version OPNsense\Firewall\Alias (1.0.0)
Keep version OPNsense\Firewall\Category (1.0.0)
Keep version OPNsense\OpenVPN\Export (0.0.1)
Keep version OPNsense\CaptivePortal\CaptivePortal (1.0.0)
Keep version OPNsense\Core\Firmware (1.0.0)
Keep version OPNsense\Interfaces\Loopback (1.0.0)
Keep version OPNsense\Interfaces\VxLan (1.0.1)
Keep version OPNsense\Unboundplus\Dnsbl (0.0.1)
Keep version OPNsense\Unboundplus\Miscellaneous (0.0.2)
Keep version OPNsense\Cron\Cron (1.0.2)
Keep version OPNsense\IPsec\IPsec (1.0.0)
Keep version OPNsense\Backup\NextcloudSettings (1.0.0)
Keep version OPNsense\TrafficShaper\TrafficShaper (1.0.3)
Keep version OPNsense\Syslog\Syslog (1.0.0)
Keep version OPNsense\IDS\IDS (1.0.6)
Keep version OPNsense\Proxy\Proxy (1.0.4)
Keep version OPNsense\Diagnostics\Netflow (1.0.1)
Keep version OPNsense\Diagnostics\Lvtemplate (0.0.1)
Keep version OPNsense\Routes\Route (1.0.0)
Keep version OPNsense\Wol\Wol (1.0.0)
Keep version OPNsense\Wireguard\General (0.0.1)
Keep version OPNsense\Wireguard\Server (0.0.2)
Keep version OPNsense\Wireguard\Client (0.0.6)
Writing firmware setting...done.
Writing trust files...done.
Configuring login behaviour...done.
Configuring system logging...done.
You may need to manually remove /usr/local/etc/ssl/cert.pem if it is no longer needed.
You may need to manually remove /usr/local/openssl/cert.pem if it is no longer needed.
You may need to manually remove /usr/local/etc/syslog-ng.conf if it is no longer needed.
=====
Message from opnsense-21.1.9:
--
What are you looking at?
Checking integrity... done (0 conflicting)
Nothing to do.
Checking all packages: .......... done
The following package files will be deleted:
/var/cache/pkg/syslog-ng-3.33.2~6c376e7982.txz
/var/cache/pkg/py37-sqlite3-3.7.11_7.txz
/var/cache/pkg/syslog-ng-3.33.2.txz
/var/cache/pkg/python37-3.7.11~024bceafdb.txz
/var/cache/pkg/python37-3.7.11.txz
/var/cache/pkg/py37-sqlite3-3.7.11_7~0d8e85655e.txz
/var/cache/pkg/py37-cffi-1.14.6~c4813eb4af.txz
/var/cache/pkg/py37-cffi-1.14.6.txz
/var/cache/pkg/php74-zlib-7.4.21~4f9b486419.txz
/var/cache/pkg/php74-zlib-7.4.21.txz
/var/cache/pkg/php74-xml-7.4.21~4594992ca8.txz
/var/cache/pkg/php74-xml-7.4.21.txz
/var/cache/pkg/php74-sqlite3-7.4.21~1087a6de8e.txz
/var/cache/pkg/php74-pdo-7.4.21~9d780ce64e.txz
/var/cache/pkg/php74-sqlite3-7.4.21.txz
/var/cache/pkg/php74-sockets-7.4.21~318a593065.txz
/var/cache/pkg/php74-sockets-7.4.21.txz
/var/cache/pkg/php74-simplexml-7.4.21~dda830ced1.txz
/var/cache/pkg/php74-simplexml-7.4.21.txz
/var/cache/pkg/php74-session-7.4.21~2e0763e575.txz
/var/cache/pkg/php74-session-7.4.21.txz
/var/cache/pkg/php74-openssl-7.4.21.txz
/var/cache/pkg/php74-pdo-7.4.21.txz
/var/cache/pkg/php74-openssl-7.4.21~a69b02fae2.txz
/var/cache/pkg/php74-mbstring-7.4.21~b8f22e462d.txz
/var/cache/pkg/php74-ldap-7.4.21.txz
/var/cache/pkg/php74-dom-7.4.21~02da277685.txz
/var/cache/pkg/php74-mbstring-7.4.21.txz
/var/cache/pkg/php74-ldap-7.4.21~91fae3e20d.txz
/var/cache/pkg/php74-json-7.4.21~a92fc4043f.txz
/var/cache/pkg/php74-json-7.4.21.txz
/var/cache/pkg/php74-gettext-7.4.21~87373c9611.txz
/var/cache/pkg/php74-gettext-7.4.21.txz
/var/cache/pkg/php74-filter-7.4.21~6afc3f9d7a.txz
/var/cache/pkg/php74-filter-7.4.21.txz
/var/cache/pkg/php74-dom-7.4.21.txz
/var/cache/pkg/php74-curl-7.4.21~1645fc8853.txz
/var/cache/pkg/php74-curl-7.4.21.txz
/var/cache/pkg/php74-ctype-7.4.21~e77813bd37.txz
/var/cache/pkg/php74-7.4.21~c40f688ed7.txz
/var/cache/pkg/php74-ctype-7.4.21.txz
/var/cache/pkg/nss-3.68~a578c55368.txz
/var/cache/pkg/php74-7.4.21.txz
/var/cache/pkg/opnsense-installer-21.7~73cdb1077f.txz
/var/cache/pkg/opnsense-21.1.9~9135bb9250.txz
/var/cache/pkg/opnsense-installer-21.7.txz
/var/cache/pkg/opnsense-21.1.9.txz
/var/cache/pkg/monit-5.28.0.txz
/var/cache/pkg/nss-3.68.txz
/var/cache/pkg/nspr-4.32~c6d3c30cb5.txz
/var/cache/pkg/nspr-4.32.txz
/var/cache/pkg/monit-5.28.0~506ff4319e.txz
/var/cache/pkg/filterlog-0.4_2~24277c303c.txz
/var/cache/pkg/curl-7.78.0~51364ee8df.txz
/var/cache/pkg/filterlog-0.4_2.txz
/var/cache/pkg/curl-7.78.0.txz
/var/cache/pkg/ca_root_nss-3.68~4366694f46.txz
/var/cache/pkg/ca_root_nss-3.68.txz
The cleanup will free 31 MiB
Deleting files: .......... done
All done
Updating OPNsense repository catalogue...
OPNsense repository is up to date.
All repositories are up to date.
The following packages will be fetched:
New packages to be FETCHED:
opnsense: 21.1.9 (4 MiB: 50.00% of the 8 MiB to download)
opnsense-devel: 21.7.b_134 (4 MiB: 50.00% of the 8 MiB to download)
Number of packages to be fetched: 2
The process will require 8 MiB more space.
8 MiB to be downloaded.
Fetching opnsense-21.1.9.txz: .......... done
Fetching opnsense-devel-21.7.b_134.txz: .......... done
Updating OPNsense repository catalogue...
OPNsense repository is up to date.
All repositories are up to date.
The following 2 package(s) will be affected (of 0 checked):
New packages to be INSTALLED:
opnsense-devel: 21.7.b_134
suricata-devel: 6.0.3
Number of packages to be installed: 2
The process will require 29 MiB more space.
2 MiB to be downloaded.
[1/1] Fetching suricata-devel-6.0.3.txz: .......... done
Checking integrity... done (2 conflicting)
- opnsense-devel-21.7.b_134 conflicts with opnsense-21.1.9 on /boot/brand-opnsense.4th
- suricata-devel-6.0.3 conflicts with suricata-5.0.7 on /usr/local/bin/suricata
Checking integrity... done (0 conflicting)
Conflicts with the existing packages have been found.
One more solver iteration is needed to resolve them.
The following 4 package(s) will be affected (of 0 checked):
Installed packages to be REMOVED:
opnsense: 21.1.9
suricata: 5.0.7
New packages to be INSTALLED:
opnsense-devel: 21.7.b_134
suricata-devel: 6.0.3
Number of packages to be removed: 2
Number of packages to be installed: 2
[1/4] Deinstalling opnsense-21.1.9...
Stopping configd...done
Resetting root shell
Updating /etc/shells
Unhooking from /etc/rc
Unhooking from /etc/rc.shutdown
[1/4] Deleting files for opnsense-21.1.9: .......... done
[2/4] Deinstalling suricata-5.0.7...
[2/4] Deleting files for suricata-5.0.7: .......... done
==> If you are permanently removing this port, run rm -rf /usr/local/etc/suricata to remove configuration files.
[3/4] Installing suricata-devel-6.0.3...
[3/4] Extracting suricata-devel-6.0.3: .......... done
[4/4] Installing opnsense-devel-21.7.b_134...
[4/4] Extracting opnsense-devel-21.7.b_134: .......... done
Updating /etc/shells
Registering root shell
Hooking into /etc/rc
Hooking into /etc/rc.shutdown
Starting configd.
>>> Invoking update script 'refresh'
Keep version OPNsense\CaptivePortal\CaptivePortal (1.0.0)
Keep version OPNsense\Core\Firmware (1.0.0)
Keep version OPNsense\Cron\Cron (1.0.2)
Keep version OPNsense\Diagnostics\Netflow (1.0.1)
Keep version OPNsense\Diagnostics\Lvtemplate (0.0.1)
Keep version OPNsense\Firewall\Category (1.0.0)
Keep version OPNsense\Firewall\Alias (1.0.0)
Keep version OPNsense\IDS\IDS (1.0.6)
Keep version OPNsense\IPsec\IPsec (1.0.0)
Keep version OPNsense\Interfaces\VxLan (1.0.1)
Keep version OPNsense\Interfaces\Loopback (1.0.0)
Keep version OPNsense\Monit\Monit (1.0.9)
Keep version OPNsense\OpenVPN\Export (0.0.1)
Keep version OPNsense\Proxy\Proxy (1.0.4)
Keep version OPNsense\Routes\Route (1.0.0)
Keep version OPNsense\Syslog\Syslog (1.0.0)
Keep version OPNsense\TrafficShaper\TrafficShaper (1.0.3)
Migrated OPNsense\Unbound\Unbound from <unversioned> to 1.0.0
Keep version OPNsense\Wol\Wol (1.0.0)
Keep version OPNsense\Wireguard\General (0.0.1)
Keep version OPNsense\Wireguard\Server (0.0.2)
Keep version OPNsense\Wireguard\Client (0.0.6)
Writing firmware setting...done.
Writing trust files...done.
Configuring login behaviour...done.
Configuring system logging...done.
You may need to manually remove /usr/local/etc/suricata/classification.config if it is no longer needed.
You may need to manually remove /usr/local/etc/suricata/reference.config if it is no longer needed.
You may need to manually remove /usr/local/etc/suricata/suricata.yaml if it is no longer needed.
=====
Message from suricata-devel-6.0.3:
--
If you want to run Suricata in IDS mode, add to /etc/rc.conf:
suricata_enable="YES"
suricata_interface="<if>"
NOTE: Declaring suricata_interface is MANDATORY for Suricata in IDS Mode.
However, if you want to run Suricata in Inline IPS Mode in divert(4) mode,
add to /etc/rc.conf:
suricata_enable="YES"
suricata_divertport="8000"
NOTE:
Suricata won't start in IDS mode without an interface configured.
Therefore if you omit suricata_interface from rc.conf, FreeBSD's
rc.d/suricata will automatically try to start Suricata in IPS Mode
(on divert port 8000, by default).
Alternatively, if you want to run Suricata in Inline IPS Mode in high-speed
netmap(4) mode, add to /etc/rc.conf:
suricata_enable="YES"
suricata_netmap="YES"
NOTE:
Suricata requires additional interface settings in the configuration
file to run in netmap(4) mode.
RULES: Suricata IDS/IPS Engine comes without rules by default. You should
add rules by yourself and set an updating strategy. To do so, please visit:
http://www.openinfosecfoundation.org/documentation/rules.html
http://www.openinfosecfoundation.org/documentation/emerging-threats.html
You may want to try BPF in zerocopy mode to test performance improvements:
sysctl -w net.bpf.zerocopy_enable=1
Don't forget to add net.bpf.zerocopy_enable=1 to /etc/sysctl.conf
=====
Message from opnsense-devel-21.7.b_134:
--
Carry on my wayward son
Your system is up to date.
Starting web GUI...done.
Generating RRD graphs...done.
***DONE***
Entered 3 servers on the DoT page and set the tick box under "Advanced" for "strict Qname minisation"
Is it necessary to set the tick box "DNS query forwarding" under "General"?
Many thanks in advance!
-
"DNS query forwarding" adds the system's domain servers as forwarding servers to ask so you don't want to enable that. Forwarding for DoT is automatically enabled when you have at least one enabled DoT server.
Cheers,
Franco
-
I made a mistake. After switching back to "Community" I pressed the update button and switched back to ... whatever... 21.1.9 is shown in the GUI.
***GOT REQUEST TO AUDIT HEALTH***
Currently running OPNsense 21.1.9 (amd64/LibreSSL) at Wed Jul 28 08:38:19 CEST 2021
>>> Check installed kernel version
Version 21.1.8 is correct.
>>> Check for missing or altered kernel files
No problems detected.
>>> Check installed base version
Version 21.1.8 is correct.
>>> Check for missing or altered base files
No problems detected.
>>> Check for missing package dependencies
Checking all packages: .......... done
>>> Check for missing or altered package files
Checking all packages: .......... done
>>> Check for core packages consistency
Core package "opnsense" has 66 dependencies to check.
Checking packages: .................................................................... done
***DONE***
Worst thing: Now the SSD it 90% full (see attachment) and I have no idea with what...
And the DoT tab in unbound is gone. No idea which configuration of unbound is valid at that time. Will updating to 21.7 later today resolve this mess?
-
Worst thing: Now the SSD it 90% full (see attachment) and I have no idea with what...
That's a known issue with the upgrade to 21.1.9, and a reboot should fix it, at least it did for me
https://forum.opnsense.org/index.php?topic=24095.0 (https://forum.opnsense.org/index.php?topic=24095.0)
-
Worst thing: Now the SSD it 90% full (see attachment) and I have no idea with what...
That's a known issue with the upgrade to 21.1.9, and a reboot should fix it, at least it did for me
https://forum.opnsense.org/index.php?topic=24095.0 (https://forum.opnsense.org/index.php?topic=24095.0)
Not the CPU, the SSD. Reboot helps nothing....
-
Not the CPU, the SSD. Reboot helps nothing....
Mine was doing it to both which I only noticed afterwards when I checked my Zabbix logs which showed my SSD being hammered, though I first spotted the issue due to the CPU fan going mad.
-
no zabbix here...
-
According to the unbound log, port 853 and my configured servers are used for DNS queries. But I can see/configure the related pages in the GUI.
What filled up 90% of my SSD would be nice to know/remove...
-
> After switching back to "Community"
But why:
> I repeat: switch to development, use the new code, do the upgrade, switch back to community.
I meant 21.7 obviously. Switching back to a version that does not have the code makes no sense.
Cheers,
Franco
-
I only wanted to check for updates, but all of a sudden the "up"date (downgrade?) started... sigh...
We are here now, what's next?
-
Fresh install with 21.7 later? Or any other ideas? :-)
-
Nothing starts suddenly without a confirmation prompt. I'm sorry, I don't have time for this as I need to prepare the 21.7 release now.
Cheers,
Franco
-
It was system logs exploding since yesterday plus very large log files for resolver on a daily basis for the whole period configured to log. SSD usage looking much better now.
Hope I can avoid doing complete fresh install. Had a look at the config.xml of the system. The is both, info from the custom options for unbound as well a the new DoT page (which is currently not visable in the GUI). Will this be a problem for 21.7?
-
Looking good now
***GOT REQUEST TO AUDIT HEALTH***
Currently running OPNsense 21.7 (amd64/LibreSSL) at Wed Jul 28 14:34:48 CEST 2021
>>> Check installed kernel version
Version 21.7 is correct.
>>> Check for missing or altered kernel files
No problems detected.
>>> Check installed base version
Version 21.7 is correct.
>>> Check for missing or altered base files
No problems detected.
>>> Check for missing package dependencies
Checking all packages: .......... done
>>> Check for missing or altered package files
Checking all packages: .......... done
>>> Check for core packages consistency
Core package "opnsense" has 66 dependencies to check.
Checking packages: .................................................................... done
***DONE***
...and unbound tab for DoT (and check box for qname minimisation) is back... :-)
-
Sorry for the noob question but trying to get ahead of the eventual upgrade to 21.7, but currently my Unbound has the following in custom:
server:
do-not-query-localhost: no
forward-zone:
name: "."
forward-addr: ::1@5353
forward-addr: 127.0.0.1@5353
It's forwarding to the DNSCrypt-Proxy service.
Will I be able to do this with 21.7 and the new standard menu? Currently still on 21.1.8 as I am not on-site to attempt the upgrade to 21.1.9
Did you find a solution yet? I'm faced with the same issue now that custom options are being taken away :(
-
No, nobody has replied yet, so I am holding off my upgrade until someone does.
Sorry for the noob question but trying to get ahead of the eventual upgrade to 21.7, but currently my Unbound has the following in custom:
server:
do-not-query-localhost: no
forward-zone:
name: "."
forward-addr: ::1@5353
forward-addr: 127.0.0.1@5353
It's forwarding to the DNSCrypt-Proxy service.
Will I be able to do this with 21.7 and the new standard menu? Currently still on 21.1.8 as I am not on-site to attempt the upgrade to 21.1.9
Did you find a solution yet? I'm faced with the same issue now that custom options are being taken away :(
-
https://docs.opnsense.org/manual/unbound.html
-
https://docs.opnsense.org/manual/unbound.html
...the relevant info starts with
...
Advanced Configurations
Some installations require configuration settings that are not accessible in the UI. To support these, individual configuration files with a .conf extension can be put into the /usr/local/etc/unbound.opnsense.d directory. These files will be automatically included by the UI generated configuration. Multiple configuration files can be placed there. But note that...
-
https://docs.opnsense.org/manual/unbound.html (https://docs.opnsense.org/manual/unbound.html)
Thanks Franco. Now I can wait patiently for the upgrade path.
-
Thanks Franco. Now I can wait patiently for the upgrade path.
This looks like a nicer option. Otherwise the custom config won't be part of the overall config file, potentially messing up restores:
https://forum.opnsense.org/index.php?topic=23941.0 (https://forum.opnsense.org/index.php?topic=23941.0)
-
This looks like a nicer option. Otherwise the custom config won't be part of the overall config file, potentially messing up restores:
https://forum.opnsense.org/index.php?topic=23941.0 (https://forum.opnsense.org/index.php?topic=23941.0)
Yes saw that as well, so will likely switch to it once I'm on 21.7
-
Well, neither method on that documentation page seems to work so either I did it wrong after triple checking or it too is for 21.7 only. Using the template method got me the incredibly useful message "ERR", then tried to copy a new conf file and on the check it just said "Action not found. Oh and "/usr/local/etc/unbound.opnsense.d" does not exist either - I tried copying my conf file to "/usr/local/etc/unbound" which was present.
So when I upgrade I will have to hope I can still access my firewall's web interface so I can fix it, and if past experience is anything to go by, I probably won't be able to. We'll have to see.
-
The custom field from the community repo can only be installed on 21.7, as in 21.1 it's still in the basic system ;-)
Remove your custom settings in the unbound GUI field and get back to "normal" DNS as resolver. Or switch to DNSmasq for the update. Check that our DNS is working. Go to 21.7 and then install the plugin for the custom field. Or copy your additional info to the new directory.
But I don't know your complete setup (DoT I guess), so YMMV...
-
Er, yes, the documentation now reflects 21.7.
Cheers,
Franco
-
Just want to say thanks to Franco and team! I just use a basic Unbound DoT forwarding config (as I suspect most do for DoT?) and the new 21.7 DoT features are working great.
cat /var/unbound/etc/dot.conf
server:
tls-cert-bundle: /etc/ssl/cert.pem
forward-zone:
name: "."
forward-tls-upstream: yes
forward-addr: 9.9.9.9@853#dns.quad9.net
forward-addr: 149.112.112.112@853#dns.quad9.net
forward-addr: 2620:fe::fe@853#dns.quad9.net
forward-addr: 2620:fe::9@853#dns.quad9.net
-
Even if we had a dumbed down version of the box, it would be nice to have a way to add always_nxdomain entries for a few really enormously bad domains I block entirely, as well as their subdomains.
One example is online-metrix.net which is a port scanner, on all subdomains - the same one used by ebay. It exploits websockets to do this.
server:
local-zone: "online-metrix.net" always_nxdomain
I'll do the custom config file route for now but just wondering if anyone has a better way of doing this - nxdomain is my favorite though for blocking all subdomains and the parent domain as well.
-
Development version for me is unstable.
After enabling DoT the router works for 5 mins and then stops working.
No network access and its like the whole OS crashes as none of my devices wired or wireless get DHCP or connectivity. Only way to access the firewall is to plug keyboard and monitor to it.
Now I have to clean install. Thankfully I keep cloud backups of config!
-
> Development version for me is unstable.
The config is the same for Unbound whether you manually add it or let the GUI do it. That bundled with the same Unbound version I highly doubt instability suddenly appears in that fixes system and you will need to troubleshoot DNS anyway.
Cheers,
Franco
-
> Development version for me is unstable.
The config is the same for Unbound whether you manually add it or let the GUI do it. That bundled with the same Unbound version I highly doubt instability suddenly appears in that fixes system and you will need to troubleshoot DNS anyway.
Cheers,
Franco
its not just DNS the router becomes un reachable.
even via IP.
-
I had loggin derail (system) at some point on Development. Any real reason to stay on Developement and not to switch (back) to 21.7?
-
> Development version for me is unstable.
The config is the same for Unbound whether you manually add it or let the GUI do it. That bundled with the same Unbound version I highly doubt instability suddenly appears in that fixes system and you will need to troubleshoot DNS anyway.
Cheers,
Franco
I wiped and installed latest version stable version and it seems fine now.
Will wait for the changes from development to be in main release rather then trying development I think
-
For all intents and purposes 21.1.9_1 development is the same as 21.7 development is the same as 21.7 release in terms of code and third party software.
The logging issue is also present in 21.1.8 -> 21.1.9 upgrade due to Syslog-ng and Python 3.7 updates. Not necessarily bad, but the missing reboot in this one (no new base or kernel updates) makes this log loop visible.
Honestly, I've never seen such a log loop before and there were no log code changes in 21.1.x either.
Cheers,
Franco
-
1. Ever since the OpenVPN custom options privilege escalation debacle in 2019 that affected *sense and prior widespread use of "just let us have custom configuration fields for all services" we decided to remove these ticking time bombs proactively and block their inclusion... slowly but steadily.
https://github.com/opnsense/changelog/blob/17ab9aee2c11fcaf811245b0b9a5e23a7c48a34f/community/19.1/19.1.8#L36
2. From a product perspective advanced users will add their custom glue and deprive meaningful use cases from the not so advanced users. It's better to work together and find GUI-driven solutions to problems everybody has.
3. For anyone saying "The GUI can't do this but when I edit the config file it gets overwritten" we usually advise to avoid using the GUI (core or plugin) and just use the service like anyone would on FreeBSD. Most decline, hence (2) is better in the long run anyway.
Cheers,
Franco
Franco,
Fuck you. I'm advanced enough to use the unbound config because I fucking learned how to do it because I needed to for the functionality. You just pushed that further out of reach. Now I have to jump through more fucking hoops in the name of protecting who? The less advanced don't know enough to break it. fkja;lkadsf.,lk I can't fucking express how fucking mad I am. Not because you did it, but because your reasoning is so fucking broken. I wish I had paid for opnsense so I could dispute the charge, so I could demand my money back. I wish you had a patreon I supported so I could pull it.
-
You sir need to take a chill pill and relax!
Dont vent your frustrations like a child and act so horribly.
If you dont like this free open source software take your lack of business elsewhere and go whine to someone else that you pay for software.
-
Franco,
[...]
Get over yourself. Just turn off Unbound in the GUI and run it via rc.conf with your own config file. I think that's time worth spent vs. pseudo-insulting open source code. ;)
Cheers,
Franco
-
Honestly the response is out of line and out of place... ranting antagonizes people (and I've had my share of vicious rants and trolling when I was younger ;P). If anything, I'm impressed with the way Franco responded (and I would have expected this to derail quickly if it happened in a different project).
On to the issue: custom config addendums are factually a security problem. Most of them allow for trivial UI to shell access, sometimes without a reboot. It's a good idea to remove them together with sanitizing inputs everywhere else, because in the end, you might as well be injecting a CRLF somewhere and a config snippet in some field. In that sense, they are taking the right steps in the long term. Of course at some point privilege separation of the web UI would be a proper course of action... but development roadmaps exist for a reason.
They left a nice way to include config mods for you... use it. All you need is shell access. Setup your user properly, add SSH pubkeys and voila. I hope you are aware that the custom options for Unbound was implemented in a way that was flakey and you had to work around it for most of the common uses. This problem is gone with the current custom config support.
edit for ref to documentation on the custom configs method: https://docs.opnsense.org/manual/unbound.html#advanced-configurations
-
On to the issue: custom config addendums are factually a security problem. Most of them allow for trivial UI to shell access, sometimes without a reboot.
But you have to authenticate to the UI first. And if you are logged in you can create users, reset the root password, enable SSH, disable all firewalling ... anyway, to your heart's content.
I don't see how these free form custom options pose any additional risk.
Could you explain?
[/quote]
-
On to the issue: custom config addendums are factually a security problem. Most of them allow for trivial UI to shell access, sometimes without a reboot.
But you have to authenticate to the UI first. And if you are logged in you can create users, reset the root password, enable SSH, disable all firewalling ... anyway, to your heart's content.
I don't see how these free form custom options pose any additional risk.
Could you explain?
[/quote]
Sure, a bunch of scenarios:
- You assume that everyone runs their firewalls as single-user/root only systems, whereas some people actually have user roles... so, let's say you have someone with access to a plugin that has custom options in the UI. Or a bunch of them. Call this "DNS admin intern".
- Custom options resulting in direct command execution or file manipulation override/bypass all ACLs in the UI, they just execute as the user of the httpd process or the CGI module (ex. WSGI or fastcgi).
- The entire ACL subsystem is moot so as long as there are obvious ways to bypass it.
Defense in depth. Also: you should not be administrating your firewall with a single user defined, and your root user data (including passwords and SSH keys) should be in offline storage (a Qubes system with a vault domain suffices.... along a HW password manager).
Of course if you do, you do so at your own risk and peril. But Franco and his team have to cater to the kind of users that do not run their systems with a maximum privilege principle.
-
I did not know that OPNsense supports administrative roles. Thanks.
Most appliances I know don't.
-
Unacceptable behaviour from cloudhoppingflowerchild. As someone who has personally interacted with Franco multiple times and received essentially free enterprise support multiple times this reaction is unwarranted and unfair and not reflective of the hard and thankless work Franco performs. You should use a different product if a free community open source product provided to you in good faith does not meet your needs. I apologise on your behalf.
-
You assume that everyone runs their firewalls as single-user/root only systems, whereas some people actually have user roles... so, let's say you have someone with access to a plugin that has custom options in the UI. Or a bunch of them. Call this "DNS admin intern".
Actually this is what https://github.com/opnsense/changelog/blob/a16acafb81b2df83a0c7feb1faa6f29fe2825107/community/19.1/19.1.8#L36 was all about over two years ago. Anyone with access to the OpenVPN configuration pages was basically able to dispatch arbitrary commands on the firewall. We locked editing custom options fields for non-administrators for that reason.
This why we also removed the raw file edit and command execution pages almost after our initial release 15.1:
https://github.com/opnsense/core/commit/f2a21ac4462
https://github.com/opnsense/core/commit/f958a96258d
The clearer issue is direct access through the ACL to those pages, but what if you could write arbitrary commands into the config.xml to gain access to those pages? From a harmless page you could get access to more dangerous pages.
This was also highlighted by the implementation of the read-only privilege which is per definition not allowed to write config changes, but if you have access to the configuration backup page you used to be able to switch to older config.xml backups or even upload a new config.xml:
https://github.com/opnsense/changelog/blob/a16acafb81b2df83a0c7feb1faa6f29fe2825107/community/18.7/18.7.7#L27
There are still pitfalls such as non-root shell access whereas potentially anyone could read the config.xml even if they have no GUI access at all. Basically we recommend never giving shell access to non-root users, but ultimately this should be fixed in a more sensible way. I think OpenVPN is currently blocking this effort because it wants to read the config.xml in an unprivileged manner.
As for *sense having an ACL... it is relatively flexible and was inherited from m0n0wall itself, but has a couple of implementational artefacts. Since it was never shipped with predefined roles I think the user base for this feature is relatively small even today. I know of a commercial m0n0wall fork that actually used this ACL extensively, but it was a special purpose fork aimed at captive portal operation where there were technical and non-technical people required to operate different aspects of it.
Cheers,
Franco
-
I did not know that OPNsense supports administrative roles. Thanks.
Most appliances I know don't.
I don't know any enterprise products that don't support fine-grained ACLs. If you talk about consumer/prosumer "crap", then yeah, most of them are garbage if you need proper security/privilege separation of some kind (let alone the ability to have audit trails), but they are meant for the market they cater to. Franco responded with far more detail.
-
Actually this is what https://github.com/opnsense/changelog/blob/a16acafb81b2df83a0c7feb1faa6f29fe2825107/community/19.1/19.1.8#L36 was all about over two years ago. Anyone with access to the OpenVPN configuration pages was basically able to dispatch arbitrary commands on the firewall. We locked editing custom options fields for non-administrators for that reason.
This why we also removed the raw file edit and command execution pages almost after our initial release 15.1:
https://github.com/opnsense/core/commit/f2a21ac4462
https://github.com/opnsense/core/commit/f958a96258d
The clearer issue is direct access through the ACL to those pages, but what if you could write arbitrary commands into the config.xml to gain access to those pages? From a harmless page you could get access to more dangerous pages.
I haven't looked into the internals of the webgui beyond checking if it runs unprivileged (it runs as root per the php-fpm pool configuration), but in the end, any loophole in the UI will allow for unconstrained root access. Since the process runs as root, you could even write a PHP stage to inject a module in the kernel, entirely off memory (has been done for Linux, for example), without requiring any sort of shell command interaction, just the API exposed via PHP and the POSIX & BSD syscalls.
This is why I mentioned defense in depth, it's not rational or making any sense to criticize the effort to remove custom options or anything in the UI that can allow for ACL bypasses.
This was also highlighted by the implementation of the read-only privilege which is per definition not allowed to write config changes, but if you have access to the configuration backup page you used to be able to switch to older config.xml backups or even upload a new config.xml:
https://github.com/opnsense/changelog/blob/a16acafb81b2df83a0c7feb1faa6f29fe2825107/community/18.7/18.7.7#L27
There are still pitfalls such as non-root shell access whereas potentially anyone could read the config.xml even if they have no GUI access at all. Basically we recommend never giving shell access to non-root users, but ultimately this should be fixed in a more sensible way. I think OpenVPN is currently blocking this effort because it wants to read the config.xml in an unprivileged manner.
As for *sense having an ACL... it is relatively flexible and was inherited from m0n0wall itself, but has a couple of implementational artefacts. Since it was never shipped with predefined roles I think the user base for this feature is relatively small even today. I know of a commercial m0n0wall fork that actually used this ACL extensively, but it was a special purpose fork aimed at captive portal operation where there were technical and non-technical people required to operate different aspects of it.
I forgot about that config.xml trick :-)
I agree that the user base for the ACL is small, but just to name one example for a system I was involved with (consulting/advice for the operations staff, they also used a well known fw product similar to OPNsense and repeated the same strategy): they had NOC users that could edit firewall rules and nothing else. This is plenty damaging (you can redirect traffic for higher privilege users...) but nonetheless they still separated things like VPN management, etc.
Of course the market for niche firewall solutions is very different than say, Palo Alto and co.
-
I don't know any enterprise products that don't support fine-grained ACLs. If you talk about consumer/prosumer "crap", then yeah, most of them are garbage if you need proper security/privilege separation of some kind (let alone the ability to have audit trails), but they are meant for the market they cater to. Franco responded with far more detail.
I would not put the Sidewinder firewall or TrueNAS into the "crap" category. But TrueNAS has got only one root account for the web UI, and Sidewinder supports an arbitrary number of individual admin accounts but only with either r/w for everything or r/o for everything.
-
I don't know any enterprise products that don't support fine-grained ACLs. If you talk about consumer/prosumer "crap", then yeah, most of them are garbage if you need proper security/privilege separation of some kind (let alone the ability to have audit trails), but they are meant for the market they cater to. Franco responded with far more detail.
I would not put the Sidewinder firewall or TrueNAS into the "crap" category. But TrueNAS has got only one root account for the web UI, and Sidewinder supports an arbitrary number of individual admin accounts but only with either r/w for everything or r/o for everything.
The use of "crap" there is synonymous for "consumer or prosumer gear" or lower tier network appliances.
TrueNAS has a lot of effort behind it, and even though I personally do not use it (I have gone through the pain of manually configuring zfs pools, nfs servers, etc), it fits a very specific niche in the market and it does so very well. :-)
As an entirely subjective observation: I would not put my money in any McAfee products as far as their SIEM offerings go and so on... but this is offtopic here ;P
-
Sidewinder belongs to Forcepoint/Raytheon now and is EOL. But it definitely had its time, in my opinion.
-
...just to add: the promised 50.- € donation for the project is out, plus 50.- € donation for general charity (flooging victims, refugees, social service). Mission accomplished, regarding DoT and OPNsense :-D
-
...just to add: the promised 50.- € donation for the project is out, plus 50.- € donation for general charity (flooging victims, refugees, social service). Mission accomplished, regarding DoT and OPNsense :-D
<3
-
Is there a reason that the custom config files I create disappear from the folder after I restart unbound?
To be more precise. Let's say I create a new config file /usr/local/etc/unbound.opnsense.d/plex.conf with the following content:
server:
private-domain: "plex.direct"This config file disappears when I restart unbound.
*EDIT*
Nevermind, it seems to have been related to the indentation.
-
Is there a reason that the custom config files I create disappear from the folder after I restart unbound?
Are you creating them in /usr/local/etc/unbound.opnsense.d as documented?
-
Is there a reason that the custom config files I create disappear from the folder after I restart unbound?
Are you creating them in /usr/local/etc/unbound.opnsense.d as documented?
Yeah, I think there was an issue related to the indentation. The config file seems to be persistent now.
-
If now the custom-options Form is removed from the GUI, is there any chance to get the custom-options.conf with the adaptations in the backup / and later on with a fresh install recovered....
-
server:
private-domain: "plex.direct"
Private domain is supported, see Services: Unbound DNS: Blocklist.
If now the custom-options Form is removed from the GUI, is there any chance to get the custom-options.conf with the adaptations in the backup / and later on with a fresh install recovered....
The whole point is not making something uncontrollable stick in the configuration in the first place.
Cheers,
Franco
-
So after upgrading to 21.7 and temporarily setting a system external DNS beforehand, I have successfully gotten Unbound working as I want it.
I decided to drop DNS-Proxy for DoH/DoT and used the DoT option in Unbound (I might revisit using DNS-Proxy in the future). The only thing I needed to work around was getting Unbound to use the local Bind service for lookups of my internal domain - Bind is set up as a slave to the main internal zone as this helps the firewall use internal FQDNs when the it is starting up. So I used the Custom plug-in to allow me to add "do-not-query-localhost: no" then Unbound was allowed to contact Bind - hopefully this could be added as a standard option of the main GUI.
-
server:
private-domain: "plex.direct"
Private domain is supported, see Services: Unbound DNS: Blocklist.
Ah, thanks for the hint.
-
server:
private-domain: "plex.direct"
Private domain is supported, see Services: Unbound DNS: Blocklist.
If now the custom-options Form is removed from the GUI, is there any chance to get the custom-options.conf with the adaptations in the backup / and later on with a fresh install recovered....
The whole point is not making something uncontrollable stick in the configuration in the first place.
Cheers,
Franco
the best to not get something uncontrollable in the configuration and have a backup of custom options in case of restore would be really easy, just add the custom-options form back ... ;D
-
Or just not. ¯\_(ツ)_/¯
Cheers,
Franco
-
So theres no support for custom SRV records then?
I managd to move my private domins over but i have a kms SRV record set up for auto detection.
-
So theres no support for custom SRV records then?
Unbound is not an authoritative nameserver but strictly a recursive resolver. You would need to use the BIND plugin - which supports SRV records just fine.
-
Unbound is not an authoritative nameserver but strictly a recursive resolver. You would need to use the BIND plugin - which supports SRV records just fine.
This is what I did in order for my firewall to hold a local copy of my main DNS zone (on Windows servers). Bind is set up as a slave zone and Unbound uses it as the lookup for my internal domain, however, for it to be able to do that you have to enable "local DNS access" as that gets blocked and this can only be done with a custom option.
-
This can be achieved now via the documented /usr/local/etc/unbound.opnsense.d directory.
If you feel like it you could implement it as a full featured option and send a pull request. Adding a single field/option to an existing dialog and writing out a handful of lines to a config file is not that difficult even if one doesn't know (much) PHP. It's mainly XML and Jinja ...
-
This can be achieved now via the documented /usr/local/etc/unbound.opnsense.d directory.
If you feel like it you could implement it as a full featured option and send a pull request. Adding a single field/option to an existing dialog and writing out a handful of lines to a config file is not that difficult even if one doesn't know (much) PHP. It's mainly XML and Jinja ...
I used the Custom Options plug-in, will leave the coding to the experts - I'm fine at scripting but don't enjoy the kind of changes required for this.
-
I have read the whole discussion and would like to say a few words.
Franco says he wants to eliminate certain parameters (such as Dns Unbound coustom option) from the graphic configuration because with the expansion of the user base many novice people could make big problems using them.
But firewalls are complex systems, and whoever uses them must at least read a fucking manual before doing a basic setup.
No firewall manufacturer that I know of whether it is Checkpoint or Cisco or juiniper or Palo alto would have ever followed this logic.
Furthermore, if during an update such a feature is deleted before proceeding, the system must give a warning big as a house to the system administrator, especially because it is not certain that one can quickly realize that the configuration has changed. because the Dnscrypt service is still formally active and if you do not check the service logs or the Unbound configuration, you risk exposing yourself to a security risk because a system security feature has been removed without however disabling the related service.
Perhaps instead of disabling that field from the graphical configuration I would have put a nice warning banner with a check mark so that the inexperienced user would realize that changing it without having the right knowledge could lead to catastrophic results.
this is my two cents.
-
must at least read a fucking manual
Nice try for a technical discussion with validity and security concerns, but won't bite. If software development for Unbound and OPNsense stood still I would agree but it does not. :)
Cheers,
Franco
-
There is a deprecation note for nearly a year and there will be a known limitation note in the major release notes. Whats the deal here AlexV?
-
Plus there is a well documented supported option for power users. Only need to use the command line.
-
Nice try for a technical discussion with validity and security concerns, but won't bite. If software development for Unbound and OPNsense stood still I would agree but it does not. :)
Cheers,
Franco
Maybe you are right, but at the moment Unbound Configuration of DOH is less flexible than DnsCrypt proxy.
for example for add a dns in dnscrypt i can use the well know list based on NS domain name.
in the unbound must be use the ip .
so if you decide to remove a function to replace it with another, the latter must have at least all the functionality of the replaced function.
by the way i will reported a issue with Dnscrypt log that are not more visibile form GUI.
can you fix this ?
-
Problem is in open source is there are no coders developing something then just moaning that it must be maintained in a certain way is not helpful. When you bring up other companies and say company x would never have done this they would have supported Y in some way, this is illogical. They pay people to code whatever they want. Open source does not work this way. Either you contribute or you dont moan. So either write and submit the code you want added or learn to adapt like the rest of us have.
-
You can still have all the custom configuration you need. Just put it as a text config file into the documented directory. Documented, supported, will survive reboots and updates. The ONLY location where it was removed is the UI!
-
by the way i will reported a issue with Dnscrypt log that are not more visibile form GUI.
can you fix this ?
22.1.1