Phase 1 and phase 2 establish connection and then after 10 seconds or so, I get:
and then the installed SAs are deleted and the whole process starts again.
I’ve got to the stage where I think I’ve tried everything and nothing works. I’m sure I’ve missed something that’s really obvious.
It seems that You have 0.0.0.0/0 <=> 0.0.0.0/0 as Your policy traffic selector.
You need to specify networks that are behind Your Cisco and RouterOS for them to establish phase 2.
I thought that’s what I’d done as phase 2 shows as established (until the error occurs and the SAs are deleted). Where the 0.0.0.0/0 addresses are coming from is, I think, what I am misunderstanding.
OK. Got to the bottom of it. It seems that I’d done everything correctly, but that there’s a mis-configuration on the remote site.
The remote site appear to have set their proposed phase 2 subnet to 0.0.0.0/0 / 0.0.0.0/0. When I replicate this, the VPN stays up and works perfectly.
The problem with this is that the IPSec policy for 0.0.0.0/0 overrides the routing table (as per https://wiki.mikrotik.com/wiki/Manual:Packet_Flow_v6) which means that the ROS box then tries to route all traffic down the VPN. I can’t see an obvious way to avoid this from happening for all but the required destination addresses.
I’ve bounced this back to the remote party, but if anybody here has any ideas, I’d be grateful.
There is too many issues about 0.0.0.0/0 <> 0.0.0.0/0 policies.
I am currently in process of solving same issue.
While connecting to AWS VPN Amazon support give an advice of using 0.0.0.0/0 policy, which is not actually right…
Will give an update on my case when done, as I spent much time searching for resolution and speaking to AWS Support.
At the moment waiting for reply from them…
The IPsec policies are examined from first to last until first match, same like firewall rules, routing rules etc.
So you can put a bunch of action=none policies before the 0.0.0.0/0<=>0.0.0.0/0 one, shadowing the latter for all other subnets than the one you wish to actually get through. E.g if you want only 128.0.0.0/2 to be tunnelled, you use src-address=0.0.0.0/0 dst-address=0.0.0.0/1 action=none
src-address=0.0.0.0/0 dst-address=192.0.0.0/2 action=none
src-address=0.0.0.0/0 dst-address=0.0.0.0/0 action=encrypt peer=…
So you need as many shadowing rules as there are bits of the prefix you want to tunnel; if you need multiple prefixes, it becomes even more complex. So nothing for everyday use.
With IKEv2 it is easier because the policies can be negotiated (narrowed down by each peer), not your case here.
Sadly this doesn’t appear to work. I have tried it as per your examples and also with source network and also setting the peer. It seems that ‘action=none’ rules are ignored
This definitely doesn’t work. ROS 7.3 and 7.3.1 on a CHR. In addition, I am seeing some newly added policies marked as ‘invalid’ for no apparent reason which only become valid after a reboot. It seems that when I do reboot the ‘none’ policy rules do work, but as soon as the tunnel goes down, some of the rules go invalid and then none of them work any more.
I’m now downgrading to v6… We’ll see what happens.
v6.49.6 worked perfectly straight away with exactly the same configuration.
So there are clearly bugs in ROS 7.3 and 7.3.1 on CHR.
1 - Adding a policy with a valid destination may or may not show that policy as invalid.
2 - Rebooting the router then shows any previously invalid policies as valid.
3 - Disabling and then re-enabling the policy that was invalid and then became valid after a reboot then marks that policy as invalid (until the next reboot).
4 - Throughout all of the above, all policies with action=none are ignored.
