Multipath Rules vs Static Routing (Policy Routes) ?

Static routes are static.

Policy routes might work, but they have generally been superseded by the Multipath system.

Barry

"Static routes are static."

Yes, but on most systems if an interface is down, routes attached to it are automatically invalidated.  Is that not the case with UTM?

I'm not sure, so I'll leave that for someone else to answer.

Any reason you don't want to try Multipath?

Barry

We went through it with support a while back and there was a bug preventing multipath from doing what we needed (there have been so many bugs and design flaws we've encountered in the past 4 months it's impossible to even remember the details of all of them).

In general I think my main concern with using multipath is that, unlike routing, it doesn't affect the routes of the UTM itself - this is most important for us when it comes to RED tunnels.  We like to ensure that our tunnel is going over a specific ISP, so we route all traffic to our datacenters (with a couple of exceptions) via a particular interface.  Is there a way to achieve this with multipath?

Thanks!

Is there anyone that has some insight here?  Every system I've ever worked with automatically invalidates routes that are no longer possible (i.e. if the associated interface goes down).  Does UTM not do that?  How can we achieve proper failover and traffic routing, including for RED tunnels?

OK after further research and finally being able to get someone from support connected on the phone, it looks like this is doable without having to resort to multipath (which doesn't work for UTM-level connections like RED).  The trick to making it work seems to be setting up your two gateways in an availability group: https://www.sophos.com/en-us/support/knowledgebase/120239.aspx

You can then tweak the numbers to get the failover happening the way you want it.  Not exactly the same thing as properly respecting static routing (why does the UTM interface even have an option for the metric on routes if the routes never invalidate? seems pointless) but it appears to do the trick!

Remember that WebAdmin is a GUI that creates a database that confd reads to create the command line instructions that determine how the UTM does things.  RED is an in-bound connection, so you would need a failover DNS service to get it to come in via your second ISP.

I still think you'd be better off with Uplink Balancing and Interface-persistent Multipath rules.

Cheers - Bob

Hi Bob, RED server hosts an inbound connection - RED client makes an outbound connection (unless I'm completely misunderstanding things).

At the datacenter we have a single ISP feed, and the datacenter UTM acts as server.  No need for dyndns or the like since we just have the one connection there of course.  On the client side, the offices with two ISPs have a UTM acting as client, so it automatically fails the RED initiation over to the secondary ISP if the primary fails.  The only issue was how to ensure that - when both ISPs are up and the secondary line has the default route - the RED connection was forced to go out over the primary low-latency line.

Since the UTM doesn't follow standard routing practices, the availability group is a way to simulate the same concept and ensure that invalid routes are properly dropped from the table (in effect) once one of the ISPs goes down.  I still can't understand why (and support was stumped as well) UTM even has an option to specify the metric in static routes since they never invalidate themselves - what good is it?  That KB I posted appears to be the only way to really set up proper failover routing (other than multipath, which is limited only to client traffic and not to the UTM's own routing table for its own traffic including RED initiation).

From everything I've seen and read over the last 6 months it doesn't appear that UTM has any other facility to achieve this - although I readily admit that it could have easily been overlooked while trying to manage a nationwide UTM rollout that happened to coincide right with the disastrous slew of bugs that has been 9.3!

At this point, we have 3 rather basic requirements at the client offices:
1) handle two ISPs
2) provide some way to designate one ISP as the default route (most systems you'd simply set up a pair of default routes with one having a lower metric than the other - but in the UTM world it appears that this is done by using uplink balancing and setting the weights to 100 and 0 respectively - seems to be working)
3) provide some way to ensure that RED initiation and Lync traffic flow over the non-default ISP (again normally done via static routing and/or PBR but in the UTM world you have the added wrinkle of establishing availability groups per the KB - multipath would be an option if it affected RED targeting but it doesn't).

If you can find me a way to control the interface that RED client initiation happens over using multipath I'd be open to switching, but at this point I think the availability group option is our only choice...

Thanks again for all the help you provide on these forums by the way!
Wes

trying to manage a nationwide UTM rollout that happened to coincide right with the disastrous slew of bugs that has been 9.3!

Wes - Oh, man!  The last nine months have been the worst since V5.0 was rolled out (2003?).  It's no wonder that you've been in a bad mood about these problems.  I'm sorry if I was less than cordial at any time!

I know you have a lot of these in place, but if these are RED tunnels instead of RED devices, then I would consider replacing the tunnels with IPsec using AES 128 PFS.  Much faster and much less load on the UTM. You would use Availability Groups in the datacenter UTM and an Interface Group in the sites with more than one WAN connection.  I described this in Auto-Failover IPsec VPN Connections.

You can achieve the same thing with the RED connections using Uplink Balancing in the client sites.  I wouldn't use the weighting tool to achieve this though.  Instead of a thousand words...[;)]



Cheers - Bob
PS  I suspect that your prior post describes what happens under the covers with Uplink Balancing when 'Persistence: by Interface' is specified.

Hi Bob,

that's so interesting because when I did a call with Sophos engineering prior to starting the design and rollout, they told me RED was faster and more efficient than IPsec - argh!

Thanks for the screenshots - so are you saying that creating a multipath rule for RED traffic will affect the RED tunnels being initiated by the UTM itself - and not just any RED devices that happen to be sitting behind it?  That also contradicts what I was told by support (that the only way to affect the interface that a UTM's own RED tunnels would initiate on would be to use a static route) - argh!!!

We can certainly go back and gradually shift over to IPsec down the road...  We deployed SG230s in the colos based on the fact that they basically won't have to do much at all other than these tunnels, so hopefully they will hold up with RED in the interim.  Do you have any documentation/comparison stuff I can check out for red v. IPsec?

Definitely looking forward to putting 9.3 behind us and enjoying the UTM world after 17 years of working with good ol screenOS...!