Dual OVPN site to site links

[xternal]

MODS: I moved this from Multi-WAN forum, as more relevant here - please close other thread

Hi,
I have an issue which I dont know if I can solve. I have two OPVN connections linking two sites.
Currently using Quagga I can get failover to work, where when one connection goes down it updates the routing table to use the next one.
However, it would be awesome if I could have both ovpn connections mapped concurrently and then use firewall gateway rules to redirect certain traffic over each line.
I dont need dynamic load balancing, I just want to use gateway rules to make VOIP connect over one ovpn and computers over the other.

Quagga identifies the 192.168.1.1 network is available on both opvnc2 and ovpns1 (each side has a server and a client)

Heres the quagga routes working properly

So what i would like to change here, is force a second route like the circle but for the 10.0.11.1 gateway (so I can setup firewall gateway rules for both vpn connections).
Currently, even if I setup ovpn gateways by assigning interfaces to the ovpn connections, it still always routes down one vpn connection (the first one connected) because of the rule at the arrow… i think.

Using a firewall gateway rule forcing traffic through 10.0.11.1 still travels over the 10.0.10.0/24 ovpn connection because of that rule?

Is it possible to force a second gateway for 192.168.1.0/24 in the routing table? Set to 10.0.11.1

[heper]

not possible as far as i know. You should check with developers to be sure.

I believe it is a limitation of the underlying OS.

[phil.davis]

If you don't need OSPF for other things (like routing in a big internal VPN network) then you should be able to do this without Quagga OSPF. You will have a gateway for each OpenVPN connection. Both gateways happen to be routes to the same LAN subnet at the other end - that is fine. You can use policy routing firewall rules (like you are trying already) to feed whatever traffic you like into whichever gateway. With no Quagga OSPF, the "strange" route for 10.0.11.1 that pushes that traffic down the wrong pipe will not be there.