Distributing Remote Access SSL VPN IP Range in OSPF

I see on the advanced tab, a place to check "Redistribute SSL VPN"

And that did redistribute as needed.

Tnx!

Interesting question and resolution!  I've not seen these options before.  I've always taken the approach described in How to allow remote access users to reach another site via a Site-to-Site Tunnel.  Please show us what you've done to accomplish this more simply.

Cheers - Bob

I'd like to know this as well [:)]

Not sure what version of OS they first appear, but this is on a 9.315 UTM. 

Glad to post how - 

Navigate to:
Interfaces & Routing -> Dynamic Routing (OSPF) -> Advanced Tab

There are options (check boxes) for all kinds of route redistribution, one of which is "Redistribute SSL VPN". 

That's all the OSPF magic required to redistribute the SSL VPN route object. [:)]

Bob -  Maybe I wasn't clear in my first post. The client has two campuses, connected by a private point to point circuit and RED connection over the internet between UTMs as a backup to the private point 2 point. I'm using ospf to decide when to use the point 2 point and when to use the red thru the metric of each path.

Interesting!  I hadn't thought of using OSPF, but that does get around some of the messiness required with an IPsec site-to-site, Uplink Monitoring, etc.  It also should mean that the failover would be sub-one-second as opposed to the almost-a-minute required to establish the IPsec tunnel.

I don't see where anyone else has described this here in the User BB or in the KnowledgeBase.  In fact, the closest thing I found is in German on Michael Klehr's blog.  Michael is an SCE-UTM.  The article he posted describes a situation when there are two RED tunnels each connected via a separate interface, so he needed Multipath rules which your solution would not have needed.  His diagrams are self-explanatory and his screencaps are with WebAdmin in English.

Here's the link.  Does that look like what you did?

Cheers - Bob

Hey Bob - The best I can tell is that Michael's network seems to be using the RED circuits to keep connectivity between sites, in his demo/test network.  My client's network had a private point to point and a UTM RED site to site vpn, but effectively whether its a UTM RED or a physical circuit, in the UTM, they are very much treated the same, so from that point of view, the networks are close enough for this discussion. 

I initially used static routes and used Availability Groups on the next hop to select routes. The down side was that I had expect that when the preferred route became available again, both the UTM's didn't cut over to the preferred circuit at the same time, which could present a problem. I never configured OSPF on a UTM but have in many Cisco routers, so I thought I would give it a try.

Using OSPF, resulted in a very quick routing convergence like you suggested, but also let me redistribute the default route (with a higher metric).  This is useful when you have a non-internet based site to site circuit, like we do have in this example. While it wasn't a deliverable defined in the scope of work, redistribution of the default route over the point to point let us back feed internet access in the case when one campus internet access goes down.

Here's a network sketch.


What I like is the simplicity of the design. The fact that testing showed that the UTM's did not swap back to the preferred circuit at the same time just gave me a "bad feeling" about unintended consequences of traffic taking paths with different latency figures.

My conclusion - OSPF + UTM RED circuits - a great combination!