[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
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.
More information about the Users
mailing list