Messages

P.S. Michael Schnerring's guide is great. I can confirm that in 2025 you can still implement his approach to sending Unbound traffic through the VPN tunnels but for Mullvad, in addition to those steps I just posted you also have to set up your Mullvad device to disable DNS hijacking via a CLI call.

Hey there idleDiplomat,

The solution that worked for me is to configure the VPN gateways as outside your subnet, and then have Unbound pass outbound traffic from the firewall through those gateways. So, you make the VPN gateways Far Gateways in System > Gateways > Configuration > [edit each gateway], also make them upstream gateways, allow default gateway switching under Systems > Settings > General, and assign those gateways a priority that is higher (a lower number) than the WAN interface. Then you configure Unbound to let the operating system take over deciding what interface to pass traffic out, by deselecting all interfaces under Services > General > Unbound DNS > [select "advanced"] > Outgoing Interfaces.

See here for more links, and here for a guide that's better than my hastily-rendered walls of text.

Happy policy making!

Other related references are here.

Also here's a Reddit post describing why not to use DNS service IP addresses to ping the gateway monitors, and here's a person who succeeded at that task and who describes why you have to enable default gateway switching and set the VPN gateways in the gateway group as upstream and higher priority (i.e., lower priority number).

(Doing some reference organizing over here.)

[Services > Unbound DNS > General > [select advanced]]

Thanks FredFresh, this helped me very much.

I'd add for other people researching this, under Services > Unbound DNS > General > [select advanced], under "Outgoing Network Interfaces" deselect all interfaces so that "All (recommended)" shows up and Unbound then will allow the operating system to select what interface to use, and so traffic will go out the default gateway.

I was able to get DNS resolving working through a Mullvad VPN connection. I first noticed that Mullvad hijacks DNS requests, so to get Unbound's resolver to pass through the VPN I used Michael Schnerring's approach, sending a CLI request to Mullvad's site to establish a new device that does not use DNS hijacking. Then, for single connections (i.e., not gateway groups), I referred to landinggear's post, set up the VPN tunnel gateways as far gateways, and passed DNS traffic through the gateway for the VPN tunnel using a rule applied to outbound traffic from the firewall, monitoring the VPN exit points and setting up static routes through the WAN interface for the monitors to ping the exit points. I enabled default gateway switching. I also configured Unbound to pass traffic through all interfaces and made sure my desired VPN tunnel was a default gateway with the highest priority. That worked, short of failover. When I then set up a gateway group, updated my floating rule to send traffic through it, and made sure the failover group gateways use the new failover and failback features, I ran into what appear to be implementation issues for OPNSense 25.1.7-12 that affect the way monitoring and default gateway switching takes place. That keeps failover from working smoothly: when the primary gateway goes down the monitors don't catch it and the firewall rules don't change. The behavior doesn't look like a configuration error, I hope that gets sorted out soon.

See also here for how to set up the routes to the endpoints.

Hey willie93,

Newbie here. I couldn't view screenshots here because Imgur blocked my VPN and also didn't state the reason I couldn't view the images. I thought it was an issue with my browser. Then I edited your URL link like so and everything worked. So I can finally view your screenshots and reply.

That tutorial you referenced is helpful. In case you haven't seen it, for failover also check out this walkthrough by Christian McDonald, which is for PfSense but works just great with OPNSense. He talks through his selection of the gateway address. He also explains why you need to use two separate Mullvad devices to generate configuration files for each VPN peer and instance (which you've done, since the tunnels are different). For the gateway, I've had luck using the tunnel address plus an offset as granute and McDonald suggest. For the gateway monitoring, I first created static routes to the public VPN endpoints as explained in landinggear's walkthrough that modifies this official tutorial for use with pushing Unbound DNS traffic out the VPN tunnels. That worked for me with using Unbound in forwarding mode, although more recently I'm encountering issues that look a lot like bugs in default gateway switching and monitoring when using both Unbound DNS in resolver mode and setting up failover.

Anyway, I think if you're getting Mullvad to resolve your DNS traffic for you, that walkthrough by landinggear should do the trick!

[System -> Gateways -> Configuration -> [edit gateway]]

Hi Maurice,

Have you tried selecting "Failover States" and "Failback States" in System -> Gateways -> Configuration -> [edit gateway]? Those may be new features as of May (at least the documentation was committed in May). Also I have been experiencing similar problems with gateway failover, but with the default route not going to the secondary gateway when the primary goes down. Here is the post, and some bug reports connected to gateway monitors and default gateway switching. It could be that our problems have the same cause.

I've been seeing that message too, and so far have ignored it. Just confirming the behavior.

Following up, I filed four bug reports: 1, 2, 3, and 4.

[pluginctl -c monitor]

Update: the behavior persists in version 25.1.12. It's actually worse: I restored my configuration that uses the gateway group (the initial post here), then tested disabling the VPN instance for Tunnel A. The monitors did not detect the gateway as down and there was no default gateway. Restarting the dpinger for Gateway A detected it as down, but Gateway B was not designated the default gateway. So that's the behavior I was in version 25.1.11. Now previously I then disabled Gateway A and the default gateway was assigned to Gateway B. This time I disabled Gateway A and still there was no default gateway. Running pluginctl -c monitor did not change that. Not even reloading all services in the CLI restored a gateway group. I had to reboot the firewall, and then Tunnel B was detected as the default gateway and traffic now passes through Tunnel B normally. Yuck!

[netstat -rn | grep wg]

I did some more digging around and can reproduce this glitch without designating a gateway group and just using ordinary default gateway switching.

I also restored an earlier configuration that did not use a gateway group. With this configuration, Gateway A for VPN Interface A is what would normally be Tier 1. It's got a priority of 225 and is preferred. Gateway B for Interface B is what would normally be Tier 2 (but there's no gateway group). It's got a priority of 227 and is next best. Default gateway switching is enabled. Both are upstream and far gateways. Failover and failback is enabled for both.

The firewall rules are not particularly relevant because I'm sure there's nothing going wrong with them, but basically I have separate rules for passing web traffic from my local network out Gateway A (the priority), and as a second rule I pass LAN traffic out Gateway B. Then I have two floating rules for passing outbound traffic from the firewall through Gateway A as a priority, and Gateway B under that. So, when testing what I think is a bug here without using a gateway group, I disable the instance for VPN Interface A under my Wireguard settings, click "Apply" and also disable and re-enable Wireguard, then disable the LAN firewall rules for Gateway A and the floating firewall rule for passing outbound traffic from the firewall through Gateway A. (For the NAT rules, I have separate NAT rules for the VPN Tunnel A interface and the VPN Tunnel B interface and they're both enabled and remain so for the duration of this test. So those are uninteresting.)

Starting with both gateways and VPN instances enabled, I have DNS and web traffic properly passing through VPN Tunnel A as seen through the live log. I can see with netstat -rn | grep wg that the gateway address for Tunnel A is listed as the default gateway. Next, I disable Interface A under my Wireguard VPN settings. Just as before with a gateway group, the gateway for Tunnel A is still green and the monitor shows no change in activity and the Tunnel A gateway still shows up in System -> Gateways -> Configuration as active. So, under System -> Diagnostics -> Services, I restart the dpinger for Gateway A and now it shows up as stopped. In System -> Gateways -> Configuration, the status of Gateway A is now red, the gateway is enabled, and Gateway B is now listed as "active". However when I run netstat -rn | grep wg I see that Gateway B does not show up as a default gateway (and there is no default gateway). And no traffic is going through Gateway A or Gateway b now (my connection is hanging, for both web traffic and DNS). Manually disabling Gateway A in System -> Gateways -> Configuration then causes Gateway B to show up as a default gateway as seen by netstat -rn | grep wg , and DNS and web traffic is now flowing through VPN Tunnel B.

I'm not clear, when not explicitly using a gateway group with failover, if the intended behavior of the software is for Gateway A to have to be manually disabled in order for Gateway B to show up as the default gateway. I thought that I checked this behavior for OPNSense 21.1.7_2 before upgrading to 21.1.11, and I did not have to disable Gateway A explicitly for Gateway B to take over as the default gateway when Interface A went down. Regardless, with a gateway group established, there should definitely be no need to disable Gateway A (and indeed that's impossible, at least through the GUI). Looks like it's time for me to revert to a previous version of OPNSense as restarting the monitors isn't enough to get the default gateway to switch.

Is anyone else able to reproduce this problem?

[netstat -rn | grep wg]

Hang on, I wasn't thorough with my testing after putting that cron job in place. I'm able to start the monitors just fine, but now I can see that when I disable the Tier 1 gateway, the Wireguard tunnel designated as Tier 2 is not showing up as the default gateway (via netstat -rn | grep wg), despite default gateway switching being enabled, the Tier 2 gateway being designated as an upstream gateway, and both the Tier 1 and Tier 2 gateways having "Failover" and "Failback" checked in their settings. Also I'm not getting traffic going through the Tier 2 gateway. (Also, now there is no default gateway.)

[/usr/local/opnsense/service/conf/actions.d/actions_restart_monitors.conf]

As a workaround, I was able to create a cron job that restarts the gateway monitors every minute.

I created a file, /usr/local/opnsense/service/conf/actions.d/actions_restart_monitors.conf:

Code Select Expand

[run]
command:/usr/local/sbin/restart_monitors.sh
parameters:
type:script
message:Restarting gateway monitors
description:Restart gateway monitors

And the script in /usr/local/sbin/restart_monitors.sh is just:

Code Select Expand

/usr/local/sbin/pluginctl -c monitor
(Make sure that script has execute permissions:

Code Select Expand

chmod 755 /usr/local/sbin/restart_monitors.sh)

Then run

Code Select Expand

service configd restart and test with

Code Select Expand

configctl restart_monitors run
And with it working, restart the web GUI or just reboot, and go into System -> Settings -> Cron and add a new Cron job to restart the gateway monitors every minute.

I tried having my script to restart the monitors run two calls to /usr/local/sbin/pluginctl -c monitor, sleeping for 30 seconds in between, but that seemed to cause the webGUI to delay during startup, so I think the sleep command might get called synchronously by something important during startup.

Anyone know a nice way to get OPNSense to run cron jobs more than once per minute? I'd prefer a faster-than-30-second wait on average for my connection to re-establish during failover.

Thanks!