IPSec Tunnels Stop Passing Traffic

I have a bit of an issue and am frankly at a loss of where to start. I have two IPSec tunnels configured and both work perfectly… for a while. There seems to be no determined length of time they continue to work, but eventually one or both will stop passing traffic (usually a period of some hours). There are no log messages, the remote peers still show as active connections, and the SAs are still in place and valid. Trying to pass traffic across the connection results in nothing more than timeouts (again, no log messages even with IPSec debug messages being logged). The only way to get the tunnel to start passing traffic again is to kill the connections and flush the SAs (both must be done before it will work). After that, the tunnel comes up exactly as it should. It should be noted there is infrequent traffic on these tunnels (every 4 hours or so). Remote equipment for one is a FortiGate (I think) and the other I believe is some Cisco equipment, but both are out of my jurisdiction (and I believe irrelevant since both tunnels do this).

If anybody can point me in a good direction for information about where to even start I would be most grateful.

RouterOS Version: 5.4

My router has the external addresses of 192.168.30.1 and 192.168.40.1 and an internal network of 172.16.101.0/24. All traffic from within the NAT network is directed outbound on an IP in the 192.168.30.0/28 network (verified). IP addresses have been changed to protect the guilty, but relativity and netmasks have been maintained.

/ip ipsec peer print

 0   ;;; Peer 1
     address=192.168.10.1/32 port=500 auth-method=pre-shared-key secret="p1secret" generate-policy=no exchange-mode=main 
     send-initial-contact=yes nat-traversal=no my-id-user-fqdn="" proposal-check=obey hash-algorithm=sha1 enc-algorithm=3des 
     dh-group=modp1024 lifetime=1d lifebytes=0 dpd-interval=2m dpd-maximum-failures=5 

 1   ;;; Peer 2
     address=192.168.20.2/32 port=500 auth-method=pre-shared-key secret="p2secret" generate-policy=no exchange-mode=main 
     send-initial-contact=yes nat-traversal=no my-id-user-fqdn="" proposal-check=obey hash-algorithm=sha1 enc-algorithm=3des 
     dh-group=modp1024 lifetime=1d lifebytes=0 dpd-interval=2m dpd-maximum-failures=5 

 2   ;;; Dynamic
     address=0.0.0.0/0 port=500 auth-method=pre-shared-key secret="dynsecret" generate-policy=yes exchange-mode=main 
     send-initial-contact=yes nat-traversal=no my-id-user-fqdn="" proposal-check=obey hash-algorithm=sha1 enc-algorithm=3des 
     dh-group=modp1024 lifetime=1d lifebytes=0 dpd-interval=2m dpd-maximum-failures=5



/ip ipsec policy print

 0   ;;; Policy 1
     src-address=192.168.30.1/28 src-port=any dst-address=10.0.1.18/32 dst-port=any protocol=all action=encrypt level=require 
     ipsec-protocols=esp tunnel=yes sa-src-address=192.168.40.1 sa-dst-address=192.168.10.1 proposal=proposal1 priority=0 

 1   ;;; Policy 2
     src-address=192.168.30.1/28 src-port=any dst-address=192.168.20.1/29 dst-port=any protocol=all action=encrypt 
     level=require ipsec-protocols=esp tunnel=yes sa-src-address=192.168.30.1 sa-dst-address=192.168.20.2 proposal=proposal2 
     priority=0



/ip ipsec proposal print

 0   name="default" auth-algorithms=sha1 enc-algorithms=3des lifetime=8h pfs-group=modp1024 

 1   name="proposal1" auth-algorithms=sha1 enc-algorithms=3des lifetime=8h pfs-group=modp1024 

 2   name="proposal2" auth-algorithms=sha1 enc-algorithms=3des lifetime=8h pfs-group=modp1024

I found a little more information about what is going on here. For some reason the remote end of the connection seems to think the SAs are expired and sends a request they be deleted. The MikroTik seems to ignore this message and leave the Phase 2 in place. It continues to send traffic to the remote end which is dropped to to an invalid Phase 2. The remote end attempts to request a new negotiation, but the MikroTik does not respond. Has anybody had a similar experience and perhaps found a fix or work-around?

If it’s a bug try emailing support.