No access to DNS in DMZ (with WAN behind another router)

[MaxG]

I am on latest OPNsense on Proxmox Debian VM.

I have been working on solving this puzzle for a few days now, and it is doing my head in.

I am preparing OPNsense to have a mail/web/vpn server in its DMZ.
The WAN (192.168.1.2) is connected to a FRITZbox (via exposed host).

I have 3 rules in the DMZ:
1. in IPv4 TCP LAN net * DMZ net 22 (allow SSH)
2. in IPv4 TCP/UDP DMZ net * DMZ address 53 (Allow DNS)
3. in IPv4* DMZ net * * * (Allow any for testing)

I have a Debian LXC in the DMZ that can ping (due to floating rule allowing ICMP), but cannot nslookup when rule 3 is disabled. It can nslookup when enabled.

So why is rule 2 not allowing DNS for this host?

I have DNS servers in System | Settings | General (9.9.9.9 and 1.1.1.1) using the WAN_GW.

Happy to provide more info; any hints appreciated.

[Patrick M. Hausen]

1. in IPv4 TCP LAN net * DMZ net 22 (allow SSH)

That one belongs on the LAN interface. Wherever the packet first enters the firewall. With source LAN net that is LAN.

2. in IPv4 TCP/UDP DMZ net * DMZ address 53 (Allow DNS)

What DNS server does the system on which you tried nslookup have configured? Is it really the IP address "DMZ address"? Or is the system trying to reach an outside server?

You can explicitly specify a server with nslookup, e.g.: "nslookup www.google.com 192.168.2.1"
Try your "DMZ address" explicitly.

[viragomann]

I have DNS servers in System | Settings | General (9.9.9.9 and 1.1.1.1) using the WAN_GW.

This setting is only used by OPNsense itselft, but not by Unbound DNS.

I guess, you container request a different DNS server.
To force all DNS traffic to Unbound you can redirect it to the interface address or to localhost with a NAT port forwarding rule.

[MaxG]

Try your "DMZ address" explicitly.

DMZ is 192.168.3.0/24 DMZ address is .1
nslookup google.com 192.168.3.1 --> works when rule 3 is disabled. (I also got rid of rule 1, actually had this one in LAN as well)

cat /etc/resolv.conf
# --- BEGIN PVE ---
search grenkowitz.lan
nameserver 8.8.8.8
nameserver 1.1.1.1
# --- END PVE ---

This setting is only used by OPNsense itselft, but not by Unbound DNS.

Hmm, I am not sure where to set the DNS servers for unbound, but I stumbled over "Rebind protection networks" in Services | Unbound | Advanced, and it lists all private networks, including 192.168.0.0./8. Is this a problem for my set-up?

---

While searching the web, I found this: "To set DNS servers for Unbound in OPNsense, navigate to Services > Unbound DNS > DNS over TLS to add encrypted upstream DNS servers like Cloudflare (1.1.1.1) or Quad9 (9.9.9.9), entering the server IP and the appropriate Verify CN hostname. Crucially, you must also blank out the DNS servers on the System > Settings > General page and disable the "Allow DNS server list to be overridden by DHCP/PPP on WAN" option to ensure Unbound exclusively uses your specified upstream servers."
Shall I try this?!

[Patrick M. Hausen]

You need to configure 192.168.3.1 as the DNS server for the system in the DMZ then - either manually or via DHCP.

[viragomann]

Hmm, I am not sure where to set the DNS servers for unbound,

Unbound uses root servers for name resolution by default.
If you want to use it a certain DNS server you have to configure it in domain override.

[Patrick M. Hausen]

Unbound uses root servers for name resolution by default.
If you want to use it a certain DNS server you have to configure it in domain override.

Correct, but none of this applies to what the client in the DMZ uses in this scenario. The OP needs to fix the configured DNS server for the client regardless of what OPNsense uses.

[viragomann]

Correct, but none of this applies to what the client in the DMZ uses in this scenario.

Combined this with the DNS redirecting as I suggested in the first post here, he would get what he want though.

[MaxG]

Hmm, being the novice I am, changed the resolv.conf to:

Code Select Expand

# --- BEGIN PVE ---
search grenkowitz.lan
#nameserver 8.8.8.8
#nameserver 1.1.1.1
nameserver 192.168.3.1
# --- END PVE ---


# [2025-09-11 07:18] root@DNS ~ #
nslookup google.com
Server:         192.168.3.1
Address:        192.168.3.1#53

Non-authoritative answer:
Name:   google.com
Address: 142.250.67.14
Name:   google.com
Address: 2404:6800:4006:80a::200e

... which resolves... not sure if the is was the correct way of doing, but it works. So does rule 2 now.

[Patrick M. Hausen]

If the resolv.conf is manually configured on this system, this is the correct way.

[MaxG]

If the resolv.conf is manually configured on this system, this is the correct way.

Thank you; I do appreciate all the feedback I am getting.

It is actually clear to me now, why this has to be with a) the rule and b) resolv.conf. Having a nameserver where the server has neither a route nor access to it, it will not resolve, unless the firewall (and that's its job) provides access to it. In my case, my rule was correct, but the resolv.conf wasn't. Changing resolv.conf to point to firewall's interface (for the, here, DMZ network) allowed the server to reolve DNS. Both, resolv.conf and DNS rule need to exist for the name resolution to work.