Half-educated guess: When the issue happens again, check if the relevant source-IPs have existing sessions for the DNS traffic. If yes, check which egress interface was chosen. You can also try clearing the sessions, and then check if that "magically" solves the issue.
What I'm thinking: When the tunnel is down (=when the internet connection is down), your only route towards the DNS servers, normally reachable through the tunnel, might be through your WAN interface due to the default route matching it. If that happens, and there is a firewall policy that could allow this traffic, then that traffic likely also gets source-NATed to the WAN IP, which makes that session be "stuck" to the WAN egress route until it ends.
UDP sessions are closed based on timeout (no traffic seen), so if your client (the app) periodically sends some UDP traffic with the same source ports (you mentioned "queries come from five or six source ports") it is theoretically possible for these UDP sessions to be kept alive forever and thus forever stuck to egressing out of WAN.
If this is your case, the typical solution is to create a blackhole route with the worst admin distance (255) for the destination subnets of the VPN tunnel(s). This ensures that packets destined to the remote destinations will be dropped when the tunnel is down.
For what it's worth, modern FortiOS versions automatically create the blackhole route when the tunnel creation wizard is used, so there is a chance that you have such a blackhole route already. If you have it then this reply might not be relevant for you. (unless the blackhole route(s) do not cover the relevant destinations)
[ corrections always welcome ]