← Back to Create

After tunnel setup

Create builds a tunnel and keeps it correct, but it does not decide which traffic uses it: that stays on core's pages, each linked from the Tunnel References table. A few reminders, not a rehash of the OPNsense documentation.

Gateway groups

Put the tunnels' gateways in a group, tiered by preference. With two WANs, the tunnels bound to your preferred WAN take the top tiers and the other WAN's tunnels the tiers below them; a second, mirrored group prefers the other WAN. A rule then chooses its preferred WAN by choosing the group. Because the plugin forces a tunnel down with its WAN, a WAN outage moves that group's traffic to the other WAN's tunnels. With one WAN, one group tiered by tunnel is enough. IPv4 and IPv6 gateways need separate groups.

Illustrative names. The IPv6 groups mirror these with each tunnel's IPv6 gateway.

Policy rules

On each interface whose traffic should use a tunnel, a pass rule with the group as its gateway and a destination that excludes local networks: an inverted alias of your private ranges (including the tailnet and ULA ranges, if you use them) never catches local traffic, whatever the rule order. Write one rule per IP version, each naming the group of its own family; core silently disables a rule whose IP version differs from its gateway's. The rule's source must also be one of the tunnel's NAT sources (Edit), or the plugin's guard drops the untranslated traffic.

Failing closed

Point policy rules at a group, even for a single tunnel. When every member of a group is down, core keeps the rule routed into tier 1, so the traffic dies in a dead tunnel instead of leaving by a WAN. A rule that names a single tunnel gateway behaves differently: while that gateway is down the rule stays active without its gateway, and its traffic leaves by the default route, unless Skip rules when gateway is down is on, in which case the rule is skipped and the rules below it decide. If you do name a single gateway, turn that setting on and add a block rule below it.

Kill states

Turn on Kill states for the tunnel gateways. Failover by itself moves only new connections; existing ones stay pinned to the dead tunnel until they time out. That matters most when a WAN outage moves a group to the other WAN's tunnels. The caveat is a jittery link: if latency alone marks a gateway down, every long-lived connection (push notifications, calls, smart-home hubs) is cut each time. There, set the monitor thresholds or the group's trigger so that loss, not delay, fails the gateway before relying on kill states.

DNS

The tunnel carries traffic; where DNS goes is a separate design decision, and there is no single correct answer. The plugin ignores the config file's DNS line and changes nothing about resolution. The common choices:

• The firewall's resolver over a WAN (Unbound resolving directly, or forwarding over DNS-over-TLS). Household DNS never depends on a tunnel's health, and local names and blocklists work for everyone. Lookups leave from the WAN while the traffic leaves from the tunnel, so services that compare the two locations can notice the difference.
• The provider's resolver through a tunnel, as the firewall's upstream. DNS and traffic come from the same place and the WAN sees no lookups. But the firewall has one upstream policy for every client, so all DNS, tunnelled or not, then depends on the tunnel. The provider's resolver is usually reachable only inside a tunnel, so it needs a static route through one tunnel's gateway, which does not fail over with the group; keep a fallback upstream.
• Per network. Give the tunnelled networks a different resolver, for example a public one handed out by DHCP, so their lookups follow the same policy rule as their traffic, while other networks keep the local resolver. Local names then need their own arrangement on those networks, and any rule that redirects DNS to the firewall must exempt them.

← Back to Create