Problem with IPsec on new ISP

RouterOS General
1

Hi,

We were using ipsec tunnels between two Mikrotik with legacy version of 5.25 for more than 2 years. Now one of the devices changed its ISP and every day the IPsec tunnel breaks and ping either times out or says “packet rejected”. In the past we would kill ipsec connection peers and flush the SAs and the connection would go up, but now this is not possible and only reboot of the devices would fix the link. Needless to say we did not change anything but the new IP address of the new place.

/ip ipsec proposal
set [ find default=yes ] auth-algorithms=md5,sha1 enc-algorithms=3des,aes-256 lifetime=8h pfs-group=none
add enc-algorithms=aes-256 lifetime=2h name=sha-aes pfs-group=none
/ip ipsec peer
add generate-policy=yes hash-algorithm=sha1 nat-traversal=yes secret=SomePass
add address=SomeIP1/32 comment=Maunsel dpd-maximum-failures=100 enc-algorithm=aes-256 hash-algorithm=sha1 nat-traversal=yes secret=
“SomePasword”
/ip ipsec policy
add comment=“Ergon to Maunsel” dst-address=192.168.99.0/24 proposal=sha-aes sa-dst-address=SomeIP1 sa-src-address=SomeIP2 src-address=
192.168.64.0/19 tunnel=yes

/ip firewall nat
add chain=srcnat comment=IPSEC dst-address=192.168.99.0/24 src-address=192.168.64.0/19

This happens like every day at least once. Any ideas?

Regards

2

This is observed in the logs:

Това виждам в лога:

09:22:01 ipsec,debug,packet resend phase1 packet 882fdd259adbc0ef:0000000000000000
09:22:02 ipsec,debug phase2 negotiation failed due to time up waiting for phase1. ESP X.X.X.X[500]->Y.Y.Y.Y[500]

I changed the initiator side to be the non-faulty Ipsec end. I also tried traceroute via UDP port 500 and it worked. After disabling/disabling all ipsec settings on both ends the link came up again.

Do you think I can check something more?

3

I can imagine IPsec transport packets to be lost selectively by contents, causing all retransmissions of the same packet to be lost, such things sometimes happen. The question is why the IPsec astro clock doesn’t recover from that, as when it re-establishes a security association (which exists also for Phase 1), the new packets should have a different contents as many things differ between the attempts.

It would require a longer quotation from the logs to see whether a new Phase 1 establishment attempt is taken or not.

But I’m afraid you should start by upgrading the devices to something contemporary like 6.40.8 if the hardware can handle that, as many things have been fixed in ipsec since 5.25.