Problem's making a failover vpn connection + static routes. Advice???

Option 1 would work when you tick 'Bind tunnel to local interface' box. With this ticked, the VPN will NOT make a route to the network and you can create one yourself with a different metric....

But how would you configure this if you cannot set a static route for the same destination network?

For Reference (replaced ips):

• Network 1 - 172.16.1.0/24, UTM_1 - 172.16.1.250, MPLS_GW_1 - 172.16.1.230
• Network 2 - 172.16.2.0/24, UTM_2 - 172.16.2.250, MPLS_GW_2 - 172.16.2.230
• IPSec tunnel created between public WAN ip's with "Strict Routing" OFF, "Bind Tunnel to local interface" ON.

The original routes would look like:

• "Gateway Route | 172.16.2.0/24 via 172.16.1.230 | metric 5" (route to network 2 via mpls_gw_1 from internal interface on utm_1)
• "Gateway Route | 172.16.1.0/24 via 172.16.2.230 | metric 5" (route to network 1 via mpls_gw_2 from internal interface on utm_2)

So then how do you add the secondary route over the ipsec-tunnel? Cant use a gateway route because the same issue occurs (same destination network). Interface route doesn't make sense because the ipsec-tunnel isn't a defined interface.

Am I missing something?

edit: more details

Hi, Corey, and welcome to the UTM Community!

In fact, I believe you can have two separate Static Routes to the same subnet.  Did you try with different metrics?  I know I've done this in the past, but maybe it was with Policy Routes???

Cheers - Bob

BAlfson said:

In fact, I believe you can have two separate Static Routes to the same subnet.

Hey Bob,

Not according to the GUI you cannot. This is the message you get if you try to configure two static routes (diff metric, diff gateway, same dest subnet) in the UTM.

Regards,

Corey

I'm having the exact same problem as Corey.

I have a static route to a remote network. I've set this metric to 1 (static route metric). I need to configure an additional route to the same network, with a higher metric, through my alternative path, in case the first one goes off.

If you try to do so, the GUI presents you with the same error message Corey-FTK pasted.

This is a common routing functionality, I can't understand why Sophos can't do it. What are metrics ther for in this case?

Just to add some interesting information:

I've figured out a way around the stupid GUI of Sophos UTM regarding Static Routes. It's completely retarded.

I was enabling the same configuration on my other end hoping to test the priority and stumbled into this behavior.

Check this out:

In this end, I have a Network Group (instead of a normal Network object), which contains the multiple remote networks I want to add a fallback route to. Notice the Network Group is exactly the same on both rules.

Note the group is EXACTLY THE SAME in both rules, thus hey contain the exact same networks.

Now you just enable both and... voilà! Stupid GUI lets you do it without complaining with that unbelievably idiotic error message.

Now, back to reality, if you try to do so with a normal Network Object...

Again, same object, but now they are of 'Network' type (not a group with multiple, identical ones). Then, you get the stupid message that doesn't know what a goddam 'Metric' stands for.

Then, to work around this, I've created a Network Group object, inserted some stupid single address object (WHICH IS ALREADY INSIDE OF THIS SAME NETWORK RANGE!!!!) and

Voilà!

Seriously.... this....

Now I need only to check if the system will abide by those. I wonder that it'll do.

Thiago, this is a new glitch in WebAdmin.  If you are on V9.506, please open a ticket with Sophos Support to make sure this bug is addressed.

Cheers - Bob

BAlfson said:

Thiago, this is a new glitch in WebAdmin.

Hello BAlfson,

Yes, v9.506002 here (latest stable so far).

By "new glitch" you mean exactly what? The 'workaround' of adding Network Group objects instead of just Network Objects, or the behavior of the GUI telling you cannot add multiple routes to the same network, regardless of metric?

I as this because I was able to trace reports of the same issue (not being able to add metric routing) back in 2014, which is a long time.

Regards,

Good Morning,

I believe that this KB responds to this behavior.

Link: https://community.sophos.com/kb/en-us/120239

No, Caio Silva, the KB doesn't. What it does is to tell you to use Availability Groups as a substitute for routing metrics, which is a standard in every single network/routing device.

I'd already stumbled into KB 120239 before posting here; it is definitely NOT an acceptable substitute for routing metrics even though it CAN act as a workaround. Also, as suggested by BAlfson, opened opened a case in Sophos (Case 7784640) to understand why Sophos UTM has a Metrics field imbued in the Static Routing configuration if the product itself will completely refrain from it.

Answer from Sophos was:

I believe as you stated that this is "normal UTM behaviour"  although it may not be what your used to seeing with other vedors and devices. This is how the UTM operates when it comes failover routes. 

In addition to the KB you provided you can also achieve this functionality by utilizing up-link balancing in conjunction with multi-path rules (for up-link routes).

community.sophos.com/.../118457

So, conclusion is (TL;DR verion):

• Sophos wants to re-invent the wheel when it comes to routing standards;
• Sophos' Static Routing configuration section has a Metrics field with a troll tag (if the solution does NOT use it, why is it there?);
• Sophos judge themselves righteous above all when it comes to protocol standards.

PS: Just to clarify as even some Sophos Support Engineers didn't get it: Availability Groups are a great functionality overall. It enables you to work with either addresses or FQDNs and does a great job in fallback scenarios in a wide variety of applications. It is jut NOT an acceptable substitute for routing Metrics; not only because metrics are a standard or that they exist solely for handling route priority, but because they do the job way better.

Availability Groups are only useful for internet uplink based routing, nothing else. (see my OP)

Thiago Palmeira said:

Sophos' Static Routing configuration section has a Metrics field with a troll tag (if the solution does NOT use it, why is it there?)

Pretty much sums it up. They either need to fix this or allow for a "backup route" option or something. It really messed with our heads and in the end (with some help) we have just made do with a script that will toggle one route off and the other on if certain conditions are not met. The alternative was to move the routing to another device but with our uptime, we deemed it not a huge issue to have a slight delay (to manually toggle before we did the script).

quite the joke tbh. even with everything going under the hood, this shouldn't really be that big of an issue to implement (read: fix).

I would be interested if this is an issue in XG as well, but I haven't touched the product extensively of late.

I'm not sure about this in XG as well; I can't suggest XG over UTM to a single customer due to various reasons:

1. STAS does not work;
2. Logging is ridiculous;
3. Sophos Support themselves can't troubleshoot XG;
4. Bugs & Functionalities;

-- STAS --

STAS is a joke. It's not reliable, it fails to consistently collect login/logoff events and I had a Case on Sophos (6058453) for over a year (07/04/2016 to 09/21/2017) regarding those various issues where their final response (21/09/2017) was "Your issue will be resolved in STAS 3.0". We are in Jan/18; that says enough.

-- Logging --

Whoever once needed to troubleshoot and do log analysis on an XG Firewall knows what I'm talking about.

-- Sophos Support --

Whoever has called Sophos Support or had a Case on Sophos regarding XG bugs or troubleshooting knows what I'm talking about.

-- Bugs & Functionalities --

STAS is a major one. EVERY single customer we have want SSO authentication mainly for proxy due to obvious reasons; refraining from it is not a viable option to anyone and it's been a pain since launch. If you use XG functionalities you find them - or they find you; Changelog tells enough.

Besides, UTM still has functionalities XG doesn't. Rather ordinary things like Smart Relays for example: XG was only able to work with them recently with last release (v17).

I wanted to like XG. I lured customers into getting XG. It's definitely a shoot to the feet. XG needs work, logging in XG needs a lot of work. SSO authentication needs a solution. I can't recommend XG for anyone and will definitely not dump UTM for it.

I'm not sure about this in XG as well; I can't suggest XG over UTM to a single customer due to various reasons:

1. STAS does not work;
2. Logging is ridiculous;
3. Sophos Support themselves can't troubleshoot XG;
4. Bugs & Functionalities;

-- STAS --

STAS is a joke. It's not reliable, it fails to consistently collect login/logoff events and I had a Case on Sophos (6058453) for over a year (07/04/2016 to 09/21/2017) regarding those various issues where their final response (21/09/2017) was "Your issue will be resolved in STAS 3.0". We are in Jan/18; that says enough.

-- Logging --

Whoever once needed to troubleshoot and do log analysis on an XG Firewall knows what I'm talking about.

-- Sophos Support --

Whoever has called Sophos Support or had a Case on Sophos regarding XG bugs or troubleshooting knows what I'm talking about.

-- Bugs & Functionalities --

STAS is a major one. EVERY single customer we have want SSO authentication mainly for proxy due to obvious reasons; refraining from it is not a viable option to anyone and it's been a pain since launch. If you use XG functionalities you find them - or they find you; Changelog tells enough.

Besides, UTM still has functionalities XG doesn't. Rather ordinary things like Smart Relays for example: XG was only able to work with them recently with last release (v17).

I wanted to like XG. I lured customers into getting XG. It's definitely a shoot to the feet. XG needs work, logging in XG needs a lot of work. SSO authentication needs a solution. I can't recommend XG for anyone and will definitely not dump UTM for it.