Uplink Monitoring Action to Enable backup IPSec Tunnel

Hi, and welcome to the user BB!

Check out Uplink Balancing instead. 
 
Cheers - Bob

Sorry for any short responses.  Posted from my iPhone.

Hi Bob, first of all I want to thank you for the welcome, and your help. 

I have attached some configuration screenshots showing the Uplink Balancing and Uplink monitoring configuration. I can't detect where the problem is. 

Thank you very much again.

Best regards.

Hi Bob, 

I think I have found what the problem is. It seems that the uplink actions only takes effect when ALL the UPLINKS are in error state. In my case, only the Intranet interface went into Error state because the host monitored was associated to that interface, as it should, because the other uplink Interface (Internet) should be monitored with the default monitoring behavior (some host in the way up to root DNS servers).
Well, I have disassociated the monitored host from the Internal interface, and now, every time the monitored host goes down, both interfaces (Internal, and External) go into Error state, and the tunnel gets enabled. I think it doesn't makes any sense, because the external interface is the interface I use to establish the tunnel, but it works only when both interfaces are in Error state. I will do some other tests, and if it works I think I can go ahead with this configuration.

Thank you very much for your help.

Best regards.

Hi Bob, after installing the UTM in the client network it doesn't work as I expected. In lab, both FW internet interfaces (ASA and Sophos) were in the same network. In that situation, even if the "Internet" interface went to Error state it was able to establish the tunnel because it has a directly connected route. In real life it is not the case, and, if the internet interface goes to Error state, Sophos looses the routes to the ASA and it can't establish the tunnel. I even tried to specify a static route to the ASA, and it established the tunnel, but it didn't allow to pass traffic. I think it established the tunnel using the DMZ interface, that was the only one not in Error state. I saw this routes when the tunnel was Up.

10.0.102.0/23 dev eth0  proto ipsec  scope link  src 192.168.20.1 
10.0.115.0/24 dev eth0  proto ipsec  scope link  src 192.168.20.1 
10.0.117.0/24 dev eth0  proto ipsec  scope link  src 192.168.20.1 
10.0.118.0/24 dev eth0  proto ipsec  scope link  src 192.168.20.1 

Sophos support tells me it won't work, because I'm monitoring an Internal interface, not an Internet interface, but to me, both are Uplink interfaces. Do you see any solution to this situation? I just want to enable the tunnel automatically when I detect connectivity issues in the WAN. I have attached a network diagram to try to clarify the scenario.

Thank you very much.

Regards.

Hi, Joel,

I've been away much of the time over the last six weeks, and just got back to this now.  My first comment was too short.  I meant that I don't see why you would need a separate VPN definition.  Then again, I was assuming that you already have a VPN in place from the UTM to the ASA, but now I see that there's a NAT, making the existence of an IPsec VPN unlikely.

I suspect you have routing problems since the traffic over the WAN would not appear to pass through the UTM.  Or do all of the devices behind the UTM have 10.0.0.1 as their default gateway?  What happens when you ping and traceroute to 172.23.146.102 from WebAdmin in the UTM?

Also, I find the use of Interface groups confusing in this situation, and I don't understand what's intended with the existing Multipath rules.  Don't you simply want to configure an alternate way to provide a connection if the WAN goes down?

Cheers - Bob

Hello Bob, first of all, thanks a lot for your time once again. I think I have not been clear enough explaining the scenario. Let see if I can do it now. I will attach an updated diagram to try to clarify some points.

1. There is no NAT between ASA and UTM. Both of them have public IP addresses (different to the IP addresses shown in the diagram for security reasons).

2. The VPN S2S is only needed when the WAN fails. I mean, all traffic from the remote Site (JAEN) going to MADRID or the rest of the internet goes through the WAN in normal operation. 

3. The HSRP routers on Madrid have static routes to JAEN through the WAN. Those routes use "tracks" to disable the route in case the WAN fails.

4. The UTM has a route to JAEN (configured in the UPLINK interface "Intranet" with multipath rules and the option to "skip rule on interface error") that goes through the HSRP routers. These routes are disabled in case the monitored host fails.  

5. The UTM has another UPLINK interface to go to the rest of the internet (configured in the UPLINK interface "Internet") It has no the "skip rule on interface error " check mark set.

6. At the other end (in JAEN), the SW-JAEN1 also has a default route with higher preference through the WAN (next hop 10.0.102.10). This route also has a "track" to detect WAN failures, and, in this case it uses a "backup" default route to the Cisco ASA (10.0.102.233) to send traffic to internet and to MADRID, through the VPN S2S that should be enable in this case.

Everything is working fine, but the tunnel does not go up in case the Intranet interface goes to error state. 

I can even enable the tunnel manually, this is the work around in this moment, but we need something similar to the configuration we had (ASA-ASA configuration). They had the tunnel permanently enabled and they control when to redirect traffic to the tunnel with "tracked" routes.

Thank you very much.

Best regards.

Joel

With all those tracks and such, it's difficult to visualize what's happening without a detailed study of all of the other routing going on in 10.0.0.0/21.  

Easiest would be to use another NIC on the UTM with an IP in 172.23.146.0/24 with a direct connection to the WAN instead of through the ONO device at 10.0.0.213. Make this new interface the other Uplink interface instead of eth1.   

Does that work for you?  

Cheers - Bob  

Sorry for any short responses.  Posted from my iPhone.

Hello Bob,

I can not use an UTM NIC interface in the 172.23.146.0/24 subnet because what is represented as WAN is the ISP IP/MPLS network. The router 10.0.0.213 is the ISP router. This is a traceroute from the UTM:

traceroute to 172.23.146.102 (172.23.146.102), 30 hops max, 40 byte packets using UDP

 1  10.0.0.213 (10.0.0.213)  0.957 ms   0.799 ms   0.776 ms

 2  172.23.146.97 (172.23.146.97)  3.153 ms   2.985 ms   1.972 ms

 3  172.23.146.101 (172.23.146.101)  9.260 ms   8.754 ms   8.748 ms

 4  172.23.146.102 (172.23.146.102)  16.110 ms * *

Thank you very much.

Best regards.

Joel

Thanks, Joel,

Where's the traceroute from?

[rant]MPLS really is (almost) worthless compared to the RED technology or IPsec VPNs.  The only thing that MPLS offers is QoS in the public network.  If there is real-time traffic between sites, then MPLS can be justified.  It's rare that this causes a problem for VoIP in spite of what the ISP's salesreps have to say.[/rant]

What happens if you disable the WAN and run the traceroute without enabling theIPsec tunnel?  What happens when you then enable the tunnel?

Cheers - Bob

Hello Bob.

The traceroute is from the UTM. It goes through the Intranet interface because of the Multipath rule associated to that interface. If we turn off this interface, or it goes to Error state,  without enabling the S2S VPN, we loose communication with the remote Site. If we manually enable the VPN then the traffic goes through the tunnel. I can't test those situations right now because it is a production network, and I should program the tests.

Thank you very much.

Regards.

Joel