Proposed solution for Mult-WAN Failover with Session Persistence

[dmor]

Hello Untanglers,

I've created a mock diagram which I am wondering if you think would be feasible to fit into the product in the future. Mostly I'm just wondering if there is anything inherently different with Untangle's internal architecture that would not allow a solution like this to be fairly easily added.

My understanding is that multi-WAN VPN failover always breaks all sessions because of Untangle's state table having the WAN interface listed with the session, and therefore when the WAN is no longer available, all associated sessions break.

I understand this makes sense. However, I'm wondering if it would be feasible to add a virtual bridge interface and let it be the "WAN" interface listed in the sessions table. Then use routes (static or dynamic) to determine which VPN tunnel (next-hop route) to take to deliver the packets. By separating the session from the physical WAN interface or even the VPN tunnel, my thought is this may allow the sessions table to still contain valid interfaces all the while, even when WAN interface & VPN tunnel availability changes.

Here is a quick diagram I made:

Proposed solution for multi-wan VPN failover with session persistence.jpg

I understand Untangle also has its existing internal virtual bridge network for the UVM/etc. But this potentially could make this type of solution even easier to implement, because you guys are already experts in that technology.

Anyway, I'm not asking this to be put into the solution. I believe there's a different place where we are supposed to submit feature requests. I'm just asking whether this solution would make sense and be feasible in the architecture of Untangle.

If so, then I will probably submit a feature request.

Thanks all!

[dmor]

This is a similar methodology to how Cisco keeps some of their dynamic routing protocol routing processes resilient against interface/route failures. I forget whether its OSPF, EIGRP or both that you have to attach to an actual interface. This is problematic unless you attach it to a loopback interface. Otherwise if you lose an interface, you lose your entire routing process, and it takes more time to recover, and you lose the benefit of a redundant dynamic routing protocol.

[dmor]

Any thoughts on this Untangle people?

[donhwyo]

Is there a feature request for this, I would vote for it?

[Coldfirex]

Is that how sdwan products do it?

[sky-knight]

And I'm just off in the weeds thinking... it's 2021, and modern cloud interfaces don't give a flying rip about session persistence. They simply reconnect and move on.