Messages

Twitter seems to be in a death spiral, see https://blog.iconfactory.com/2023/01/twitterrific-end-of-an-era/ for how they are treating app developers.  I was using a different app to access Twitter and it also stopped working and I am so fed up with Twitter anyway that I haven't been on their site since except to stop following everyone I had been following there.  For a number of reasons you may want to consider leaving Twitter and moving to Mastodon while you have the choice and can announce it to your followers, because there's a good chance that if and when (and I think it's a matter of when, not if) it disappears it will do so quite suddenly, and then you won't have the opportunity to tell your Twitter followers how to find you on Mastodon.  Obviously you don't need to leave Twitter in order to have a presence on Mastodon, you could post to both for a while, but increasingly you may find that Twitter is turning into the kind of place you won't want to be.

Just a suggestion.

[how]

And to answer a previous poster, no, it's not fixed.  Lock Suricata at 6.0.8.  Everything else should work fine.

Thanks for the response.  Still running 22.7.8 here so don't have to revert anything, and I'm not using Suricata but I know it is installed on the router because I see it update when I update OPNsense.  So what I'm trying to clarify is, if I lock my current version of Suricata can I then upgrade to the current OPNsense version without issues, or am I still likely to have problems?  In other words is it definitely just Suricata that is causing all the weirdness and the loss of Internet connectivity, or are there other factors at play also?

And assuming you can do normal upgrades once you have locked Suricata, then my question is, how do you lock Suricata at the current version?  EDIT:  After more searching I found the post on Reddit that gave this procedure:

System - Firmware - Packages

Scroll down to Suricata. On the far right there's a lock icon. Clicking it toggles locked/unlocked.

Is that the procedure you used to lock it?

As I said previously, OPNsense has been such a joy to use up until this, but I cannot take the risk of doing an update and having the router lose internet connectivity (whether immediately or a day later).  I would really hate having to go to pfsense or some other router software after all this time, so I hope a solution that permanently fixes this problem appears soon!

Doesn't anyone have any idea if this has been fixed yet, or whether it even affects people who are not running Suricata?  Those of us who are temporarily away from home are afraid to upgrade our routers for fear of them losing contact with the Internet after a day or so.

OPNsense has always been so reliable and problem free, and now this!

I too would like to know if this has been resolved.

Does this problem affect people who are not running Suricata, I ask because I thought I had read where someone said it does?

We are also seeing an issue with memory usage, prior to the last upgrade it never got above about 4% but in this new version it just keeps climbing over time.  Now when we reboot it shows 4 to 5% but over the space of several hours it just keeps climbing, so after 24 hours it's up to 13%.  It's a remote system (relative) so we can't let it get so high that it crashes, but the weird part is that no one is even home this week so there should only be very minimal traffic through the router.  And we are not doing any really advanced type stuff, it's basically just acting as a router.

We have no idea where to even start to look for the problem, but again, we're not advanced users so some of this discussion has been completely over our heads.  We do see quite a bit of firewall traffic (about a page full of entries in a minute and a half), and a lot of it is labelled "Default deny rule" but we don't know what to make of that.

Has anyone actually figured out what the problem is, and is there a fix in the works?

Thank you, I very much appreciate this clear and simple explanation!

[EDIT: Never mind, I got a clear and easy to understand explanation in a different part of this forum. I am leaving this post up, but probably won't be checking back for a while so no further response is necessary.]

EDIT:  Never mind, I got a clear and easy to understand explanation in a different part of this forum.  I am leaving this post up, but probably won't be checking back for a while so no further response is necessary.

OMG.  You sound like a person who, if your child asks why the sky is blue, would haul out a physics textbook... I honestly did not understand half of what you wrote!

I thought I was asking a simple question in my first paragraph.  If you set up DNS over TLS in Unbound, there are three fields to fill out (not counting the checkbox that enables it).  The first two are pretty much self explanatory, all I was wondering was what are good servers to use in the USA, and you did answer that when you wrote about CloudFlare and Quad9, both of which I have heard of.  But my other question was about the "Verify CN" field and in that regard your answer was not at all helpful.  No, I haven't looked into how DoT works, because I would not understand anything more than the most superficial of explanations anyway.  What I have deduced out is it's more secure than regular DNS (or at least not LESS secure), and it bypasses your ISP's DNS.  And that's really all I need to know.

My specific question was in regard to the "Verify CN" field.  This seems to be something newly added in OPNsense and all I really need to know is if it's necessary to put anything in that field, and if so, what.  I really don't need a long technical explanation.  With all due respect, your reply was rather condescending and pretty much designed to tell me what an idiot I am when it comes to this stuff.  Well, I already know I'm an idiot when it comes to this, if I weren't then I wouldn't need to ask this question.  But it just astounds me that you would make the effort to write all that verbiage and still not answer the one simple question of what, if anything, I need to put in the "Verify CN" field (assuming I am going to use CloudFlare and Quad9).  And yes, I am aware that they can see my DNS queries, but I'd rather have them seeing them than my ISP, particularly if their servers are more reliable (which is a pretty low bar).  But then again, can't any DNS over TLS provider that you might use see your queries?

As for your last paragraph, you said "OPNsense ships by default in resolver mode, which means all of your DNS queries are sent in plaintext so that your ISP (or anyone else) in the middle can potentially see them, but the queries are sent randomly to hundreds of various root servers and the local Unbound service within OPNsense resolves them and caches them."  And I am guessing you think that's a GOOD thing.  What if I don't want my DNS queries sent to random root servers all over the globe, particularly in plaintext?  I do not see how that is in any way an advantage.  Honestly, I read everything you wrote, and understood some of it, but really wish you'd skipped most of that and just told me about the CloudFlare and Quad9 servers (thank you for that, at least), and what to put in that "Verify CN" field, if I need to put anything at all there.

    I followed the instructions from here and it worked fine https://homenetworkguy.com/how-to/configure-dns-over-tls-unbound-opnsense/

As other have mentioned, those instructions appear to be for a slightly older version.  Now under Unbound DNS in the left hand menu there is a sub-page for DNS over TLS, which appears to make it easy to add this feature.  However if you go there and click + to add a server, it asks for the Server IP and Server Port, both of which are pretty self-explanatory, but there is also a field that says "Verify CN" (the help text says, "Verify if CN in certificate matches this value").  There is nothing that indicates whether this is an optional value, and no explanation of how you would find a CN for any particular DNS over TLS server.  Does anyone know how to fill this in correctly?  Can you just ignore it, and is it safe to do that?

Your post seems a bit off topic given that with the 21.7 series, the developers actually added a separate DoT section in Unbound. Input the IP, DNS name, and port and that's it. It doesn't get much easier than that. Both OPNsense and pfSense do a good job at mainstreaming DoT and not having a huge technical barrier in place.

The more complex configuration you see in this thread would be for users that wish to try something a bit more performant than Unbound DoT. Thus we have to setup a separate resolver for DoT and forward internal Unbound queries to that resolver (Stubby/getdns).

The reason this is complicated is that there really isn't a single solution for all of the examples that you give. If you want IPS/IDS, there's no way to know for sure that your traffic will be the same as another use case. That's why a) its complicated to configure and b) you need to know your traffic and device use cases. These cases rarely fit in to the "I just want a checkbox and done" crowd.

Thank you for explaining all that.  I took a look at the Unbound configuration and saw what you are talking about, the only thing I don't really understand is that there is a field for "Verify CN" (the help tip is "Verify if CN in certificate matches this value") but I am not sure what you are supposed to put there.  If you look at the list of servers in the top post there is nothing indicated as a "CN"; I do see that most have "tls_pubkey_pinset" entries but I assume that's not the same thing.

The other thing is there are no default or suggested entries; in a way I can understand the logic behind that but in the OP's list I see no servers that look even remotely familiar, so basically someone with no experience or background with this is still left scratching their head wondering what to do.  What would be ideal for me is to have settings for one or two good DNS over TLS providers in the USA, or somewhere in North America.  I'm not necessarily saying they have to be Google (if Google even runs a DNS over TLS server) but it would be nice to not be going to somewhere completely unknown.  My goal here is to bypass my ISP's DNS servers, which not only are frequently down, but also if I use those then my ISP can track where I go on the Internet more easily.  But I don't want to replace those with something even less reliable, or that may also be tracking where I go and selling that data who knows where, so that why I wish there were some list of recommended DNS over TLS providers and you could select one or more just by clicking a checkbox.  Or failing that, a link to an article somewhere that contains that information.

Maybe DNS over TLS is too new, or there really are that few servers that support it, if so I apologize if I am asking for too much, but I am just trying to understand if this is something that is possible. As for the comment about the article being for those "that wish to try something a bit more performant than Unbound DoT", I guess I would say that while I suppose everyone would like maximum performance (however they define that), not everyone has the time, patience, or ability to learn how to tweak things to the very max (that's as true of computer networking as it is of mechanical things such as car engines).  I would just be happy if it works reliably and doesn't become a bottleneck to network traffic.

And again, I am not in any way knocking the OP's post, I am sure there are people who like having that level of detail and the ability to fine tune their networks in ways I could never hope to understand.

To start with I am not in any way knocking you for posting these instructions, I'm sure you took a lot of time to write them up and for that you should be commended.  But what I find incredible is that you have to go through all this in the first place.  I am sorry, but this is just WAAAAAY too difficult for any average user (and maybe some readers think only technically minded people use OPNsense, but that's not necessarily true). This kind of reminds me of the method you had to use to set up an Internet connection back in the very early days of Windows, until Microsoft came out with a version of Windows that made setting up network connectivity relatively painless.

What OPNsense needs is a page specifically for enabling DNS over TLS, that would be used by both OPNsense itself and by any device on the local network that uses the OPNsense IP address for DNS (including devices that use DHCP to get their network connectivity information).  And that page should have exactly two things:

• A checkbox to enable or disable DNS over TLS
• A textbox with a list of servers capable of receiving DNS over TLS queries (and/or alternately, checkboxes to enable or disable certain popular and well-known servers)

And that's ALL.  If anything else is needed then OPNsense should assume sensible defaults, and not trouble the user about them.  For those that simply must have the ability to tweak, you could have an Advanced Settings section, but this should be pre-populated with a working configuration.

Features that are hard to use don't get used, except by a very small minority that actually has the knowledge and patience to use them.  OPNsense is really bad about making some features much harder to use than they should be.  Another example of this is intrusion detection - that's another one that ideally should be "just click on a checkbox to turn it on and done (unless you really have a burning desire to tweak the advanced settings)."  When you need an article this long to explain how to do something that should be drop-dead easy, that's a real design failure.  Look at how easy it is to turn on DNS over HTTPS in Firefox - you go to the Network Settings and click one checkbox at the bottom of the Connection Settings pane, and either use the default provider or use a custom one.  That's how easy it should be in any decent router software!  And I HOPE that is how easy it will be in some future version of OPNsense.

Sometimes what should be the simplest questions are the hardest ones to find an answer to.  I just want to set it so that when OPNsense goes out to get updates, etc. it uses Google's DNS rather than my ISP's, because my ISP's DNS is horribly slow.  I am hoping that you do not have to make changes in Unbound, because it seems that when people do that they then have all kinds of DNS issues.

I found these settings, if I just enter the DNS I want to use in those fields will that be sufficient, or is that for some other purpose entirely?

I'd like to see it also.

Thanks for that.  I didn't realize those were curl options, I thought they were API options.  If they are curl options then

-k allows curl to proceed and operate even for server connections otherwise considered insecure.

-u specifies that user:password follows

-v makes curl verbose during the operation (probably would not want this unless debugging).

Now it makes sense, I think!

[Using curl]

Just read the docs about API usage, then in your browser type F12 and diagnose network traffic and click reboot or poweroff, then you can see the API commands the browser is using. This will also work via curl bash script.

Thank you.  Searching for info on that led me to this thread:  https://forum.opnsense.org/index.php?topic=3007.0

So I'm assuming from that this would now work in my case:

Code Select Expand

curl -XPOST -d '{}' -H "Content-Type: application/json" -k -u "APIKEY":"APISECRET" https://192.168.1.1/api/core/firmware/poweroff

But it says "Note that this requires the user to have firmware page privileges" and I assume that relates to the APIKEY and APISECRET values.  And then there is a different format given on the documentation page at https://docs.opnsense.org/development/api/core/firmware.html and from that I surmise that this simplified form should work:

Code Select Expand

curl -k -u "$key":"$secret" https://192.168.1.1/api/core/firmware/poweroff -v

So then I am wondering how you set the APIKEY/$key and APISECRET/$secret values.  I found this information at this page: https://docs.opnsense.org/development/api.html#introduction

The $key and $secret parameters are used to pass the API credentials using curl. You need to set these parameters with your own API credentials before using them in the examples:

Code Select Expand

key=w86XNZob/8Oq8aC5r0kbNarNtdpoQU781fyoeaOBQsBwkXUt
secret=XeD26XVrJ5ilAc/EmglCRC+0j2e57tRsjHwFepOseySWLM53pJASeTA3

Now that would be helpful, if only it told where to get that key and secret.  I wish whoever wrote that page would have taken the extra ten seconds to create a link, something like "How to set up API credentials."  Anyway on that page it says:

API keys are managed in the user manager (system_usermanager.php), go to the user manager page and select a user. Somewhere down the page you will find the API section for this user.



Click on the + sign to add a new key. When the key is created, you will receive a (single download) with the credentials in one text file (ini formatted). The contents of this file look like this:

Code Select Expand

key=w86XNZob/8Oq8aC5r0kbNarNtdpoQU781fyoeaOBQsBwkXUt
secret=XeD26XVrJ5ilAc/EmglCRC+0j2e57tRsjHwFepOseySWLM53pJASeTA3

So I am assuming that once you get the text file you open that up and use the key and secret from that.  But also on that same page it says:

Using curl

Simple testing with curl is also possible, the sample below uses the same credentials, but ignores the SSL certificate check (-k) for testing.

Code Select Expand

curl -k -u "w86XNZob/8Oq8aC5hxh2he+vLN00r0kbNarNtdpoQU781fyoeaOBQsBwkXUt":"puOyw0Ega3xZXeD26XVrJ5WYFepOseySWLM53pJASeTA3" https://192.168.1.1/api/core/firmware/status

And schedule the actual upgrade of all packages using:

Code Select Expand

curl -XPOST -d '{"upgrade":"all"}' -H "Content-Type: application/json" -k -u "w86XNZob/8Oq8aC5hxh2he+vLN00r0kbNarNtdpoQU781fyoeaOBQsBwkXUt":"puOyw0Ega3xZXeD26XVrJ5WYFepOseySWLM53pJASeTA3" https://10.211.55.100/api/core/firmware/upgrade

So, yet two more forms of the curl command, and I have no idea which is the correct one to use.  For example in the second example curl command above there is a -v at the end of the line but in the third example which also uses the simplified form there is no -v, and believe it or not I cannot find where in the documentation it explains what those options do.

This a case of documentation written for programmers rather than for users!  I don't mean to be too critical because at least there is documentation, but this is probably why many users never even try to use some of the advanced features of OPNsense - the documentation that explains how to do it isn't written for us.  Look at how many pages I had to go to in order to find this information, and even then I still have the unresolved question of which form of the curl command is correct.  And I still have no idea what the -k, -u, and -v options do because I simply could not find any page where those are explained!