Another approach you could take is leaving them both connected all of the time. If you don't care which one is primary then that is all you need to do. If they are both active, the router will do some kind of crude load-balancing between them (not that it matters, they are sharing the same WAN connection). If one goes down, it will be removed from the routing table and not used until it reconnects.
If you do care which one is primary, then you can write a simple vpn script to change the routing table to lower the priority of the one you don't want to use.
Create a file
/jffs/scripts/openvpn-event with the below commands, it will run every time a VPN tunnel changes states
#!/bin/sh
route del -net 128.0.0.0 netmask 128.0.0.0 dev tun12
route del -net default netmask 128.0.0.0 dev tun12
route add -net 128.0.0.0 netmask 128.0.0.0 dev tun12 metric 100
route add -net default netmask 128.0.0.0 dev tun12 metric 100
This assumes you want to lower the priority of tun12, which should be client 2. Setting a metric 100 sets the route at a higher cost, which tells the router to only use it if lower cost options are not available.
Note, I am recreating the routes without a Gateway, which should be fine because VPN tunnels are considered point-to-point interfaces and work without a GW. The gateway will likely change between sessions, so you don't want to hard-code it. If you want to get fancy, you could first read the existing gateway into a variable and provide it when recreating the routes. Another nice enhancement would be first checking to see if the commands need to run (is there a tun12 route? is the metric already set?). I am not a script junkie, and wanted to keep this super basic. This should work as-is, even if it isn't as elegant as it could be.
I've been banned from messing with the router in the evenings when they're all using the internet!
