Thread Info
  • State
  • Locked Locked
  • Replies 7 replies
  • Subscribers 2 subscribers
  • Views 17769 views
  • Users 0 members are here
Options
Suggested
This discussion has been locked.
You can no longer post new replies to this discussion. If you have a question you can start a new discussion

Distributing Remote Access SSL VPN IP Range in OSPF

n8xja

I have several UTM's and I'd like to announce the remote access ssl vpn ip range to the other UTM's so that someone who is VPN'ed into one UTM can get to other places in the network as needed.  I've got everything done and route redistribution works, however, I do not see where I can add a range of IP's not connected to an interface.  I'm sure this has had to come up before, but I couldn't fine any posts. I have different IP ranges used in each of the RA SSL VPN configs so they won't collide in each of the UTMs.

Any guesses?



This thread was automatically locked due to age.
Parents
  • 0
    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!
Reply
  • 0
    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!
Children
No Data
Unfiltered HTML