Hi everyone,

I'm having a weird issue with IPSEC. Hope someone of you guys can help:
SCENARIO
I am establishing an IPSEC tunnel between two mikrotiks. Both have to wan (fiber) links, so i have created two tunnels, so we have a (manual) fallback in case any of the fibers fail.
For that, i have created two sets of policies and two peers per router.
There are several subnets to be connected, so there are 7 policies per tunnel.
The weird thing is that one of those is automatically marked as invalid for both mikrotiks. They mark it as invalid instantly as soon as i enable it, so i am understanding it is not related to a faulty connection, but to some (misterious) internal calculation of the router that says "i don't like this route". But, why?
This is the regarding data:

ROUTER1 - IPSEC - POLICIES
# PEER TUNNEL SRC-ADDRESS DST-ADDRESS PROTOCOL ACTION LEVEL PH2-COUNT
0 A RW yes 192.168.41.0/24 172.31.0.0/16 all encrypt require 2
1 A RW yes 192.168.41.0/24 192.168.0.0/16 all encrypt require 1
2 A RW yes 10.20.14.0/24 172.31.0.0/16 all encrypt require 1
3 A RW yes 10.20.14.0/24 192.168.0.0/16 all encrypt require 1
4 A RW yes 172.30.100.0/24 172.31.0.0/16 all encrypt require 1
5 A RW yes 172.30.100.0/24 192.168.0.0/16 all encrypt require 1
6 RW yes 10.20.59.0/24 192.168.0.0/16 all encrypt require 0
7 A RW yes 10.20.59.0/24 172.31.0.0/16 all encrypt require 1
8 XI RWC yes 192.168.41.0/24 172.31.0.0/16 all encrypt require 0
9 XI RWC yes 192.168.41.0/24 192.168.0.0/16 all encrypt require 0
10 XI RWC yes 10.20.14.0/24 172.31.0.0/16 all encrypt require 0
11 XI RWC yes 10.20.14.0/24 192.168.0.0/16 all encrypt require 0
12 XI RWC yes 172.30.100.0/24 172.31.0.0/16 all encrypt require 0
13 XI RWC yes 172.30.100.0/24 192.168.0.0/16 all encrypt require 0
14 XI RWC yes 10.20.59.0/24 172.31.0.0/16 all encrypt require 0
15 XI RWC yes 10.20.59.0/24 192.168.0.0/16 all encrypt require 0
16 T * ::/0 ::/0 all


As you can see, policies 0-7 are for the first tunnel, and are active currently. Policies 8 to 15 are for the secind tunnel, and inactive. The problem es policiy 6.
Now the other router:

ROUTER2 - IPSEC - POLICIES
# PEER TUNNEL SRC-ADDRESS DST-ADDRESS PROTOCOL ACTION LEVEL PH2-COUNT
0 XI RWC yes 172.31.0.0/16 192.168.41.0/24 all encrypt require 0
1 XI RWC yes 192.168.0.0/16 192.168.41.0/24 all encrypt require 0
2 XI RWC yes 172.31.0.0/16 10.20.14.0/24 all encrypt require 0
3 XI RWC yes 192.168.0.0/16 10.20.14.0/24 all encrypt require 0
4 XI RWC yes 172.31.0.0/16 172.30.100.0/24 all encrypt require 0
5 XI RWC yes 192.168.0.0/16 172.30.100.0/24 all encrypt require 0
6 XI RWC yes 172.31.0.0/16 10.20.59.0/24 all encrypt require 0
7 XI RWC yes 192.168.0.0/16 10.20.59.0/24 all encrypt require 0
8 A RW yes 172.31.0.0/16 192.168.41.0/24 all encrypt require 2
9 A RW yes 192.168.0.0/16 192.168.41.0/24 all encrypt require 1
10 A RW yes 172.31.0.0/16 10.20.14.0/24 all encrypt require 1
11 A RW yes 192.168.0.0/16 10.20.14.0/24 all encrypt require 1
12 A RW yes 172.31.0.0/16 172.30.100.0/24 all encrypt require 1
13 A RW yes 192.168.0.0/16 172.30.100.0/24 all encrypt require 1
14 I RW yes 192.168.0.0/16 10.20.59.0/24 all encrypt require 0
15 A RW yes 172.31.0.0/16 10.20.59.0/24 all encrypt require 1
16 T * ::/0 ::/0 all

As you can see, in Router 2 the offending policy is 14.

If i switch tunnels and let the other one work, the same issue happens. Route from/to 192.168.0.0/16 -- 10.20.59.0/24 is consistently marked as invalid. Everything else works flawlessly but, of course, traffic between these two subnets.

By the way, Router 1 is an RB4011 with Os v6.47.10, and Router2 is a cloud hosted router with Os v6.47.8

I have check -literally- the configs a hundred times. Cannot find anything worng. I can only thing this is a (very) odd issue into the Mkt, But it would be lovely if any of you experienced guys could have a look and help.

Thank you very much in advance.

In such a situation it is better to use a GRE or IPIP tunnel over IPsec transport.
Then you define the IPsec only in terms of "GRE protocol sent between the routers" and you can route the subnets using BGP, OSPF or static routes.

In such a situation it is better to use a GRE or IPIP tunnel over IPsec transport.
Then you define the IPsec only in terms of "GRE protocol sent between the routers" and you can route the subnets using BGP, OSPF or static routes.

Hi pe1chl, many thanks for your answer

While i will consider your approach, this will involve noticeable time spent in studying howto and testing. Would it be possible to fix my current scenario first?

This approach is much easier to get going. Just create GRE tunnel, enter IPsec secret on its setup form, add a /30 address to each endpoint (e.g. 10.0.0.1/30 and 10.0.0.2/30) and set your routes.
Much much simpler than what you are doing now. No NAT exceptions needed, much simpler firewalling (because internal traffic is on another interface), etc.

Would it be possible to fix my current scenario first?

Unless you have made a trivial error (i.e. configured a peer that is constantly disabled for the problematic policy at the router that indicates it as Invalid), it looks like a bug to me, as that problematic policy is not shadowed by any previous one.

You can try to split the problematic policy into 10.20.59.0/25 and 10.20.59.128/25 at that side or into 192.168.0.0/17 and 192.168.128.0/17 at the other one, to see whether it reveals something or at least makes it work. Of course you have to modify it the same way at both routers.

But even if you fix it, @pe1chl's suggestion makes a lot of sense. If you use IPIP tunnel and transport mode of IPsec, the overhead of the tunnel (number of header bytes in each packet) will be exactly the same like now, but the failover to the backup tunnel can be automated, as tunnel between WAN 1s and the tunnel between WAN 2s can both stay up all the time and OSPF with BFD can take care of the failover of the payload.