[strongSwan] checkpoint interoperability problem

Thu Jan 11 13:29:59 CET 2018

Hi,

That's weird behaviour that I've seen with checkpoints, too. I think the right solution is to stop the checkpoint from initiating main mode on its own.

Kind regards

Noel

On 05.01.2018 16:59, Marco Berizzi wrote:
> 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
>         keyingtries=%forever
>         #left=%defaultroute
>         keyexchange = ikev1
>
> conn customer-10.0.16.0
>         left=205.223.229.254
>         right=213.255.45.11
>         leftsubnet=192.168.121.0/28
>         rightsubnet=10.0.16.0/21
>         authby=secret
>         auto=route
>         ike=aes256-sha1-modp2048
>         esp=aes256-sha1-modp2048
>         compress=no
>         leftid=205.223.229.254
>         keyingtries=%forever
>         keylife=1h
>         ikelifetime=1h
>
> When I run 'ipsec up customer-10.0.16.0' 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 192.168.121.14/32[icmp/8] === 10.0.20.16/32[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 205.223.229.254[500] to 213.255.45.11[500] (444 bytes) 
> 16:02:36 11[NET] received packet: from 213.255.45.11[500] to 205.223.229.254[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] 213.255.45.11 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 205.223.229.254[500] to 213.255.45.11[500] (144 bytes) 
> 16:02:36 09[NET] received packet: from 213.255.45.11[500] to 205.223.229.254[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 205.223.229.254[500] to 213.255.45.11[500] (324 bytes) 
> 16:02:36 05[NET] received packet: from 213.255.45.11[500] to 205.223.229.254[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 205.223.229.254...213.255.45.11[213.255.45.11] 
> 16:02:36 05[CFG] selected peer config "customer-10.0.16.0" 
> 16:02:36 05[IKE] IKE_SA customer-10.0.16.0[802] established between 205.223.229.254[205.223.229.254]...213.255.45.11[213.255.45.11] 
> 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 205.223.229.254[500] to 213.255.45.11[500] (76 bytes) 
> 16:02:36 07[NET] received packet: from 213.255.45.11[500] to 205.223.229.254[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 205.223.229.254[500] to 213.255.45.11[500] (444 bytes) 
> 16:02:46 13[IKE] deleting IKE_SA customer-10.0.16.0[795] between 205.223.229.254[205.223.229.254]...213.255.45.11[213.255.45.11] 
> 16:02:46 13[IKE] sending DELETE for IKE_SA customer-10.0.16.0[795] 
> 16:02:46 13[ENC] generating INFORMATIONAL_V1 request 216163641 [ HASH D ] 
> 16:02:46 13[NET] sending packet: from 205.223.229.254[500] to 213.255.45.11[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:
>
> Symptoms
>
>     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. 
>
> Cause
>
> 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.
>
> Solution
>
> 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:
>
> strongswan_bug_workaround=1
>
> 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.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: OpenPGP digital signature
URL: <http://lists.strongswan.org/pipermail/users/attachments/20180111/f544d264/attachment-0001.sig>