IPSec policies going into an invalid state

RouterOS General
1

ROS 6.42.12. Does anyone here perhaps have any specific information on why IPSec policies would out of the blue go into an invalid state? This happens randomly and I cannot reproduce on demand. There are no overlapping subnets. The only way I have been able to get the policy to function again is to leave it disabled for quite some time and then sometimes it just functions again. This makes no sense to me.

Policy state:
https://imgur.com/bs9ynhA

Config:

/ip ipsec peer
add address=32.56.77.82/32 dh-group=modp1024 dpd-interval=10s dpd-maximum-failures=3 enc-algorithm=aes-128 lifetime=8h local-address=197.45.67.3 nat-traversal=no secret=secret-here

/ip ipsec policy
add dst-address=169.254.200.66/32 proposal=vpn-core protocol=gre sa-dst-address=32.56.77.82 sa-src-address=197.45.67.3 src-address=169.254.200.65/32 tunnel=yes

/ip ipsec proposal
add enc-algorithms=aes-128-cbc lifetime=1h name=vpn-core

Log:

Apr/08/2019 12:03:23 ipsec,error 32.56.77.82 peer sent packet for dead phase2
Apr/08/2019 12:03:23 ipsec,error 32.56.77.82 peer sent packet for dead phase2
Apr/08/2019 12:03:37 ipsec,error 32.56.77.82 peer sent packet for dead phase2
Apr/08/2019 12:03:51 ipsec,info purging ISAKMP-SA 197.45.67.3[500]<=>32.56.77.82[500] spi=411d519e3dff9ebb:8bbc9dbda5d18093.
Apr/08/2019 12:03:51 ipsec,info ISAKMP-SA deleted 197.45.67.3[500]-32.56.77.82[500] spi:411d519e3dff9ebb:8bbc9dbda5d18093 rekey:1
Apr/08/2019 12:03:51 ipsec,info respond new phase 1 (Identity Protection): 197.45.67.3[500]<=>32.56.77.82[500]
Apr/08/2019 12:03:52 ipsec,info ISAKMP-SA established 197.45.67.3[500]-32.56.77.82[500] spi:a4065316fd2443e0:99be3dee19e7e38d
Apr/08/2019 12:03:52 ipsec,error 32.56.77.82 failed to pre-process ph2 packet.
Apr/08/2019 12:04:02 ipsec,error 32.56.77.82 peer sent packet for dead phase2
Apr/08/2019 12:04:11 ipsec,info ISAKMP-SA deleted 197.45.67.3[500]-32.56.77.82[500] spi:a4065316fd2443e0:99be3dee19e7e38d rekey:1
Apr/08/2019 12:05:03 ipsec,info respond new phase 1 (Identity Protection): 197.45.67.3[500]<=>32.56.77.82[500]
Apr/08/2019 12:05:03 ipsec,error no suitable proposal found.
Apr/08/2019 12:05:03 ipsec,error 32.56.77.82 failed to get valid proposal.
Apr/08/2019 12:05:03 ipsec,error 32.56.77.82 failed to pre-process ph1 packet (side: 1, status 1).
Apr/08/2019 12:05:03 ipsec,error 32.56.77.82 phase1 negotiation failed.
Apr/08/2019 12:05:12 ipsec,info respond new phase 1 (Identity Protection): 197.45.67.3[500]<=>32.56.77.82[500]
Apr/08/2019 12:05:12 ipsec,error no suitable proposal found.
Apr/08/2019 12:05:12 ipsec,error 32.56.77.82 failed to get valid proposal.
Apr/08/2019 12:05:12 ipsec,error 32.56.77.82 failed to pre-process ph1 packet (side: 1, status 1).
Apr/08/2019 12:05:12 ipsec,error 32.56.77.82 phase1 negotiation failed.
Apr/08/2019 12:05:32 ipsec,info respond new phase 1 (Identity Protection): 197.45.67.3[500]<=>32.56.77.82[500]
Apr/08/2019 12:05:32 ipsec,error no suitable proposal found.
Apr/08/2019 12:05:32 ipsec,error 32.56.77.82 failed to get valid proposal.
Apr/08/2019 12:05:32 ipsec,error 32.56.77.82 failed to pre-process ph1 packet (side: 1, status 1).
Apr/08/2019 12:05:32 ipsec,error 32.56.77.82 phase1 negotiation failed.
Apr/08/2019 12:06:12 ipsec,info respond new phase 1 (Identity Protection): 197.45.67.3[500]<=>32.56.77.82[500]
2

Anyone?

3

For what it’s worth - I just started having this problem today (2019-09-11). One policy, identical to over 20 others, is flagged as invalid.

RouterOS ver: 6.45.6 on CCR1009-8G-1S.

Here is the policy definition that is flagged as invalid:

/ip ipsec policy
add action=encrypt comment=“VPN to SCSO for Spillman for station 31” disabled=yes dst-address=168.180.18.0/24
dst-port=any ipsec-protocols=esp level=require peer=SCSO_primary proposal=SCSO protocol=all sa-dst-address=
168.180.17.12 sa-src-address=67.128.135.131 src-address=192.168.31.0/24 src-port=any tunnel=yes

/ip ipsec peer
add address=168.180.17.12/32 comment=“SCSO VPN for Spillman” disabled=no exchange-mode=main local-address=
67.128.135.131 name=SCSO_primary profile=profile_1 send-initial-contact=no

/ip ipsec proposal
add auth-algorithms=sha1 disabled=no enc-algorithms=aes-128-cbc lifetime=8h name=SCSO pfs-group=none


Here’s another proposal that is working:
add action=encrypt comment=“VPN to SCSO for Spillman from station 34” disabled=no dst-address=168.180.18.0/24
dst-port=any ipsec-protocols=esp level=require peer=SCSO_primary proposal=SCSO protocol=all sa-dst-address=
168.180.17.12 sa-src-address=67.128.135.131 src-address=192.168.34.0/24 src-port=any tunnel=yes


I’ve also checked for overlapping subnets. I can’t think of anything else to look for. The router that I’m peering with (a third party) won’t connect any policy unless there is an exact match of policies between my end and theirs. So I’ve had to have them disable the “invalid” policy on their end for now, so that the others can come up.

Any ideas?

4

Hi dcdorsey777,

What I can say is that after much back and forth with support, the issue I am experiencing, should be fixed in in v6.45.

From support: “This issue should be resolved in 6.45.1.” and “There was a bug in IPsec policy code that prevented traffic selectors to be installed in the kernel. The occurrence was pretty random and there are no specific steps to trigger the issue, but more policies caused the issue to happen more frequently.”

You are running a later version so I can only assume the issue you are seeing is because of a different underlying reason or, and I hope this is not the case, the issue is not properly resolved in 6.45. I have not upgraded to 6.45 yet as I have been waiting for the release to mature, but I will keep this thread updated with my findings.

5

I have upgraded my CCR1036 to v6.45.6 on the 18th of September and so far the IPSec policies have remained stable. I have however noticed that dynamic policies used for L2TP over IPSec sometimes go into an invalid state but this seems to be isolated to L2TP and I will dig deeper into that at a later state. For now it looks good.