Unbound with VPN (was: IPv6 only upstream and IPv4 forwarders) [SOLVED]

Started by dmgeurts, December 16, 2024, 11:07:26 PM

Previous topic - Next topic
December 16, 2024, 11:07:26 PM Last Edit: December 17, 2024, 09:32:49 PM by dmgeurts Reason: Solution found
New to OPNsense and struggling to work out a fully working unbound DNS config.

Remote firewall, connected via VPN. It only has a public IPv6 address as that's what's used for the VPN. And so it has IPv6 DNS servers configured and these work fine for DNS resolution. I can resolve from the CLI fine with this.

What doesn't work is getting unbound to respond to IPv4 requests on the LAN interface. Traffic is permitted, but unbound won't respond to IPv4 requests. IPv6 works fine.

So to recap:
host google.com                  <<< works
host google.com 127.0.01        <<< works
host google.com ::1              <<< works
host google.com 192.168.1.1      <<< doesn't work
host google.com 2a01:blah::blah  <<< (public IP on the WAN interface, also works)

WWW <IPv6> firewall <IPv4> LAN

I eventually will have an IPv4 address on the WAN, but right now I was hoping to be able to test if an IPv4 client can resolve a public domain.

Equally, I haven't got the forwarders working yet for the internal domain. I don't know if this is due to the same problem or something else. I can resolve via direct query via the VPN, so there's no firewall rules blocking this. How does one debug unbound on OPNsense? The logs in the UI are pretty sparse. The config is pretty default: No ACL (yet), no overrides, internal domain added to `Private Domains`.

I briefly dabbled with Dnsmasq where for the forwarders I could set a source IP address. It seems this isn't possible for unbound, though I don't know if this is needed. Maybe I need to configure the VTI mode so that unbound can find the DNS servers better via the VPN.

I'm connecting to another site of mine and was hoping to avoid running a DNS server on another host at this remote site. The VPN is to a Palo Alto firewall and so far things have been working fine without using route based (VTI). But it appears that unbound requires VTI as per this log entry:

Error    unbound    [35197:1] error: udp connect failed: Network is unreachable for 192.168.10.22 port 53 (len 16)

Under Services -> Unbound DNS -> General, is "Network Interfaces" set to "All"?

If that's not it, you might try setting "Outgoing Network Interfaces" there too...

December 17, 2024, 01:58:17 PM #2 Last Edit: December 17, 2024, 01:59:56 PM by dmgeurts
Quote from: dseven on December 17, 2024, 10:15:19 AMUnder Services -> Unbound DNS -> General, is "Network Interfaces" set to "All"?

Yes, it is, so it should respond to both IPv4 and IPv6.

Setting outgoing Network interfaces, I only have the LAN and WAN options, not the VPN. Changing this to WAN doesn't fix anything. From the firewall itself:

user@fw01:~ $ host ilse.nl ::1
Using domain server:
Name: ::1
Address: ::1#53
Aliases:

ilse.nl has address 76.76.21.164
ilse.nl has address 76.76.21.61
ilse.nl mail is handled by 1 aspmx.l.google.com.
ilse.nl mail is handled by 10 alt3.aspmx.l.google.com.
ilse.nl mail is handled by 5 alt1.aspmx.l.google.com.
ilse.nl mail is handled by 5 alt2.aspmx.l.google.com.
ilse.nl mail is handled by 10 alt4.aspmx.l.google.com.

user@fw01:~ $ host ilse.nl 127.0.0.1
Using domain server:
Name: 127.0.0.1
Address: 127.0.0.1#53
Aliases:

ilse.nl has address 76.76.21.61
ilse.nl has address 76.76.21.164
ilse.nl mail is handled by 5 alt2.aspmx.l.google.com.
ilse.nl mail is handled by 10 alt4.aspmx.l.google.com.
ilse.nl mail is handled by 1 aspmx.l.google.com.
ilse.nl mail is handled by 10 alt3.aspmx.l.google.com.
ilse.nl mail is handled by 5 alt1.aspmx.l.google.com.

user@fw01:~ $ host ilse.nl 192.168.1.1
;; connection timed out; no servers could be reached

So this proves that unbound can resolve public domains fine via IPv6 and unbound is the only thing listening on port 53:

user@fw01:~ $ sudo sockstat -l -46 | grep 53
unbound  unbound    27263 5   udp6   *:53                  *:*
unbound  unbound    27263 6   tcp6   *:53                  *:*
unbound  unbound    27263 7   udp4   *:53                  *:*
unbound  unbound    27263 8   tcp4   *:53                  *:*
unbound  unbound    27263 9   udp6   *:53                  *:*
unbound  unbound    27263 10  tcp6   *:53                  *:*
unbound  unbound    27263 11  udp4   *:53                  *:*
unbound  unbound    27263 12  tcp4   *:53                  *:*
unbound  unbound    27263 13  tcp4   127.0.0.1:953         *:*

The timeout yields no log entries in the unbound logs and there are no firewall rules blocking access:

userfw01:~ $ nc -zvu 192.168.1.1 53
Connection to 192.168.1.1 53 port [udp/domain] succeeded!

But no response on TCP, despite seeing the traffic permitted in the firewall logs.

December 17, 2024, 02:05:57 PM #3 Last Edit: December 17, 2024, 04:49:16 PM by dmgeurts
I should add that the LAN interface is a tagged interface (opt1). And a direct IPv6 request against the self-assigned IPv6 address of this interface doesn't work either.

But, alas, switching to an untagged interface makes no difference.

December 17, 2024, 08:51:51 PM #4 Last Edit: December 17, 2024, 09:31:47 PM by dmgeurts
So, as it turns out. DNS lookups work fine until the VPN comes up. How does a VPN affect the reachability of unbound on a directly connected interface?!

Switching to dnsmasq makes no difference. So it's not unbound or dnsmasq at fault.

Which led me to check my phase 2 details on the VPN. Here I had used a supernet for the remote end and the local network was part of this network. From a routing perspective this is not a problem as more specific routes are preferred. However, when it comes to VPNs the routing tables apparently aren't checked and matching traffic is either dropped or forwarded. Bit of an oversight IMHO as now I'll need to define very specific IP address ranges for the child SAs.

Policy based IPsec takes precedence over routes. Fact for FreeBSD but also traditional Cisco IOS and whole bunch of other operating systems.

Good you were able to solve it and thanks for reporting back.
Deciso DEC750
People who think they know everything are a great annoyance to those of us who do. (Isaac Asimov)