Unbound DNS Resolver, Domain Overrides to IP across OpenVPN tunnel interface.
SimpleOne last edited by SimpleOne
With reference to this thread:
I can confirm exactly the same issue. The problem is that Unbound doesn't seem to see the OpenVPN tunnel interface as a valid interface to send queries from. If you try to set Unbound to use the LAN interface for outgoing queries (the LAN interface in my case can hit the HOME LAN with no problems in either direction) it still doesn't work. It seems like the routes available via the OpenVPN tunnel aren't visible to Unbound (the firewall itself passes traffic between REMOTE_LAN<>HOME_LAN and PFSENSE_LAN_INTERFACE<>HOME_LAN without issue). All DNS resolution for queries directed out the WAN interface do work (i.e. a query from REMOTE_LAN_HOST to ARBITRARY_DOMAIN will resolve successfully via the WAN interface with no issues). As soon as you add a domain override for ARBITRARY_DOMAIN and try to get the query sent via the OpenVPN tunnel, precisely nothing happens; no query is sent down the tunnel (confirmed via pcap on that interface). There are no firewall rules blocking traffic in any direction across the tunnel.
The old DNS forwarder does work in this scenario.
A crap work around is to run them simultaneously (resolver on the standard UDP 53 and forwarder on UDPSomeOtherPort) and use a domain override within the unbound resolver that is pointed at the internal DNS forwarder. Honestly though, that's a hack, this should be fixed properly.
And your going to have to post more info - just like in that other thread.
I just simulated this. I created a dns server using 2k12r2 on my local network, my wlan 192.168.2/24 at 192.168.2.12
I then created a forward lookup zone home.lan, I then created a record host.home.lan 10.10.10.10
In unbound I created a domain override pointing home.lan to 192.168.2.12. I then setup unbound to be able to use the wlan interface 192.168.2.253 (pfsense wlan IP) as outbound query.
Now my remote vpn client using pfsense as its dns was able to query host.home.lan without any issues.
Here is the thing. Unbound has ACLs - do you allow the vpn tunnel network to query unbound? Out of the box the automatic acls only allow for networks pfsense is directly attached to query - I do not believe it would allow a tunnel network IP to query it even. So you have to adjust your unbound acl's. You also have to worry about rebind protection in unbound. When unbound forwards, or queries outbound to roots even.. If a record returns rfc1918, it would not hand that off to the client asking.. So you need to setup in your unbound options setting that domain, home.lan in my case as private.
server: private-domain: "plex.direct" private-domain: "home.lan"
This is simple enough to test what happens. Can your remote vpn client query pfsense dns? Or do you get a servfail? Can pfsense query your local dns?
Happy to help you figure out the piece your missing, but need more info. But as I understand what your trying to do - as per that other thread have a vpn client query pfsense through the vpn, and then have a domain overfide to let unbound query a local dns this works just fine if correctly configured.
The thread you linked to is not about sending unbound outbound a client vpn connection, its about inbound to unbound from a remote vpn client.
What are you routes that would have pfsense/unbound use the vpn client connection? Lets see your setup and we can figure out what is not right with it.
SimpleOne last edited by SimpleOne
Thanks for the input. I did get this working to an extent as well. I haven't posted the steps I took as yet because I'm still doing a stocktake and tidy up to workout what of it all was really required. Roughly it looks like the below:
Set your OpenVPN client endpoint to have a static IP using client specific overrides on the OpenVPN server side.
Add any appropriate routing/NAT between the OpenVPN client endpoint and the internal DNS server that you want to query and make sure there is no firewalling blocking anything. Make sure you are accounting for the fact that the request is coming from the tunnel subnet IP assigned to the OpenVPN client endpoint.
Add ACL for the OpenVPN tunnel subnet (or at least the static /32 of the OpenVPN client endpoint specified as the outgoing interface below).
Add 'Custom Options' in the Unbound Resolver running on the OpenVPN client endpoint to specify the outgoing interface(s) for Unbound:
- server: outgoing-interface: OPENVPN_TUNNEL_STATIC_IP
- server: outgoing-interface: WAN_IP
Save and apply the changes and then restart the Unbound service.
(Optional: Confirm that queries are now at least being sent from your OpenVPN Client endpoint across the tunnel by doing a PCAP on the OpenVPN interface filtering on port 53. Test queries from hosts on the LAN of the OpenVPN client endpoint as well as queries from the OpenVPN client endpoint itself).
SimpleOne last edited by
I will get back to this thread with some better information (fixed or otherwise), but I'm just running out of time at the moment. I believe the issue is mostly fixed by the bits above, but there are some other issues outstanding. For instance, it seems that Unbound is querying the domains as specified in the domain overrides, only via the OpenVPN tunnel (good), but some quick pcaps I did indicated that it was simultaneously appending the pfsense's local domain suffix to those same queries, and trying to resolve them out the WAN interface in parallel. This was occurring even with the Unbound zone set to static in the GUI.
I haven't done enough systematic investigation at this stage, suspect it's just a config issue to nail out. First though, I'm going to upgrade the hardware that pfSense is deployed on and rollout 2.4.X as currently I'm still running x86 and 2.3.6-dev. I don't want to waste more of anyone's time if it only occurs in an outgoing architecture (and if it is indeed a bug/limitation, rather than just my own config issue, which is what I'm starting to suspect it is).
This thread looks like someone bumped into the same 'append the local domain and try to resolve' issue before me here:
Also sounds like it was prior to there being a zone type setting in the GUI for Unbound, which I have been running as static in my config. I'll do some more reading. For anyone else's reference, this is very helpful (unsurprisingly): https://www.unbound.net/documentation/unbound.conf.html
The manual in combination with rummaging through the following should produce some corrections/answers/fixes for me in time:
/etc/inc/unbound.inc (and friends)
/etc/var/hosts (and friends)
Thanks again for the response and info @johnpoz
it was simultaneously appending the pfsense’s local domain suffix to those same queries,
That would be your client using suffix search that has nothing to do with unbound. Unbound would never nor could it add a suffix to a query. it is only going to resolve or forward what is asked of it.
And yeah since there is no override for it, yes it would try and resolve it the normal way. You can stop those from happening by changing your zone type to static. I personal think this should really be the default zone type vs transparent.