[strongSwan] checkpoint interoperability problem

Marco Berizzi pupilla at hotmail.com
Fri Jan 5 16:59:52 CET 2018

Hello everyone,

I have a very nasty problem with an ipsec tunnel between
strongswan 5.6.1 and a customer ipsec gateway (checkpoint).

This is my ipsec.conf tunnel configuration:

config setup
        # strictcrlpolicy=yes
        # uniqueids = no

conn %default
        keyexchange = ikev1

conn customer-

When I run 'ipsec up customer-' everything is in
good shape: main mode and quick mode are established.

The problem happens after few hours (when there is no traffic
from/to this ipsec tunnel).
If I try to ping a customer system, strongswan is trying to
do a quick mode to the customer peer, but the checkpoint start
the main mode and the quick mode is not established anymore
by strongswan.

16:02:36 10[KNL] creating acquire job for policy[icmp/8] ===[icmp/8] with reqid {239} 
16:02:36 10[ENC] generating QUICK_MODE request 1914820055 [ HASH SA No KE ID ID ] 
16:02:36 10[NET] sending packet: from[500] to[500] (444 bytes) 
16:02:36 11[NET] received packet: from[500] to[500] (152 bytes) 
16:02:36 11[ENC] parsed ID_PROT request 0 [ SA V V ] 
16:02:36 11[ENC] received unknown vendor ID: f4:ed:19:e0:c1:14:eb:51:6f:aa:ac:0e:e3:7d:af:28:07:b4:38:1f:00:00:00:01:00:00:13:8d:5a:4f:93:8b:00:00:00:00:18:28:00:00 
16:02:36 11[IKE] received FRAGMENTATION vendor ID 
16:02:36 11[IKE] is initiating a Main Mode IKE_SA 
16:02:36 11[ENC] generating ID_PROT response 0 [ SA V V V ] 
16:02:36 11[NET] sending packet: from[500] to[500] (144 bytes) 
16:02:36 09[NET] received packet: from[500] to[500] (312 bytes) 
16:02:36 09[ENC] parsed ID_PROT request 0 [ KE No ] 
16:02:36 09[ENC] generating ID_PROT response 0 [ KE No ] 
16:02:36 09[NET] sending packet: from[500] to[500] (324 bytes) 
16:02:36 05[NET] received packet: from[500] to[500] (76 bytes) 
16:02:36 05[ENC] parsed ID_PROT request 0 [ ID HASH ] 
16:02:36 05[CFG] looking for pre-shared key peer configs matching[] 
16:02:36 05[CFG] selected peer config "customer-" 
16:02:36 05[IKE] IKE_SA customer-[802] established between[]...[] 
16:02:36 05[IKE] scheduling reauthentication in 2723s 
16:02:36 05[IKE] maximum IKE_SA lifetime 3263s 
16:02:36 05[ENC] generating ID_PROT response 0 [ ID HASH ] 
16:02:36 05[NET] sending packet: from[500] to[500] (76 bytes) 
16:02:36 07[NET] received packet: from[500] to[500] (92 bytes) 
16:02:36 07[ENC] parsed INFORMATIONAL_V1 request 3913147254 [ HASH D ] 
16:02:36 07[IKE] received DELETE for different IKE_SA, ignored 
16:02:40 04[IKE] sending retransmit 1 of request message ID 1914820055, seq 4 
16:02:40 04[NET] sending packet: from[500] to[500] (444 bytes) 
16:02:46 13[IKE] deleting IKE_SA customer-[795] between[]...[] 
16:02:46 13[IKE] sending DELETE for IKE_SA customer-[795] 
16:02:46 13[ENC] generating INFORMATIONAL_V1 request 216163641 [ HASH D ] 
16:02:46 13[NET] sending packet: from[500] to[500] (92 bytes) 

It there any configuration option to tweak on my strongswan
side to fix this problem?

I have also found article sk118536 from checkpoint, but I'm
running IKEv1 and not IKEv2:


    VPN Site To Site with StrongSwan (mobile router using Linux with IPSec implementation) fails.
    Unstable VPN connection between the VPN peers.
    Security Gateway not able to create new keys with StrongSwan. 


There is a known issue with Strongswan that it only stores (and uses) keys that are re-keys of existing keys.

There are even scenarios when Strongswan peer itself starts a new Phase 2 exchange but never stores the exchanged keys because they are not re-keys of existing key and then we are not able to decrypt the traffic encrypted with the new keys.


Enable the following VPN kernel flag on the Security Gateway by running the command:

# fw ctl set int strongswan_bug_workaround 1

Note: this command does not survive a reboot.

In case it resolves the issue, the parameter can be set to survive reboot by modifying the file: $FWDIR/modules/vpnkern.conf
and adding the following line:


Note: if the file does not exist, create it.

With the flag on, the Security Gateway only store new keys if they are re-keys of existing ones (or if there are no existing ones).

Note that this flag is relevant to IKEv2 only.

More information about the Users mailing list