[SOLVED] CCR IPSec rekey problem

RouterOS General
1

Hello.
I have encountered a problem with IPSec between my CCR1016-12G with ROS 6.27 and Linux host with Strongswan version 5.
IPSec works in transport mode with GRE over it. IPSec negotiation is successful betwen CCR and Linux host, GRE is up, traffic flows, everything is fine. But, when SA expiration comes and when CCR tries to rekey I have this messages in Strongswan log:

  • Aug 30 03:00:17 linuxhost0 charon: 13[IKE] detected rekeying of CHILD_SA My-Shiny-IPSec{846}
    Aug 30 03:00:17 linuxhost0 charon: 13[ENC] generating QUICK_MODE response 2238353212 [ HASH SA No KE ID ID ]
    Aug 30 03:00:17 linuxhost0 charon: 13[NET] sending packet: from 192.0.2.102[500] to 192.0.2.101[500] (316 bytes)
    Aug 30 03:00:17 linuxhost0 strongswan: 08[NET] sending packet: from 192.0.2.102[500] to 192.0.2.101[500] (92 bytes)
    Aug 30 03:00:17 linuxhost0 strongswan: 09[NET] received packet: from 192.0.2.101[500] to 192.0.2.102[500] (92 bytes)
    Aug 30 03:00:17 linuxhost0 strongswan: 09[ENC] parsed INFORMATIONAL_V1 request 2378938268 [ HASH N(DPD) ]
    Aug 30 03:00:17 linuxhost0 strongswan: 09[ENC] generating INFORMATIONAL_V1 request 2812928436 [ HASH N(DPD_ACK) ]
    Aug 30 03:00:17 linuxhost0 strongswan: 09[NET] sending packet: from 192.0.2.102[500] to 192.0.2.101[500] (92 bytes)
    Aug 30 03:00:17 linuxhost0 strongswan: 12[NET] received packet: from 192.0.2.101[500] to 192.0.2.102[500] (92 bytes)
    Aug 30 03:00:17 linuxhost0 strongswan: 12[ENC] parsed INFORMATIONAL_V1 request 2760470801 [ HASH N(DPD) ]
    Aug 30 03:00:17 linuxhost0 strongswan: 12[ENC] generating INFORMATIONAL_V1 request 1693968130 [ HASH N(DPD_ACK) ]
    Aug 30 03:00:17 linuxhost0 strongswan: 12[NET] sending packet: from 192.0.2.102[500] to 192.0.2.101[500] (92 bytes)
    Aug 30 03:00:17 linuxhost0 strongswan: 04[NET] received packet: from 192.0.2.101[500] to 192.0.2.102[500] (92 bytes)
    Aug 30 03:00:17 linuxhost0 strongswan: 04[ENC] parsed INFORMATIONAL_V1 request 2739474851 [ HASH N(DPD) ]
    Aug 30 03:00:17 linuxhost0 strongswan: 04[ENC] generating INFORMATIONAL_V1 request 2361218907 [ HASH N(DPD_ACK) ]
    Aug 30 03:00:17 linuxhost0 strongswan: 04[NET] sending packet: from 192.0.2.102[500] to 192.0.2.101[500] (92 bytes)
    Aug 30 03:00:17 linuxhost0 strongswan: 14[NET] received packet: from 192.0.2.101[500] to 192.0.2.102[500] (92 bytes)
    Aug 30 03:00:17 linuxhost0 strongswan: 14[ENC] parsed INFORMATIONAL_V1 request 2170908798 [ HASH N(DPD) ]
    Aug 30 03:00:17 linuxhost0 strongswan: 14[ENC] generating INFORMATIONAL_V1 request 2853904775 [ HASH N(DPD_ACK) ]
    Aug 30 03:00:17 linuxhost0 strongswan: 14[NET] sending packet: from 192.0.2.102[500] to 192.0.2.101[500] (92 bytes)
    Aug 30 03:00:17 linuxhost0 strongswan: 05[NET] received packet: from 192.0.2.101[500] to 192.0.2.102[500] (92 bytes)
    Aug 30 03:00:17 linuxhost0 strongswan: 05[ENC] parsed INFORMATIONAL_V1 request 3663549940 [ HASH N(DPD) ]
    Aug 30 03:00:17 linuxhost0 strongswan: 05[ENC] generating INFORMATIONAL_V1 request 26231505 [ HASH N(DPD_ACK) ]
    Aug 30 03:00:17 linuxhost0 strongswan: 05[NET] sending packet: from 192.0.2.102[500] to 192.0.2.101[500] (92 bytes)
    Aug 30 03:00:17 linuxhost0 strongswan: 14[NET] received packet: from 192.0.2.101[500] to 192.0.2.102[500] (92 bytes)
    Aug 30 03:00:17 linuxhost0 strongswan: 14[ENC] parsed INFORMATIONAL_V1 request 2549998286 [ HASH N(DPD) ]
    Aug 30 03:00:17 linuxhost0 strongswan: 14[ENC] generating INFORMATIONAL_V1 request 763764598 [ HASH N(DPD_ACK) ]
    Aug 30 03:00:17 linuxhost0 strongswan: 14[NET] sending packet: from 192.0.2.102[500] to 192.0.2.101[500] (92 bytes)
    Aug 30 03:00:17 linuxhost0 strongswan: 13[NET] received packet: from 192.0.2.101[500] to 192.0.2.102[500] (284 bytes)
    Aug 30 03:00:17 linuxhost0 strongswan: 13[ENC] parsed QUICK_MODE request 2238353212 [ HASH SA No KE ]
    Aug 30 03:00:17 linuxhost0 strongswan: 13[IKE] received 3600s lifetime, configured 0s
    Aug 30 03:00:17 linuxhost0 charon: 09[NET] received packet: from 192.0.2.101[500] to 192.0.2.102[500] (76 bytes)
    Aug 30 03:00:17 linuxhost0 charon: 09[ENC] parsed INFORMATIONAL_V1 request 3511421001 [ HASH N(ATTR_UNSUP) ]
    Aug 30 03:00:17 linuxhost0 charon: 09[IKE] received ATTRIBUTES_NOT_SUPPORTED error notify
    Aug 30 03:00:17 linuxhost0 charon: 09[IKE] received ATTRIBUTES_NOT_SUPPORTED error notify

And over and over again messages with detected rekeying and received ATTRIBUTES_NOT_SUPPORTED.
Traffic stops to flow between CCR and Linux Host.

Here Is Mikrotik CCR messages:

  • aug/30 03:00:17 ipsec,error failed to pre-process ph2 packet.
    aug/30 03:00:49 ipsec,error failed to pre-process ph2 packet.
    aug/30 03:01:21 ipsec,error failed to pre-process ph2 packet.
    aug/30 03:01:54 ipsec,error failed to pre-process ph2 packet.
    aug/30 03:02:26 ipsec,error failed to pre-process ph2 packet.

And so on until I flush SAs from CCR side (sometimes with /ip ipsec remote-peers kill-connections) or running a script on Linux host:

#!/bin/bash
osth=192.168.0.250
peerip=192.0.2.101/32
myip=192.0.2.102/32
ifname=enp5s0
connid=$(/sbin/iptables -nvL OUTPUT 1 | awk '{ print $17 }')
/usr/bin/ping -c3 $osth > /dev/null
retval=$?
if [ $retval -eq "0" ] ; then
 echo -n "Everything seems to be fine..." | logger -t sschecker
else
 echo -n "Whoa, something nasty with a rekeying. Ty to fix..." | logger -t sschecker
 /usr/sbin/swanctl -t --child $tname
 sleep 3
 /usr/sbin/swanctl -i --child $tname
fi

Only then we are back online and so on.
So, I’ve put this dirty script in cron and lived with this for a while. It’s just workaround.

But I’ve notised, if Strongswan tries to rekey expiring SA everything is just fine:

  • Aug 27 17:06:39 linuxhost0 strongswan: 04[KNL] creating rekey job for CHILD_SA ESP/0x01d30567/192.0.2.101
    Aug 27 17:06:39 linuxhost0 strongswan: 04[ENC] generating QUICK_MODE request 1912290060 [ HASH SA No KE ID ID ]
    Aug 27 17:06:39 linuxhost0 strongswan: 04[NET] sending packet: from 192.0.2.102[500] to 192.0.2.101[500] (316 bytes)
    Aug 27 17:06:39 linuxhost0 strongswan: 06[NET] received packet: from 192.0.2.101[500] to 192.0.2.102[500] (300 bytes)
    Aug 27 17:06:39 linuxhost0 strongswan: 06[ENC] parsed QUICK_MODE response 1912290060 [ HASH SA No KE ID ID ]
    Aug 27 17:06:39 linuxhost0 strongswan: 06[IKE] CHILD_SA My-Shiny-IPSec{298} established with SPIs cde7c024_i 0afd2c51_o and TS 192.0.2.102/32 === 192.0.2.101/32
    Aug 27 17:06:39 linuxhost0 strongswan: 06[ENC] generating QUICK_MODE request 1912290060 [ HASH ]
    Aug 27 17:06:39 linuxhost0 strongswan: 06[NET] sending packet: from 192.0.2.102[500] to 192.0.2.101[500] (60 bytes)
    Aug 27 17:06:39 linuxhost0 strongswan: 08[KNL] creating rekey job for CHILD_SA ESP/0xc77f123b/192.0.2.102
    Aug 27 17:06:39 linuxhost0 strongswan: 14[NET] received packet: from 192.0.2.101[500] to 192.0.2.102[500] (92 bytes)
    Aug 27 17:06:39 linuxhost0 strongswan: 14[ENC] parsed INFORMATIONAL_V1 request 2226730451 [ HASH N(DPD) ]
    Aug 27 17:06:39 linuxhost0 strongswan: 14[ENC] generating INFORMATIONAL_V1 request 1860165424 [ HASH N(DPD_ACK) ]
    Aug 27 17:06:39 linuxhost0 strongswan: 14[NET] sending packet: from 192.0.2.102[500] to 192.0.2.101[500] (92 bytes)
    Aug 27 17:06:39 linuxhost0 strongswan: 13[NET] received packet: from 192.0.2.101[500] to 192.0.2.102[500] (92 bytes)
    Aug 27 17:06:39 linuxhost0 strongswan: 13[ENC] parsed INFORMATIONAL_V1 request 2828512676 [ HASH N(DPD) ]
    Aug 27 17:06:39 linuxhost0 strongswan: 13[ENC] generating INFORMATIONAL_V1 request 3746866616 [ HASH N(DPD_ACK) ]
    Aug 27 17:06:39 linuxhost0 strongswan: 13[NET] sending packet: from 192.0.2.102[500] to 192.0.2.101[500] (92 bytes)
    Aug 27 17:06:39 linuxhost0 strongswan: 07[NET] received packet: from 192.0.2.101[500] to 192.0.2.102[500] (92 bytes)
    Aug 27 17:06:39 linuxhost0 strongswan: 07[ENC] parsed INFORMATIONAL_V1 request 3401905689 [ HASH N(DPD) ]
    Aug 27 17:06:39 linuxhost0 strongswan: 07[ENC] generating INFORMATIONAL_V1 request 3800780160 [ HASH N(DPD_ACK) ]
    Aug 27 17:06:39 linuxhost0 strongswan: 07[NET] sending packet: from 192.0.2.102[500] to 192.0.2.101[500] (92 bytes)
    Aug 27 17:06:39 linuxhost0 strongswan: 07[KNL] creating delete job for CHILD_SA ESP/0xc77f123b/192.0.2.102
    Aug 27 17:06:39 linuxhost0 strongswan: 08[KNL] creating delete job for CHILD_SA ESP/0x01d30567/192.0.2.101
    Aug 27 17:06:39 linuxhost0 strongswan: 12[IKE] closing expired CHILD_SA My-Shiny-IPSec{297} with SPIs c77f123b_i 01d30567_o and TS 192.0.2.102/32 === 192.0.2.101/32
    Aug 27 17:06:39 linuxhost0 strongswan: 12[IKE] sending DELETE for ESP CHILD_SA with SPI c77f123b
    Aug 27 17:06:39 linuxhost0 strongswan: 12[ENC] generating INFORMATIONAL_V1 request 3146463862 [ HASH D ]
    Aug 27 17:06:39 linuxhost0 strongswan: 12[NET] sending packet: from 192.0.2.102[500] to 192.0.2.101[500] (76 bytes)
    Aug 27 17:06:39 linuxhost0 strongswan: 08[JOB] CHILD_SA ESP/0x01d30567/192.0.2.101 not found for delete
    Aug 27 17:06:39 linuxhost0 strongswan: 07[NET] received packet: from 192.0.2.101[500] to 192.0.2.102[500] (92 bytes)
    Aug 27 17:06:39 linuxhost0 strongswan: 07[ENC] parsed INFORMATIONAL_V1 request 3844915908 [ HASH N(DPD) ]
    Aug 27 17:06:39 linuxhost0 strongswan: 07[ENC] generating INFORMATIONAL_V1 request 3306289288 [ HASH N(DPD_ACK) ]
    Aug 27 17:06:39 linuxhost0 strongswan: 07[NET] sending packet: from 192.0.2.102[500] to 192.0.2.101[500] (92 bytes)
    Aug 27 17:06:39 linuxhost0 strongswan: 12[NET] received packet: from 192.0.2.101[500] to 192.0.2.102[500] (92 bytes)
    Aug 27 17:06:39 linuxhost0 strongswan: 12[ENC] parsed INFORMATIONAL_V1 request 4117118147 [ HASH N(DPD) ]
    Aug 27 17:06:39 linuxhost0 strongswan: 12[ENC] generating INFORMATIONAL_V1 request 257275019 [ HASH N(DPD_ACK) ]
    Aug 27 17:06:39 linuxhost0 strongswan: 12[NET] sending packet: from 192.0.2.102[500] to 192.0.2.101[500] (92 bytes)
    Aug 27 17:06:39 linuxhost0 strongswan: 07[NET] received packet: from 192.0.2.101[500] to 192.0.2.102[500] (92 bytes)
    Aug 27 17:06:39 linuxhost0 strongswan: 07[ENC] parsed INFORMATIONAL_V1 request 2274358397 [ HASH N(DPD) ]
    Aug 27 17:06:39 linuxhost0 strongswan: 07[ENC] generating INFORMATIONAL_V1 request 4076003362 [ HASH N(DPD_ACK) ]
    Aug 27 17:06:39 linuxhost0 strongswan: 07[NET] sending packet: from 192.0.2.102[500] to 192.0.2.101[500] (92 bytes)
    Aug 27 17:06:39 linuxhost0 strongswan: 10[NET] received packet: from 192.0.2.101[500] to 192.0.2.102[500] (92 bytes)
    Aug 27 17:06:39 linuxhost0 strongswan: 10[ENC] parsed INFORMATIONAL_V1 request 2971473291 [ HASH N(DPD) ]
    Aug 27 17:06:39 linuxhost0 strongswan: 10[ENC] generating INFORMATIONAL_V1 request 1067495819 [ HASH N(DPD_ACK) ]
    Aug 27 17:06:39 linuxhost0 strongswan: 10[NET] sending packet: from 192.0.2.102[500] to 192.0.2.101[500] (92 bytes)
    Aug 27 17:06:39 linuxhost0 strongswan: 11[NET] received packet: from 192.0.2.101[500] to 192.0.2.102[500] (92 bytes)
    Aug 27 17:06:39 linuxhost0 strongswan: 11[ENC] parsed INFORMATIONAL_V1 request 3184653391 [ HASH N(DPD) ]
    Aug 27 17:06:39 linuxhost0 strongswan: 11[ENC] generating INFORMATIONAL_V1 request 2060425617 [ HASH N(DPD_ACK) ]
    Aug 27 17:06:39 linuxhost0 strongswan: 11[NET] sending packet: from 192.0.2.102[500] to 192.0.2.101[500] (92 bytes)
    Aug 27 17:06:39 linuxhost0 strongswan: 10[NET] received packet: from 192.0.2.101[500] to 192.0.2.102[500] (92 bytes)
    Aug 27 17:06:39 linuxhost0 strongswan: 10[ENC] parsed INFORMATIONAL_V1 request 2458016713 [ HASH N(DPD) ]
    Aug 27 17:06:39 linuxhost0 strongswan: 10[ENC] generating INFORMATIONAL_V1 request 3714585430 [ HASH N(DPD_ACK) ]
    Aug 27 17:06:39 linuxhost0 strongswan: 10[NET] sending packet: from 192.0.2.102[500] to 192.0.2.101[500] (92 bytes)
    Aug 27 17:06:39 linuxhost0 strongswan: 05[NET] received packet: from 192.0.2.101[500] to 192.0.2.102[500] (92 bytes)
    Aug 27 17:06:39 linuxhost0 strongswan: 05[ENC] parsed INFORMATIONAL_V1 request 2996969408 [ HASH N(DPD) ]

Problem becames more weird as I have another site with RB2011UiAS-2HnD with ROS 6.27, it connects to another server in the same datacenter with absolutely same hardware an software (Linux host with Strongswan version 5, same builds, same connection settings but in Tunnel Mode) and everythings runs smoothly! Without rekeying issues from Mikrotik side:

  • Aug 30 10:03:03 linuxhost1 strongswan: 11[IKE] detected rekeying of CHILD_SA My-Glossy-IPSec{392}
    Aug 30 10:03:03 linuxhost1 strongswan: 11[ENC] generating QUICK_MODE response 3908604539 [ HASH SA No KE ID ID ]
    Aug 30 10:03:03 linuxhost1 strongswan: 11[NET] sending packet: from 192.0.2.12[500] to 192.0.2.11[500] (316 bytes)
    Aug 30 10:03:03 linuxhost1 strongswan: 07[NET] received packet: from 192.0.2.11[500] to 192.0.2.12[500] (60 bytes)
    Aug 30 10:03:03 linuxhost1 strongswan: 07[ENC] parsed QUICK_MODE request 3908604539 [ HASH ]
    Aug 30 10:03:03 linuxhost1 strongswan: 07[IKE] CHILD_SA My-Glossy-IPSec{392} established with SPIs c8d52db2_i 0f818cae_o and TS 192.168.57.0/24 === 192.168.2.0/24
    Aug 30 10:03:03 linuxhost1 strongswan: 05[NET] received packet: from 192.0.2.11[500] to 192.0.2.12[500] (92 bytes)
    Aug 30 10:03:03 linuxhost1 strongswan: 05[ENC] parsed INFORMATIONAL_V1 request 2357359639 [ HASH N(DPD) ]
    Aug 30 10:03:03 linuxhost1 strongswan: 05[ENC] generating INFORMATIONAL_V1 request 3312896096 [ HASH N(DPD_ACK) ]
    Aug 30 10:03:03 linuxhost1 strongswan: 05[NET] sending packet: from 192.0.2.12[500] to 192.0.2.11[500] (92 bytes)
    Aug 30 10:03:03 linuxhost1 strongswan: 05[IKE] sending DPD request
    Aug 30 10:03:03 linuxhost1 strongswan: 05[ENC] generating INFORMATIONAL_V1 request 1350979213 [ HASH N(DPD) ]
    Aug 30 10:03:03 linuxhost1 strongswan: 05[NET] sending packet: from 192.0.2.12[500] to 192.0.2.11[500] (92 bytes)
    Aug 30 10:03:03 linuxhost1 strongswan: 15[NET] received packet: from 192.0.2.11[500] to 192.0.2.12[500] (92 bytes)
    Aug 30 10:03:03 linuxhost1 strongswan: 15[ENC] parsed INFORMATIONAL_V1 request 3679142773 [ HASH N(DPD_ACK) ]
    Aug 30 10:03:03 linuxhost1 strongswan: 09[NET] received packet: from 192.0.2.11[500] to 192.0.2.12[500] (92 bytes)
    Aug 30 10:03:03 linuxhost1 strongswan: 09[ENC] parsed INFORMATIONAL_V1 request 3411493336 [ HASH N(DPD) ]
    Aug 30 10:03:03 linuxhost1 strongswan: 09[ENC] generating INFORMATIONAL_V1 request 3202597828 [ HASH N(DPD_ACK) ]
    Aug 30 10:03:03 linuxhost1 strongswan: 09[NET] sending packet: from 192.0.2.12[500] to 192.0.2.11[500] (92 bytes)
    Aug 30 10:03:03 linuxhost1 strongswan: 09[IKE] sending DPD request
    Aug 30 10:03:03 linuxhost1 strongswan: 09[ENC] generating INFORMATIONAL_V1 request 1917207016 [ HASH N(DPD) ]
    Aug 30 10:03:03 linuxhost1 strongswan: 09[NET] sending packet: from 192.0.2.12[500] to 192.0.2.11[500] (92 bytes)
    Aug 30 10:03:03 linuxhost1 strongswan: 12[NET] received packet: from 192.0.2.11[500] to 192.0.2.12[500] (92 bytes)
    Aug 30 10:03:03 linuxhost1 strongswan: 12[ENC] parsed INFORMATIONAL_V1 request 3645007545 [ HASH N(DPD_ACK) ]
    Aug 30 10:03:03 linuxhost1 strongswan: 04[NET] received packet: from 192.0.2.11[500] to 192.0.2.12[500] (92 bytes)
    Aug 30 10:03:03 linuxhost1 strongswan: 04[ENC] parsed INFORMATIONAL_V1 request 4267068721 [ HASH N(DPD) ]
    Aug 30 10:03:03 linuxhost1 strongswan: 04[ENC] generating INFORMATIONAL_V1 request 2604831734 [ HASH N(DPD_ACK) ]
    Aug 30 10:03:03 linuxhost1 strongswan: 04[NET] sending packet: from 192.0.2.12[500] to 192.0.2.11[500] (92 bytes)
    Aug 30 10:03:03 linuxhost1 strongswan: 04[IKE] sending DPD request
    Aug 30 10:03:03 linuxhost1 strongswan: 04[ENC] generating INFORMATIONAL_V1 request 476917384 [ HASH N(DPD) ]
    Aug 30 10:03:03 linuxhost1 strongswan: 04[NET] sending packet: from 192.0.2.12[500] to 192.0.2.11[500] (92 bytes)
    Aug 30 10:03:03 linuxhost1 strongswan: 11[NET] received packet: from 192.0.2.11[500] to 192.0.2.12[500] (92 bytes)
    Aug 30 10:03:03 linuxhost1 strongswan: 11[ENC] parsed INFORMATIONAL_V1 request 3206318713 [ HASH N(DPD_ACK) ]
    Aug 30 10:03:03 linuxhost1 strongswan: 07[NET] received packet: from 192.0.2.11[500] to 192.0.2.12[500] (92 bytes)

Log in RB2011UiAS-2HnD just empty.

I’ve updated CCR1016-12G to 6.30.2 - no effect. Attibutes not supported during rekey from CCR side.
Updated to lates version of Strongswan in repos (strongswan-5.3.2-1.el7.x86_64) - no effect.

So, let’s conclude:
CCR1016-12G <–IPSec Transport–> Strongswan 5 - works till 1-st rekey from CCR side
RB2011UiAS-2HnD <–IPSec Tunnel → Strongswan 5 - runs smoothly.

Here is Strongswan config:

# basic configuration

config setup
        # strictcrlpolicy=yes
        # uniqueids = no

# Add connections here.

conn %default
        ikelifetime=1440m
        keylife=60m
        rekeymargin=3m
        keyingtries=5
        authby=secret
        keyexchange=ikev1
        mobike=no

conn My-Shiny-IPSec
        left=192.0.2.102
        leftfirewall=yes
        right=192.0.2.101
        ike=aes128-sha1-modp1024
        esp=aes128-sha1-modp1024
        type=transport
        auto=start
        dpdaction=restart
        dpddelay=60s
        dpdtimeout=180s

#rekey = yes | no
#whether a connection should be renegotiated when it is about to expire. The two ends need not agree, but
#while a value of no prevents the daemon from requesting renegotiation, it does not prevent responding
#to renegotiation requested from the other end, so no will be largely ineffective unless both ends agree on it.

Same config on other host but different connection name.

CCR1016-12G settings:

/ip ipsec proposal print 
0  * name="default" auth-algorithms=sha1 enc-algorithms=aes-128-cbc lifetime=1h pfs-group=modp1024

/ip ipsec policy print 
src-address=192.0.2.101/32 src-port=any dst-address=192.0.2.102/32 dst-port=any protocol=all action=encrypt level=require ipsec-protocols=esp tunnel=no sa-src-address=192.0.2.101  
sa-dst-address=192.0.2.102 proposal=default priority=0

/ip ipsec peer print
address=192.0.2.102/32 local-address=192.0.2.101 passive=no port=500 auth-method=pre-shared-key secret="MyShinySecret" generate-policy=no policy-template-group=default exchange-mode=main 
send-initial-contact=yes nat-traversal=no proposal-check=obey hash-algorithm=sha1 enc-algorithm=aes-128 dh-group=modp1024 lifetime=1d lifebytes=0 dpd-interval=2m dpd-maximum-failures=5

What am I doing wrong?
Is this a problem with IPSec transport mode, CCR (tilegx) IPsec package (security), or both?
Is it possible to disable phase 2 rekey in CCR with just setting up passive=yes in ipsec peer config (I have not much time for expreiments)?
Overall, how to FIX this weird CCR behavior?

For now, I was pushed to temporarily use OpenVPN tunnel, but speed is so-so slow!
I need IPsec in transport mode with GRE/EoIP/IPIP/(Some analog).
Do not suggest me to use pure L2TP, I need encryption. And don’t tell me to use IPSec over L2TP (as everyone but Mikrotik use L2TP over IPSec :slight_smile:, sorry )

2

Problem is related to hw encryption driver used by CCR. We are working on solution right now.

3

Wow! I’ve almost lost hope! :slight_smile:
Greatly thanks for your feedback. I can’t help waiting ROS version with this fix. Can you approximately tell me when it will be released?

4

Same issue with IPSEC between CCR 1009 and Sophos UTM. I hope we get a fix asap.

5

Hello. Any chance to see a fix in foreseeable future?

6

Problem should be already fixed in latest v6.33rc version.

7

I’ve upgraded CCR to 6.33 (stable).
I can confirm that I don’t experience rekey problem since reboot.
Uptime is about 48 hours.
Thanks for solving this issue.