Ping return interface/route

Hi
I have a multiple ISP config with two default routes with different distances which is changed with a netwatch script. This works fine for letting the router control the route/ISP used. Now our secondary ISP want to monitor the other way too and ping the router on it’s WAN2 IP to confirm the availability of their service all the way and they normally don’t see any traffic as secondary so they can’t simply watch for that. Primary ISP get a reply but the secondary simply won’t since the route for them is not active because of the route distance metric. What happens is that ping request from ISP2 arrive on WAN2 IP (secondary) and reply is sent out on WAN1 IP (primary) where I think ISP1s router/firewall blocks it because it did not see the initial request and opened a connection. Or the ISP2 monitoring IPs could also be unreachable via ISP1 because they could be in a ISP2 DMZ or something. I guess there are several possible reasons here and which a customer have no control over.

How can I solve this in the best possible way? I think similar cases to this must be quite common so maybe there a “standard” way one should solve it?
I could of course add static routes via the gateway on IP2 for ISP2s monitoring host(s) if they are static but this feels like a fragile solution.
The best solution I could think of (which I of course don’t know if possible) is if there was a way/option to return pings on the interface they arrived on against the route distance priority. Maybe by somehow using NAT rules and tagging traffic so the return patch is altered from using the default lowest distance route?

Kind regards
David