Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

Unbound issue with logging and OpenVPN after rebooting OPNsense #2791

Closed
JasMan78 opened this issue Oct 4, 2018 · 16 comments
Closed

Unbound issue with logging and OpenVPN after rebooting OPNsense #2791

JasMan78 opened this issue Oct 4, 2018 · 16 comments
Assignees
@fichtner
Labels
bug Production bug
Milestone
19.1

Comments

@JasMan78
Copy link

JasMan78 commented Oct 4, 2018 •
edited
Loading

Introduction: First I thought I've a problem with Unbound combined with OpenVPN. But after some tests with a completly fresh installed OPNsense in Hyper-V I think this is only an Unbound issue which effects OpenVPN too. Therefore I renamed this opened issue. Sorry for the confusion.

Some basic informations.
Version: 18.7.4
Installed on self-configured hardware (Intel(R) Celeron(R) CPU J1900 @ 1.99GHz (4 cores)) and as Hyper-V VM for tests with an fresh installation
Issue appears: after each reboot of OPNsense

Issue:
I raised the log level verbosity of Unbound from 1 to 2 to get every DNS query logged. I've noticed that when I restart my OPNsense, the logging stoppes or falles back to log level verbosity 1. DNS querys are not logged anymore.
I've to restart the Unbound service to get the logging working as configured in the log level verbosity settings of Unbound.

If this issue happens the DNS resolving for OpenVPN clients only is not working. LAN clients are not affected. They can resolve internal and exteranl DNS names. So I guess Unbound is not completly hanging or stopped. After restarting Unbound the DNS resolving for the OpenVPN clients works fine again.

I've also noticed that after restarting the service the FQDN DNS record of my OPNsense contains the IP address of the management interface, and the IP address of the virtual OpenVPN interface. Therefore when I try to access the WebGUI, and my client resolves the OpenVPN IP for the OPNsense FQDN, I get timeouts and of course a lot of deny entrys in the firewall logs because this interface is not configured for the WebGUI access.

Name: jaswall.mgmt.home.arpa
Addresses: 192.168.1.1
192.168.15.1

The fresh installed OPNsense VM is configured with the basic settings like WAN and LAN interface only. No additional plugins or services are running. But it shows the same behaviour as my productive OPNsense.

I'm not sure if this are two completly different problems, or if an Unbound issue causes this behaviours.
@JasMan78 JasMan78 changed the title Unbound stops logging when OpenVPN service is running Unbound issue with logging and OpenVPN after rebooting OPNsense Oct 7, 2018
@fichtner fichtner self-assigned this Oct 16, 2018
@fichtner fichtner added the bug Production bug label Oct 16, 2018
@fichtner fichtner added this to the 19.1 milestone Oct 16, 2018
@fichtner
Copy link
Member

@JasMan78 let's start with the verbosity issue. can you verify that /var/unbound/unbound.conf verbosity changes back to 1 after reboot?

# grep verbosity: /var/unbound/unbound.conf

@JasMan78
Copy link
Author

@fichtner The verbosity level is still 2 after a reboot. It looks like the logging of at least Unbound has completely stopped.

@fichtner
Copy link
Member

does this only happen with verbosity 2 or also 1 ? after reboot+in conjunction with OpenVPN I mean

@JasMan78
Copy link
Author

JasMan78 commented Oct 17, 2018 •
edited
Loading

Also with verbosity 1.
After a reboot of OPNsense the internal and external DNS queries from VPN clients are not answered by Unbound. LAN clients get an answer. When I restart the Unbound service, the DNS resolving for the VPN clients is working again.

fichtner added a commit that referenced this issue Oct 17, 2018
@fichtner
unbound: set up a full chroot including local log socket #2791
2d5d392
@fichtner
Copy link
Member

fichtner commented Oct 17, 2018 •
edited
Loading

Unbound chroot is not so nice, I've changed it to what dhcpd is getting... Try the patch. It requires a reboot to take full effect:

# opnsense-patch 2d5d392

Cheers,
Franco

@JasMan78
Copy link
Author

I've installed the patch on my VM OPNsense, but same issue after rebooting it.
I'm not sure if the installation was successfull. Here's the output:

# opnsense-patch 2d5d392

Hmm...  Looks like a unified diff to me...
The text leading up to this was:
--------------------------
|From 2d5d392bc2b722ab9f52aeb624d42317a78288fb Mon Sep 17 00:00:00 2001
|From: Franco Fichtner <franco@opnsense.org>
|Date: Wed, 17 Oct 2018 17:23:45 +0000
|Subject: [PATCH] unbound: set up a full chroot including local log socket
| #2791
|
|---
| src/etc/inc/plugins.inc.d/unbound.inc | 12 ++++++++++++
| src/etc/inc/system.inc                |  2 +-
| 2 files changed, 13 insertions(+), 1 deletion(-)
|
|diff --git a/src/etc/inc/plugins.inc.d/unbound.inc b/src/etc/inc/plugins.inc.d/unbound.inc
|index 9a3a18589..a15809375 100644
|--- a/src/etc/inc/plugins.inc.d/unbound.inc
|+++ b/src/etc/inc/plugins.inc.d/unbound.inc
--------------------------
Patching file etc/inc/plugins.inc.d/unbound.inc using Plan A...
Hunk #1 succeeded at 431 (offset 13 lines).
Hmm...  The next patch looks like a unified diff to me...
The text leading up to this was:
--------------------------
|diff --git a/src/etc/inc/system.inc b/src/etc/inc/system.inc
|index eb3fa39bc..594525092 100644
|--- a/src/etc/inc/system.inc
|+++ b/src/etc/inc/system.inc
--------------------------
Patching file etc/inc/system.inc using Plan A...
Hunk #1 failed at 693.
1 out of 1 hunks failed--saving rejects to etc/inc/system.inc.rej
done

@fichtner
Copy link
Member

Indeed, system.inc needs patching. Sorry about the hiccup. Can you manually change it and do another reboot?

2d5d392#diff-460dfc2bc3262765b55473c6f9b38003R696

Use this after edit to make sure it boots ok:

# php -l /usr/local/etc/inc/system.inc

@JasMan78
Copy link
Author

No problem, but I don't understand what I should do now or what I should "manually change".

@fichtner
Copy link
Member

I can send you a working patch if you tell me which version that patch needs.

@JasMan78
Copy link
Author

Oh, stupid me.
Now I understand what you want me to do. Of course I can change the files manually. I will try to do it during today or tomorrow. Thank you in advanced for your help.

@fichtner
Copy link
Member

No worries, thanks for your help.

@JasMan78
Copy link
Author

I've changed the files but the issue remains after reboot.

@JasMan78
Copy link
Author

JasMan78 commented Oct 19, 2018 •
edited
Loading

Sorry, I made a mistake. I tried to resolve a domain via the WebGUIs interface diagnostic tools this time. But as I just noticed those requests are not logged by the Unbound log. I guess they're directly forwarded to the external DNS resolver.

The Unbound logging is fine now after I've changed the files and rebooted OPNsense.

EDIT: The change had no impact to the other problems: right after the reboot DNS for my OpenVPN clients is not working, and the DNS record for the FQDN of my OPNsense contains only the management IP address. When I restart the Unbound service, DNS for my OpenVPN clients is working again, but the IP address of the virtual OpenVPN interface is added to the DNS record of my OPNsense.

@fichtner
Copy link
Member

hold on, the subject says "Unbound issue with logging and OpenVPN after rebooting" and that's what was worked on. Did the previous fix it?

If yes, what is the second problem in an isolated manner and wouldn't it be better to create a separate ticket for this to avoid "endless" tickets? :)

@JasMan78
Copy link
Author

Yes, changing the two files fixed the Unbound logging issue. 👍

OK, I understand.
Just want to inform you that the fix had no impact to the other issue(s) I have with Unbound DNS. I will open a new support tickets for this.

@fichtner
Copy link
Member

Thanks, then I will close and ship the logging fix in 18.7.6 and will take the other issue as soon as it's there :)

fichtner added a commit that referenced this issue Oct 22, 2018
@fichtner
unbound: set up a full chroot including local log socket #2791
c246acb 
(cherry picked from commit 2d5d392)
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees

@fichtner fichtner

Labels
bug Production bug
Milestone
19.1
Development

No branches or pull requests
2 participants
@fichtner @JasMan78