Unbound Service Intermittently Stops

chpalmer

CE 2.9

At least the second time in the past week that Ive had my phone report that my WIFI has no internet.. Log into the dashboard of my pfSense and find the Unbound service stopped.

Aug 30 05:01:01 unbound 75031 [75031:4] fatal error: could not set up listen SSL_CTX
Aug 30 05:01:01 unbound 75031 [75031:4] error: and additionally crypto error:0A080002:SSL routines::system lib
Aug 30 05:01:01 unbound 75031 [75031:4] error: and additionally crypto error:10080002:BIO routines::system lib
Aug 30 05:01:01 unbound 75031 [75031:4] error: Error in SSL_CTX use_PrivateKey_file crypto error:8000000D:system library::Permission denied
Aug 30 05:01:01 unbound 75031 [75031:4] error: error for private key file: /sslcert.key

Looks like it doesn't always like my private key which is the pfSense webConfigurator Self-Signed Certificate?? My next step I suppose would be to set up a different key?

Anyone else see this kind of error at all? How to stop it? Thanks!

Gertjan

@chpalmer

The sslcert.key file and sslcert.crt files in /var/unbound/ are only used (referenced in /var/unbound/unbound.conf) if this option is set :

I'm don't think your files, these two certicate files are wrong.
It's neither the fact that they are read/write for root only, as these files are read by unbound when it is still running as root before it shift to a lower identity : 'unbound'.

What I think that is happening here :
Before unbound is started with a (new) config, a /var/unbound/test/ folder is created, all needed files, like the newly generated unbound.conf, other files and subfolders are place in this "test" folder and then unbound is started using the chroot method into this folder.
Files in that folder are accessed like /sslcert.key because the root folder for unbound is now /var/unbound/test/ so a file path like /sslcert.keyis valid.
Something went wrong with the test folder building, or the chroot failed, and now /sslcert.key is accessed from the root of the filesystem itself, the pfSense /, and that folder has no files, only folders like /etc /bin /root /sbin /usr /var etc etc

The "Permission denied" is somewhat misleading, as unbound is still running as root, so it can open any root own file with the minimal 'rw' root owner flags.

Me just thinking out loud here.
And I'm using Plus, not CE, but I think that this part of unbound management is identical.

Also, this issue has been shown before here on the forum.

johnpoz

@chpalmer said in Unbound Service Intermittently Stops:

My next step I suppose would be to set up a different key?

Do you actually have clients using dot asking unbound on pfsense? It would be rare a client to use dot, they like doh. Also any sane client would validate the cert is valid for the fqdn being used, and they trust the CA that signed it.

This isn't going to work if your just using the self signed cert meant to be used by the web gui.

I would evaluate if you should even have that checked. And if do want to serve up via dot - you should validate the cert you are using would be trusted by the client asking unbound via dot.

chpalmer

Thanks guys! I do now have my son and his wife living next door and utilizing the internet here.. she has a work router that may just be using dot.. Makes a lot of sense now truthfully. This only happened after they move in.

I am a little concerned that it would just stop the service but at least know how to proceed.

johnpoz

@chpalmer said in Unbound Service Intermittently Stops:

she has a work router that may just be using dot..

Unlikely to be honest. And you don't hand out dot via dhcp, etc. So how is it pointing to your pfsense for dot, and it sure wouldn't trust the cert. So its a borked client - the harped on advantages of dot and doh is validation you are talking to who you want to talk to via cert validation. A client that doesn't do that kind of pointless to one of the biggest selling points of dot and doh.. Sure your traffic is encrypted - but you are also validating what NS your talking to get your answers to your queries.

Your wifes router is prob just talking to unbound on normal 53 dns, and your check box to have unbound listen for dot is doing nothing. Expect maybe causing issues with starting because it doesn't like the cert or key or whatever.

chpalmer

It could actually be her device itself when she goes outside with it connecting to my main WIFI.. The job is sensitive and I don't believe her I.T. would talk to me if I asked..

They are on their own router and WIFI over there until they leave the building.. then it is mine due to my whole yard coverage. (they did allow that after she told them I was using pfSense and shared details about my WIFI setup here)..

Truthfully I initially thought a possible difference between my older Plus installed (now lab box) and my newer with CE was causing this but upon reading I see I was wrong.

I just disabled the SSL/TLS Service and will see if that causes her any problems. I might just have to get a signed certificate and go that route if needed.

bmeeks

While accepting/expecting DoT connections from internal clients is not common, it sounds like it could be this bug recently posted to the pfSense Redmine site that is impacting the OP: https://redmine.pfsense.org/issues/16937.

johnpoz

@bmeeks quick breeze over and sure could be that for sure. but yeah use of local dot is going to be very uncommon.. Dot would be normally be used in a scenario where you want your nameserver to forward to say quad9 or google or something. And because you want to hide the queries from the transport you going over (the internet) and you also want to validate you are indeed talking to quad9 or googledns.

I am not aware of any sort of client os or application software that would default to dot, doh sure.. Lots of examples of that.

Not saying there isn't any - but I am not aware of any.. They like doh - for starters its harder to block and is easy missed in normal ssl traffic, and is most always open. While dot is 853 and easy to block and spot. But both dot and doh, either need to be pre configured in the app, like browser tend to do - or would require user interaction to set it up. And if the client isn't validating the cert - its not a very good client. Sure you could prob tell it to trust an unsigned cert, but this should again require user interaction in the setup process.

I find it hard to believe some work router would point to dot on some router in front of it for dns. Maybe it might point back to a work run dot server.. Just not aware of even how that would could be setup in any automatic fashion - get the IP of the dns via dhcp - and then hope it listens for dot, and either don't check its cert or hope its signed by a valid public CA?

Encryption of dns queries don't make a lot of sense unless your transport network is hostile. You can get unbound to do doh, but there is no way to set it up in the gui. And even to use dot locally - there needs to be more thought and effort put into vs just checking a box. Because if your dot client is not validating that cert - the client isn't a very good one. So if you do happen to want to run dot and or doh on unbound.. Some extra effort should be taken that the cert you are using is going to be trusted by the client. Or your client should have to be told to use the cert anyway even if doesn't pass validation.

chpalmer

@bmeeks said in Unbound Service Intermittently Stops:

While accepting/expecting DoT connections from internal clients is not common, it sounds like it could be this bug recently posted to the pfSense Redmine site that is impacting the OP: https://redmine.pfsense.org/issues/16937.

Ive just applied that patch (at the bottom of that Redmine) and my Unbound service restarted successfully.. Time will tell.

bmeeks

@chpalmer said in Unbound Service Intermittently Stops:

@bmeeks said in Unbound Service Intermittently Stops:

While accepting/expecting DoT connections from internal clients is not common, it sounds like it could be this bug recently posted to the pfSense Redmine site that is impacting the OP: https://redmine.pfsense.org/issues/16937.

Ive just applied that patch (at the bottom of that Redmine) and my Unbound service restarted successfully.. Time will tell.

The way I understand the problem, it is a condition that results from a "reload" of unbound versus a "restart" of unbound. The unbound process is started as root but then drops privs to run as the more permissions limited unbound user. This is a common tactic for security by running processes as an unprivileged user to limit damage for any potential exploit of the process.

When doing an actual restart of the entire unbound process, everything is invoked as root and thus there are no file permission problems. But when doing a configuration "reload" instead of a full restart, the process is using the limited permissions of the unbound user account and thus hits the restrictive file permissions on the TLS keys. This is described in one of the posts in the Redmine issue. Certain pfSense operations apparently result in a reload of the unbound configuration as opposed to a full restart of the daemon itself. And it's the configuration reload that hits the file permissions issue.