DNS for Wireguard not working after reboot

Started by Kinerg, March 25, 2023, 08:29:13 PM

Previous topic - Next topic
After OPNsense reboots, my Wireguard clients don't get DNS responses. If I manually restart Unbound, everything is ok until the next reboot. I haven't seen anything useful in the Unbound log.

This has been going on (at least) for the last several OPNsense versions (23.1.4_1 currently). I can't be sure if it happened before in 22.7 or 22.1, maybe I was just lucky with timing.


After a reboot Unbound denys requests on the WireGuard interface. It a normal behavior, because the WG-interface is not yet ready when the unbound service starts after a reboot.
Simply go to Services/Unbound/Access Lists and add your WireGuard Subnet. Then it should work.

Quote from: Andi75 on March 26, 2023, 10:18:07 PM
After a reboot Unbound denys requests on the WireGuard interface. It a normal behavior, because the WG-interface is not yet ready when the unbound service starts after a reboot.
Simply go to Services/Unbound/Access Lists and add your WireGuard Subnet. Then it should work.

Should have mentioned I've tried that, sorry. No change, and Wireguard subnet is already present as an Internal allowed subnet even after reboot. But adding it again manually doesn't help.

I'm still having this issue on 23.1.7_3

Any ideas? Is it possible to delay the Unbound start or possibly set up a script to restart the Unbound service X seconds after OPNsense boot?

Quote from: Kinerg on March 27, 2023, 02:30:06 AM
Quote from: Andi75 on March 26, 2023, 10:18:07 PM
After a reboot Unbound denys requests on the WireGuard interface. It a normal behavior, because the WG-interface is not yet ready when the unbound service starts after a reboot.
Simply go to Services/Unbound/Access Lists and add your WireGuard Subnet. Then it should work.

Should have mentioned I've tried that, sorry. No change, and Wireguard subnet is already present as an Internal allowed subnet even after reboot. But adding it again manually doesn't help.

Can you post a screenshot?  I had the same problem a while back and adding it manually solved my problem.

Quote from: CJRoss on May 19, 2023, 03:04:10 PM
Quote from: Kinerg on March 27, 2023, 02:30:06 AM
Quote from: Andi75 on March 26, 2023, 10:18:07 PM
After a reboot Unbound denys requests on the WireGuard interface. It a normal behavior, because the WG-interface is not yet ready when the unbound service starts after a reboot.
Simply go to Services/Unbound/Access Lists and add your WireGuard Subnet. Then it should work.

Should have mentioned I've tried that, sorry. No change, and Wireguard subnet is already present as an Internal allowed subnet even after reboot. But adding it again manually doesn't help.

Can you post a screenshot?  I had the same problem a while back and adding it manually solved my problem.

Sure. First is the Unbound ACL list after reboot. Second is the manual ACL rule. Third is the ACL list after reboot with the manual rule added.

End result is the same and Unbound restart is required.

Quote from: Kinerg on May 19, 2023, 09:38:19 PM
Quote from: CJRoss on May 19, 2023, 03:04:10 PM
Quote from: Kinerg on March 27, 2023, 02:30:06 AM
Quote from: Andi75 on March 26, 2023, 10:18:07 PM
After a reboot Unbound denys requests on the WireGuard interface. It a normal behavior, because the WG-interface is not yet ready when the unbound service starts after a reboot.
Simply go to Services/Unbound/Access Lists and add your WireGuard Subnet. Then it should work.

Should have mentioned I've tried that, sorry. No change, and Wireguard subnet is already present as an Internal allowed subnet even after reboot. But adding it again manually doesn't help.

Can you post a screenshot?  I had the same problem a while back and adding it manually solved my problem.

Sure. First is the Unbound ACL list after reboot. Second is the manual ACL rule. Third is the ACL list after reboot with the manual rule added.

End result is the same and Unbound restart is required.

So the third screenshot is the current configuration and when you reboot OPNSense you still can't get DNS?

Quote from: CJRoss on May 19, 2023, 11:28:18 PM
Quote from: Kinerg on May 19, 2023, 09:38:19 PM
Quote from: CJRoss on May 19, 2023, 03:04:10 PM
Quote from: Kinerg on March 27, 2023, 02:30:06 AM
Quote from: Andi75 on March 26, 2023, 10:18:07 PM
After a reboot Unbound denys requests on the WireGuard interface. It a normal behavior, because the WG-interface is not yet ready when the unbound service starts after a reboot.
Simply go to Services/Unbound/Access Lists and add your WireGuard Subnet. Then it should work.

Should have mentioned I've tried that, sorry. No change, and Wireguard subnet is already present as an Internal allowed subnet even after reboot. But adding it again manually doesn't help.

Can you post a screenshot?  I had the same problem a while back and adding it manually solved my problem.

Sure. First is the Unbound ACL list after reboot. Second is the manual ACL rule. Third is the ACL list after reboot with the manual rule added.

End result is the same and Unbound restart is required.

So the third screenshot is the current configuration and when you reboot OPNSense you still can't get DNS?

Correct. I'll provide any additional info/logs if you point me where to look. Unbound log in the GUI didn't show anything obvious.

Did you set unbound to listen on all interfaces?

Quote from: zan on May 20, 2023, 05:36:41 AM
Did you set unbound to listen on all interfaces?

I haven't. Just tried it and that does fix the issue. I would like to avoid having to implement specific firewall rules for all the blocked interfaces, though. Any idea how to fix it while keeping Unbound active only on selected interfaces? I'd rather keep doing the manual restarts if nothing else is possible.

Yep unbound failed to bind to an interface when it was not ready, hence needs restarting. You can set unbound to listen on all interfaces(inaddr_any) to prevent such issue and unbound will happily serve all current and future interfaces you might create, irrespective of their states.

QuoteAny idea how to fix it while keeping Unbound active only on selected interfaces? I'd rather keep doing the manual restarts if nothing else is possible.
Unbound works best with static interfaces, so you may want to pick an address from one of your static interfaces (eg:LAN) and use it as DNS for your WG clients.
Or if you are paranoid, you can always create a loopback interface, assign a RFC1918/32 address and make unbound only listen to this interface. This way you don't have auto-added ACLs all over the place and can 'slim down' your firewall rules in one interface.

Today, it's "paranoid", tomorrow it's "pro-active" at best... Has been so the last (1)25 years, will always be that way... ;-)
kind regards
chemlud
____
"The price of reliability is the pursuit of the utmost simplicity."
C.A.R. Hoare

felix eichhorns premium katzenfutter mit der extraportion energie

A router is not a switch - A router is not a switch - A router is not a switch - A rou....

May 20, 2023, 10:05:47 PM #12 Last Edit: May 20, 2023, 10:19:17 PM by Kinerg
Quote from: zan on May 20, 2023, 04:38:50 PM
Yep unbound failed to bind to an interface when it was not ready, hence needs restarting. You can set unbound to listen on all interfaces(inaddr_any) to prevent such issue and unbound will happily serve all current and future interfaces you might create, irrespective of their states.

Since VPN interfaces are pretty common, some kind of workaround like a delayed Unbound start or forced refresh upon new interface detection would be preferable.

Is it expected to have the WireGuard network in the Unbound ACL even if the WireGuard interface wasn't ready at Unbound's initial start?

Quote
Unbound works best with static interfaces, so you may want to pick an address from one of your static interfaces (eg:LAN) and use it as DNS for your WG clients.
Or if you are paranoid, you can always create a loopback interface, assign a RFC1918/32 address and make unbound only listen to this interface. This way you don't have auto-added ACLs all over the place and can 'slim down' your firewall rules in one interface.

That would still require special firewall rules for each interface to (dis)allow routing, wouldn't it? Seems messy as a fix just for this use case. I guess I'll have to stick to manual restarts, at least reboots are rare.

I do appreciate the hints and will note them for possible future implementation.

Quote from: chemlud on May 20, 2023, 05:16:09 PM
Today, it's "paranoid", tomorrow it's "pro-active" at best... Has been so the last (1)25 years, will always be that way... ;-)
True dat  :)

QuoteIs it expected to have the WireGuard network in the Unbound ACL even if the WireGuard interface wasn't ready at Unbound's initial start?
The ACL config is created during during (re)configuration, not on the fly.

QuoteThat would still require special firewall rules for each interface to (dis)allow routing, wouldn't it?
Floating rules :)