Perfect, your post is very clear and helpful to understand the requirement; it is in the same lines as what I assumed in my earlier post.
This design is not a straightforward VPN design, at the same time - it is not impossible.
The primary issue is what you have highlighted in your post - only one default route will be active on the spoke. So, all VPN negotiations will happen only through one ISP. The way around this is to split the ISPs into their own routing domains ie., configure 2 VRs and bind each ISP to its own VR. Now, both ISP links and routes will be active at the same time.
Let us assume Comcast is in VR-A and Frontier is in VR-B.
Next ==> configure 2 VPNs, one through each ISP, pointing to the same peer - the hub. Create 2 tunnels, one in each VR and bind the VPNs to their respective tunnels.
Next step => Let us say 10.0.3.0/24 is a part of VR-A. Add a route in VR-A, saying to reach 10.0.1.0/24, use the tunnel in the same VR (Comcast). Add another route, to reach 10.0.2.0/24, go to VR-B.
In VR-B, add a route to 10.0.2.0/24, using the tunnel for Frontier.
The second issue: The hub side has no way to deteermine which tunnel to send the return traffic through, because the spoke subnet is always the same.
Some workarounds I can think of:
- perform bidirectional NAT-ing on the spoke on both tunnels, so hub can route traffic back easily
- disable reverse route lookup on the hub -> this is a global setting and can affect other traffic
- use source based routing on the hub, to choose tunnel.1 or tunnel.2 based on the source
The third concern: I would assume you would also want to achieve ISP redundancy i.e, if one ISP is down, route all traffic through the live ISP. If yes, then you can add more routes and modify the preference values.
Let me know if this helps..