OSPF over IPsec (keeping sessions alive in multi-ISP VPN failover)

[dmor]

Can anyone confirm that OSFP over IPsec will prevent existing sessions from breaking in the event of a multi-WAN scenario with 2 actively-connected tunnels and OSPF simply dictating the best route for a given packet?

I realize that Untangle as a firewall is "session-based". However, OSPF by nature is Layer 3 and session-agnostic. Further, the function of OSPF is to have multiple routes in the routing table at all times, and then to choose the best route with each packet that needs routed.

So I'm hoping OSPF over IPsec would be a feasible way to have a multi-ISP tunnel scenario where sessions do not break if the primary/preferred ISP fails (so long as the secondary/backup ISP is still up).

Basically separating the routed interface from the session.

I would appreciate any feedback on this.

-
Doug

[sky-knight]

The session layer is above the networking layer, any changes in the networking layer by definition breaks all sessions.

When you have a WAN failover event, any sessions depending on that WAN link WILL terminate. OSPF doesn't change this, all OSPF or any other dynamic routing protocol does is allow a router to automatically find a new path to allow new sessions to establish via another path. It's an automated repair engine to minimize downtime, it doesn't actually prevent downtime.

That still doesn't confirm if Untangle's OSPF implementation can work over multiple tunnels. I've not had cause to try that yet.

[dmor]

The session layer is above the networking layer, any changes in the networking layer by definition breaks all sessions.

When you have a WAN failover event, any sessions depending on that WAN link WILL terminate. OSPF doesn't change this, all OSPF or any other dynamic routing protocol does is allow a router to automatically find a new path to allow new sessions to establish via another path. It's an automated repair engine to minimize downtime, it doesn't actually prevent downtime.

That still doesn't confirm if Untangle's OSPF implementation can work over multiple tunnels. I've not had cause to try that yet.

Rob,

OSPF is more than what you describe, when you take it out of the context of a firewall / Layer 4 session-oriented device. OSPF's origin's (and I suspect still the vast majority of its use, is not even on firewalls that deal with Layer 4 (sessions). It is a layer 3 protocol used primarily on routers (normally routers don't even deal with or know about sessions.
OSPF is agnostic to sessions, and OSPF was not created as a repair mechanism to find a new path for broken sessions.

It is abound redundancy and survivability. It just dynamically adds/removes additional routes to the routing table, and changes the metric for each based on changes to the upstream topologies.

In reality I could accomplish what I want with OSPF by having the multi-ISP connections NOT on untangle, but instead an upstream (next hop) router or SD-WAN device. This way Untangle always sends all sessions out the same WAN interface (to the SD-WAN device), and therefore Untangle's routing table never changes, and thus it doesn't break any sessions in the event of WAN failover. Untangle wouldn't even be aware of an upstream WAN failover.

Because if OSFP is separated from the Layer 4 session-oriented device (Untangle), then all OSPF is doing is helping whatever router it is on make the best decision on where to route every packet that comes in. Packet by packet (Layer 3). It doesn't know or care about sessions, and there's no impact or relationship to sessions.

Meanwhile, Untangle is agnostic as to how the packet reaches Point A to Point B after it has sent it to the next hop device. Untangle has done its part, and the upstream infrastructure is responsible to get the packet there by whatever routes are available. These routing changes are happening constantly via BGP on the internet, and our VPN tunnels will regularly ride different paths without breaking the tunnel, because it doesn't matter what path the packets ride to get between Point A & Point B beyond their own locally attached interfaces. After leaving the local interface, there is no control or visibility, and you just let dynamic routing on the internet take care of that for you.

But I do get your point, and think you were really summarizing the above in the context of Untangle. I just know how you love technical conversations, so figured I'd round this one out. :-)

I have a ticket open with Untangle support and they are looking into whether what I want to do is possible. My hope is that if they don't currently have this ability, they will add it in the near future, so we can maintain this survivability of sessions without having to add another device upstream adjacent to the Untangle firewall. I'd prefer not to add another point of failure to each end of the VPN, and also appreciate the visibility and control we get with Untangle having so much functionality in one box.

Cheers.

[dmor]

Perhaps to summarize it would be worth stating that OSPF (and other dynamic routing protocols) exist to keep things (sessions) from breaking. Not to fix them (or help create a path for new sessions) after they break (although they do this implicitly).

[sky-knight]

All any dynamic routing protocol does is configure layer 3, and if layer 3 breaks layer 5 breaks too. You can put all the lipstick you want on that pig, but I don't care what level gear you're using. If a route falls over, and OSPF has to redirect things to a new gateway every single session that was using the old route just collapsed.

But, thanks to the magic of TCP and UDP most of the time we just don't care. But it really does greatly depend on what protocol you're using at the time.

That does bring up the curve ball though...

If the VPN tunnels are all privately addressed, and the source and destination are communicating "directly", if the path changes do they care?

But the tunnels themselves are using a connection that just died, and the secondary route popped up. So with the transport layer just taking a nose dive on the tunnel that collapsed... who saw it?

Honestly, a good portion of that just makes my head hurt. Fortunately, for most applications the connection firing back up in a few nanoseconds using a new route means all of this just doesn't matter anymore.

Fun side note... noticed the Internet being strange lately? The core Internet routers in Dallas have been a bit... strained. It's making things... WEIRD.

[dmor]

If layer 3 has redundancy & is a device indepentent/upstream from the firewall or endpoint device, 1 failed/broken path won't break the existing session. It is a *proactive* solution, rather than a reactive one. OSPF, BGP, etc. will all do this for you if they are separated from the firewall session interfaces. But with Untangle, it seems (having it all on one box), you lose this benefit.

Fun side note... noticed the Internet being strange lately? The core Internet routers in Dallas have been a bit... strained. It's making things... WEIRD.

Yes. Comcast upload horrendously slow yesterday.

[gravenscroft]

Can anyone confirm that OSFP over IPsec will prevent existing sessions from breaking in the event of a multi-WAN scenario with 2 actively-connected tunnels and OSPF simply dictating the best route for a given packet?
Doug

I can officially deny that this is the case. As sky-knight has said, if the session breaks, the session remains broken. Dynamic routing isn't relevant at that point: the session's failed regardless of what routes are available. If it's TCP traffic and the session originator will automatically re-send, then great! The new session will use the new route. The old one's dead, though, and depending on what kind of traffic it is, there will be an interruption from the failed session.

[dmor]

I can officially deny that this is the case. As sky-knight has said, if the session breaks, the session remains broken. Dynamic routing isn't relevant at that point: the session's failed regardless of what routes are available. If it's TCP traffic and the session originator will automatically re-send, then great! The new session will use the new route. The old one's dead, though, and depending on what kind of traffic it is, there will be an interruption from the failed session.

With Untangle doing the dynamic routing, it seems yes.

With the dynamic routing happening upstream & Untangle being agnostic to it, that is not necessarily true. I think a session in Untangle (and any application that uses TCP) will tolerate a lost packet without breaking the session/connection.

[gravenscroft]

Sure, anything's possible if you change the nature of the question! In this case, I will defer to sky-knight's considerable expertise as I can really only speak to Untangle products.

Have fun, you kids!