core

core copied to clipboard

Important notices

Before you add a new report, we ask you kindly to acknowledge the following:

• [x] [ I have read the contributing guide lines at https://github.com/opnsense/core/blob/master/CONTRIBUTING.md
• [x] I am convinced that my issue is new after having checked both open and closed issues at https://github.com/opnsense/core/issues?q=is%3Aissue

Describe the bug The firewall is the main DNS server through Unbound DNS. All clients have the address of the firewall as the destination DNS address. There is a second DNS server in the domain controller (domain.local).

Users are in VLANx and make a DNS request "domain.local". Therefore, DNS requests for "domain.local" must be forwarded to the domain controller in VLANy. In "Services: Unbound DNS: Query Forwarding" the domain server is configured as forward address. The "Unbound DNS Access list" allows the connection.

The problem is that the users are not getting a DNS response (both PING and NSLOOKUP).

Wireshark (Packet Capture) provide the following insight:

• client in VLANx sends a DNS request "domain.local" to the firewall;
• the firewall correctly forwards this DNS request to the Domain controller VLANx;
• the domain controller in VLANy responds to the Firewall with a response (in this case two DNS A records);
• the firewall replies in VLANx to a client's initial request back with the request without the reply.

VLANx (request from client to firewall and no repsonse)

VLANy (request from firewall and response back)

To Reproduce

• Configure a second DNS server in a second VLAN;
• Set the second DNS server as "Query Forwarding"';
• Send a DNS request which can affect the second DNS server;
• see the result in the first VLAN.

Expected behavior The expectation was that the DNS response will be passed in OPNSense to the other VLAN.

Describe alternatives you considered No known alternative.

Screenshots See item Wireshark capture

Relevant log files Wireshark logs as picture

Additional context No

Environment OPNsense 22.1.10 (amd64, OpenSSL).

Thank you for creating an issue. Since the ticket doesn't seem to be using one of our templates, we're marking this issue as low priority until further notice.

For more information about the policies for this repository, please read https://github.com/opnsense/core/blob/master/CONTRIBUTING.md for further details.

The easiest option to gain traction is to close this ticket and open a new one using one of our templates.

What is the reason that my post does not comply with the policy?

looks normal, removed the incomplete tag

I don't understand why this doesn't work and how it is supposed to work, but I have found that if you, instead of on the 'Query forwarding' page, add the forward on the 'Overrides' page on the 'Domain Overrides' tab, it does work as expected.

In both cases I can see the override getting added to the configuration. The query forwarding things are added to /var/unbound/etc/dot.conf and the override things are added to /var/unbound/etc/domainoverrides.conf, as far as I could tell with the same syntax. So I don't understand why the result is different.

This is possibly a side effect of https://github.com/opnsense/core/commit/161d24650b6020393b57238c0a0d4e40110dc6d3.

Can you share (and if necessary sanitize) the output of /var/unbound/private_domains.conf when a domain override is configured?

Do you have DNSSEC enabled?

@RHeijmans @tinus-github Can you try # opnsense-patch f3efe39f7 and restart Unbound to see if it resolves the issue?

Context: https://github.com/opnsense/core/commit/f3efe39f7b7e182bb77a7dd3a371fe4c5c054585

I can confirm that with this patch applied, using the Query Forwarding pane works as expected. I did try applying the patch again to remove it, but then it kept working. I am not sure what is going on, I do not know this software well enough.

I did try applying the patch again to remove it, but then it kept working.

Likely Unbound wasn't restarted after removing the patch. If it was, the response was probably cached as the default behaviour between restart is to reload the existing cache.

@RHeijmans Can we close this ticket?

@swhite2

I am rebuilding the environment, to test your solution.

I am familiar with the override function and basically it works. However, the goal is that the second DNS server solution is a redundant environment of two domain controllers.

Therefore, an override solution is not useful. The domain controller should control which addresses (both, or a specific one) are returned as DNS.

I'll be back soon if the patch works.

Do you have DNSSEC enabled?

No, it isn't enabled

@swhite2

I am rebuilding the environment, to test your solution.

I am familiar with the override function and basically it works. However, the goal is that the second DNS server solution is a redundant environment of two domain controllers.

Therefore, an override solution is not useful. The domain controller should control which addresses (both, or a specific one) are returned as DNS.

I'll be back soon if the patch works.

@swhite2, Patch # opnsense-patch f3efe39f7 indeed works for me too. With this patch, the request from another VLAN is neatly passed through the firewall to the correct VLAN. Thank you for your support!

Is it possible that this will be included in the next update? How does this work?

You should be allowed to close the ticket.

@RHeijmans Glad to help! If all goes well, this patch should make it into the next release. I am however considering expanding on this a bit as the code which fixes your problem is based on "expected behaviour" as it was implemented for Domain Overrides, which I don't really agree with. For now this is a good solution.

Yes, this will be available in 22.7.3.