Re: [strongSwan] disable sending vendor id

[Marco Berizzi]

Hello Tobias,

thank you for your kind reply.

Undoubtedly the message reported by
microsoft about the introduction of
regression is rather unclear.

Marco

From: Tobias Brunner 
Sent: Monday, January 17, 2022 2:49 PM
To: Marco Berizzi ; users@lists.strongswan.org 

Subject: Re: [strongSwan] disable sending vendor id 
 
Hi Marco,

> kindly, I would like to know if there is a way to
> make strongswan not send the 'vendor id'.

There is currently no option to generally disable Vendor IDs as some are 
basically integral part of IKEv1 e.g. to use XAuth or DPDs, and 
especially to negotiate NAT-Traversal (only the strongSwan and Cisco 
Unity vendor IDs can be disabled with individual settings, both are 
disabled by default).

Better use IKEv2 anyway.

Regards,
Tobias

Re: [strongSwan] disable sending vendor id

[Marco Berizzi]

Hello,

yes indeed, you are right.
I noticed, unfortunately the regression
introduced by microsoft is not fixable
from strongswan's point of view.

Marco

From: Rajiv Kulkarni 
Sent: Monday, January 17, 2022 1:10 PM
To: Marco Berizzi 
Cc: users@lists.strongswan.org 
Subject: Re: [strongSwan] disable sending vendor id 
 
Hi 

Actually, by default Strongswan is configured with NOT sending Vendor_idbut 
you can make it explicit by enabling/uncommenting the setting in 
"../Strongswan.d/charon.conf" file as below:

# Send strongSwan vendor ID payload                                    
  send_vendor_id = no

hope this helps

thanks & regards
Rajiv




On Fri, Jan 14, 2022 at 3:10 PM Marco Berizzi  wrote:
Hello everyone,

kindly, I would like to know if there is a way to 
make strongswan not send the 'vendor id'. 
Unfortunately the windows 10 update kb5009543 
introduced this regression:

"After installing this update, IP Security 
(IPSEC) connections that contain a Vendor ID might 
fail. VPN connections using Layer 2 Tunneling 
Protocol (L2TP) or IP security Internet Key 
Exchange (IPSEC IKE) might also be affected.


To mitigate the issue for some VPNs, you can 
disable Vendor ID within the server-side 
settings.

Note Not all VPN servers have the option to 
disable Vendor ID from being used.

We are presently investigating and will provide an 
update in an upcoming release."

Thanks in advance
Marco

[strongSwan] disable sending vendor id

[Marco Berizzi]

Hello everyone,

kindly, I would like to know if there is a way to 
make strongswan not send the 'vendor id'. 
Unfortunately the windows 10 update kb5009543 
introduced this regression:

"After installing this update, IP Security 
(IPSEC) connections that contain a Vendor ID might 
fail. VPN connections using Layer 2 Tunneling 
Protocol (L2TP) or IP security Internet Key 
Exchange (IPSEC IKE) might also be affected.


To mitigate the issue for some VPNs, you can 
disable Vendor ID within the server-side 
settings.

Note Not all VPN servers have the option to 
disable Vendor ID from being used.

We are presently investigating and will provide an 
update in an upcoming release."

Thanks in advance
Marco

[strongSwan] negative rekeying time from swanctl -l

[Marco Berizzi]

Hello everyone,

I have encountered that the output of 'swanctl -l' sometimes returns a negative 
value on the rekeying time. Does it have any sort of special meaning?

installed 890s ago, rekeying in -684s, expires in 10s

Marco

Re: [strongSwan] disregarded diffie hellmann group

[Marco Berizzi]

Hi Tobias,

apologies for the late response.

> You didn't clarify if that happens during a CHILD_SA initiation with
> IKE_AUTH or with CREATE_CHILD_SA.

According to the swanctl output it is happening with CHILD_SA initiation
with IKE_AUTH:

[IKE] initiating IKE_SA [146788]
[ENC] generating IKE_SA_INIT request 0 [ SA KE No N(NATD_S_IP) N(NATD_D_IP) 
N(FRAG_SUP) N(HASH_ALG) N(REDIR_SUP) ]
[ENC] parsed IKE_SA_INIT response 0 [ SA KE No N(NATD_S_IP) N(NATD_D_IP) 
N(CHDLESS_SUP) ]
[CFG] selected proposal: 
IKE:AES_CBC_256/HMAC_SHA2_256_128/PRF_HMAC_SHA2_256/ECP_384
[IKE] establishing CHILD_SA networks2{1872399}
[ENC] generating IKE_AUTH request 1 [ IDi N(INIT_CONTACT) IDr AUTH SA TSi TSr 
N(EAP_ONLY) N(MSG_ID_SYN_SUP) ]
[ENC] parsed IKE_AUTH response 1 [ IDr AUTH N(CRASH_DET) SA TSi TSr 
N(ESP_TFC_PAD_N) N(NON_FIRST_FRAG) ]
[IKE] scheduling reauthentication in 40155s
[IKE] maximum IKE_SA lifetime 44475s
[IKE] received ESP_TFC_PADDING_NOT_SUPPORTED, not using ESPv3 TFC padding
[CFG] selected proposal: ESP:AES_CBC_256/HMAC_SHA2_256_128/NO_EXT_SEQ
[IKE] CHILD_SA networks2{1872399} established with SPIs cdb597cf_i 8630bd6e_o 
and TS 10.159.240.0/30 === 10.176.194.0/24
initiate completed successfully

with CREATE_CHILD_SA instead everything looks good: the dhgroup is there.

[IKE] establishing CHILD_SA networks3{1872407}
[ENC] generating CREATE_CHILD_SA request 2 [ SA No KE TSi TSr ]
[ENC] parsed CREATE_CHILD_SA response 2 [ SA No KE TSi TSr N(ESP_TFC_PAD_N) 
N(NON_FIRST_FRAG) ]
[IKE] received ESP_TFC_PADDING_NOT_SUPPORTED, not using ESPv3 TFC padding
[CFG] selected proposal: ESP:AES_CBC_256/HMAC_SHA2_256_128/ECP_384/NO_EXT_SEQ
[IKE] CHILD_SA networks3{1872407} established with SPIs c5e40f32_i ee9e59b2_o 
and TS 10.159.240.0/30 === 10.96.101.0/24
initiate completed successfully

> During IKE_AUTH, the DH group is always omitted, so it really
> shouldn't matter who is initiator (and removing the DH group from
> the proposal doesn't make a difference). However, during
> CREATE_CHILD_SA DH is optional.  But enforcing a DH group as
> responder and not proposing one as initiator of the same CHILD_SA
> doesn't really make sense.  So if that's the case, it sounds like
> a bug.

thanks for the clarification Tobias.

Marco

Re: [strongSwan] disregarded diffie hellmann group

[Marco Berizzi]

Hi Tobias,

> You don't have to change the config as long as both peers agree to use a
> DH group when rekeying or creating the SA with a CREATE_CHILD_SA
> exchange.

I tried to remove the dh group, but if my ipsec peer running strongswan
is the initiator the proposal will be refused.

> You only need that second proposal (or adding modpnone at the
> end of the existing proposal) if there is a peer that doesn't use a DH
> group in these situations.

It looks like the other peer (which should be a checkpoint) when acting
as a responder claim the dhgroup. Instead when acting as initiator is
going to drop the dh group request.

Thanks Tobias. I didn't know the modpnone parameter: I will change the
proposal like this:

esp_proposals = aes256-sha512-ecp521-modpnone

Marco

Re: [strongSwan] disregarded diffie hellmann group

[Marco Berizzi]

> [1] https://wiki.strongswan.org/projects/strongswan/wiki/ExpiryRekey#IKEv2

Thanks for the hints, Tobias.
I have patched the configuration like this:

from esp_proposals = aes256-sha512-ecp521
to esp_proposals = aes256-sha512-ecp521,aes256-sha512

Marco

[strongSwan] disregarded diffie hellmann group

[Marco Berizzi]

Hello everyone,

I'm experimenting a problem with an IKEv2 tunnel to a customer.
I'm running strongswan 5.8.4, compiled from sources.
This is my configuration file:

children {
 networks1 {
local_ts  = 10.101.32.0/30
remote_ts = 10.101.10.0/25

start_action = trap
esp_proposals = aes256-sha512-ecp521
rekey_time = 3600
dpd_action = restart
 }
 networks2 {
local_ts  = 10.101.32.0/30
remote_ts = 10.101.16.0/24

start_action = trap
esp_proposals = aes256-sha512-ecp521
rekey_time = 3600
dpd_action = restart


Sometimes the customer ipsec peer is acting as the initiator
and for some reason it is going to propose the aes256-sha512
without any diffie-hellmann group, and strongswan will
accept it. Here is the log message:

received proposals: ESP:AES_CBC_256/HMAC_SHA2_512_256/NO_EXT_SEQ
configured proposals: ESP:AES_CBC_256/HMAC_SHA2_512_256/ECP_521/NO_EXT_SEQ
selected proposal: ESP:AES_CBC_256/HMAC_SHA2_512_256/NO_EXT_SEQ

and this is the 'swanctl -l' output:

ESTABLISHED, IKEv2, 60de91499e6b7dfa_i 77c55b0c87bc1cae_r*
AES_CBC-256/HMAC_SHA2_512_256/PRF_HMAC_SHA2_512/ECP_521
established 885s ago, reauth in 79513s

networks1: #1849832, reqid 811, INSTALLED, TUNNEL, 
ESP:AES_CBC-256/HMAC_SHA2_512_256
installed 722s ago, rekeying in 2532s, expires in 3238s
in  c9057fde,  0 bytes, 0 packets
out 38bfaa76,  10320 bytes,   258 packets, 4s ago
local  10.101.32.0/30
remote 10.101.10.0/25
networks2: #1849845, reqid 813, INSTALLED, TUNNEL, 
ESP:AES_CBC-256/HMAC_SHA2_512_256/ECP_521
installed 692s ago, rekeying in 2577s, expires in 3268s
in  c53b9387, 7143044 bytes,  7957 packets, 1s ago
out 38bfaa77, 1337085 bytes,  7138 packets, 1s ago
local  10.101.32.0/30
remote 10.101.16.0/24

As you can see, one traffic selector is correctly established
(network2) and other (network1) is not correct.

Is there any configuration tweak that should be done to
reject the proposal without the diffie hellmann group?

Thanks
Marco

Re: [strongSwan] strongswan 5.8.3 core dump

[Marco Berizzi]

Hello Tobias,

> I pushed a fix to master [1].  I guess we'll be releasing 5.8.4 soon.

I have applied your fix and after 5 hours, everything is in good shape.
Thanks a lot Tobias for the quick response and fix.

Cheers,

Marco

PS: Here is the log:

[CFG]  found matching child config 
"apsil-10.221.128.183" with prio 6
[CFG]  selecting traffic selectors for other:
[CFG]   config: 10.221.128.183/32, received: 
10.221.0.0/16 => match: 10.221.128.183/32
[CFG]  selecting traffic selectors for us:
[CFG]   config: 10.240.123.0/26, received: 
10.240.123.0/26 => match: 10.240.123.0/26
[CFG]  selecting proposal:
[CFG]no acceptable DIFFIE_HELLMAN_GROUP found
[CFG]  selecting proposal:
[CFG]no acceptable ENCRYPTION_ALGORITHM found
[CFG]  received proposals: 
ESP:3DES_CBC/HMAC_SHA1_96/NO_EXT_SEQ
[CFG]  configured proposals: 
ESP:3DES_CBC/HMAC_SHA1_96/MODP_1024/NO_EXT_SEQ, 
ESP:AES_CBC_128/AES_CBC_192/AES_CBC_256/HMAC_SHA2_256_128/HMAC_SHA2_384_192/HMAC_SHA2_512_256/HMAC_SHA1_96/AES_XCBC_96/NO_EXT_SEQ
[IKE]  no matching proposal found, sending 
NO_PROPOSAL_CHOSEN
[IKE]  queueing INFORMATIONAL task
[IKE]  delaying task initiation, QUICK_MODE exchange 
in progress

Re: [strongSwan] strongswan 5.8.3 core dump

[Marco Berizzi]

Hello Tobias,

Here is the charon.log: I hope it will be useful for you.

[CFG]  found matching child config 
"apsil-10.221.128.183" with prio 6
[CFG]  selecting traffic selectors for other:
[CFG]   config: 10.221.128.183/32, received: 
10.221.0.0/16 => match: 10.221.128.183/32
[CFG]  selecting traffic selectors for us:
[CFG]   config: 10.240.123.0/26, received: 
10.240.123.0/26 => match: 10.240.123.0/26
[CFG]  selecting proposal:
[CFG]no acceptable DIFFIE_HELLMAN_GROUP found
[CFG]  selecting proposal:
[CFG]no acceptable ENCRYPTION_ALGORITHM found
[CFG]  received proposals: 
ESP:3DES_CBC/HMAC_SHA1_96/NO_EXT_SEQ
[CFG]  configured proposals: 
ESP:3DES_CBC/HMAC_SHA1_96/MODP_1024/NO_EXT_SEQ, 
ESP:AES_CBC_128/AES_CBC_192/AES_CBC_256/HMAC_SHA2_256_128/HMAC_SHA2_384_192/HMAC_SHA2_512_256/HMAC_SHA1_96/AES_XCBC_96/NO_EXT_SEQ
[DMN]  thread 15 received 11
[LIB]   dumping 11 stack frame addresses:
[LIB]/lib64/libpthread.so.0 @ 0x7f100083d000 
[0x7f100084e3b0]
[LIB]  -> ??:?
[LIB]/usr/local/lib/ipsec/libcharon.so.0 @ 
0x7f1000d63000 [0x7f1000d86603]
[LIB]  -> 
/tmp/STRONGSWAN/strongswan-5.8.3/src/libcharon/encoding/payloads/sa_payload.c:411
[LIB]/usr/local/lib/ipsec/libcharon.so.0 @ 
0x7f1000d63000 [0x7f1000dc6ab7]
[LIB]  -> 
/tmp/STRONGSWAN/strongswan-5.8.3/src/libcharon/sa/ikev1/tasks/quick_mode.c:748
[LIB]/usr/local/lib/ipsec/libcharon.so.0 @ 
0x7f1000d63000 [0x7f1000dc8d1c]
[LIB]  -> 
/tmp/STRONGSWAN/strongswan-5.8.3/src/libcharon/sa/ikev1/tasks/quick_mode.c:1153
[LIB]/usr/local/lib/ipsec/libcharon.so.0 @ 
0x7f1000d63000 [0x7f1000dbc70d]
[LIB]  -> 
/tmp/STRONGSWAN/strongswan-5.8.3/src/libcharon/sa/ikev1/task_manager_v1.c:1081
[LIB]/usr/local/lib/ipsec/libcharon.so.0 @ 
0x7f1000d63000 [0x7f1000d94a77]
[LIB]  -> 
/tmp/STRONGSWAN/strongswan-5.8.3/src/libcharon/sa/ike_sa.c:1587
[LIB]/usr/local/lib/ipsec/libcharon.so.0 @ 
0x7f1000d63000 [0x7f1000d8c111]
[LIB]  -> 
/tmp/STRONGSWAN/strongswan-5.8.3/src/libcharon/processing/jobs/process_message_job.c:74
[LIB]/usr/local/lib/ipsec/libstrongswan.so.0 @ 
0x7f1000ff5000 [0x7f100102cb83]
[LIB]  -> 
/tmp/STRONGSWAN/strongswan-5.8.3/src/libstrongswan/processing/processor.c:235
[LIB]/usr/local/lib/ipsec/libstrongswan.so.0 @ 
0x7f1000ff5000 [0x7f100103e4b7]
[LIB]  -> 
/tmp/STRONGSWAN/strongswan-5.8.3/src/libstrongswan/threading/thread.c:332 
(discriminator 3)
[LIB]/lib64/libpthread.so.0 @ 0x7f100083d000 
[0x7f1000844684]
[LIB]  -> ??:?
[LIB]/lib64/libc.so.6 @ 0x7f100027 
(clone+0x6d) [0x7f1000376eed]
[LIB]  -> ??:?
[DMN]  killing ourself, received critical signal


From: Tobias Brunner 

Sent: Wednesday, March 25, 2020 3:07 PM

To: Marco Berizzi ; users@lists.strongswan.org 


Subject: Re: [strongSwan] strongswan 5.8.3 core dump

 


Hi Marco,



> What should I do to debug it?



First, not stripping symbols/debug information from binaries probably

would help.  Then you might already see what the problem is.  Otherwise

try attaching a debugger or use one to analyze the core dump (if one is

created).



Regards,

Tobias

Re: [strongSwan] strongswan 5.8.3 core dump

[Marco Berizzi]

Thanks Tobias,

I have run again 'make install', without stripping anymore the symbols.
I'm waiting the crash.

Thanks again.

From: Tobias Brunner 

Sent: Wednesday, March 25, 2020 3:07 PM

To: Marco Berizzi ; users@lists.strongswan.org 


Subject: Re: [strongSwan] strongswan 5.8.3 core dump

 


Hi Marco,



> What should I do to debug it?



First, not stripping symbols/debug information from binaries probably

would help.  Then you might already see what the problem is.  Otherwise

try attaching a debugger or use one to analyze the core dump (if one is

created).



Regards,

Tobias

[strongSwan] strongswan 5.8.3 core dump

[Marco Berizzi]

Hello everyone,

I have just upgraded to 5.8.3 running on Slackware linux 64 bit.

I'm getting this message on charon.log

thread 4 received 11
 dumping 11 stack frame addresses:
  /lib64/libpthread.so.0 @ 0x7f7ea89a4000 [0x7f7ea89b53b0]
-> ??:?
  /usr/local/lib/ipsec/libcharon.so.0 @ 0x7f7ea8eca000 [0x7f7ea8eed603]
-> ??:?
  /usr/local/lib/ipsec/libcharon.so.0 @ 0x7f7ea8eca000 [0x7f7ea8f2dab7]
-> ??:?
  /usr/local/lib/ipsec/libcharon.so.0 @ 0x7f7ea8eca000 [0x7f7ea8f2fd1c]
-> ??:?
  /usr/local/lib/ipsec/libcharon.so.0 @ 0x7f7ea8eca000 [0x7f7ea8f2370d]
-> ??:?
  /usr/local/lib/ipsec/libcharon.so.0 @ 0x7f7ea8eca000 [0x7f7ea8efba77]
-> ??:?
  /usr/local/lib/ipsec/libcharon.so.0 @ 0x7f7ea8eca000 [0x7f7ea8ef3111]
-> ??:?
  /usr/local/lib/ipsec/libstrongswan.so.0 @ 0x7f7ea915c000 [0x7f7ea9193b83]
-> ??:?
  /usr/local/lib/ipsec/libstrongswan.so.0 @ 0x7f7ea915c000 [0x7f7ea91a54b7]
-> ??:?
  /lib64/libpthread.so.0 @ 0x7f7ea89a4000 [0x7f7ea89ab684]
-> ??:?
  /lib64/libc.so.6 @ 0x7f7ea83d7000 (clone+0x6d) [0x7f7ea84ddeed]
-> ??:?
killing ourself, received critical signal

What should I do to debug it?

Thanks

Marco

[strongSwan] Route-based VPNs (XFRM Interfaces) vs policies based VPNs

[Marco Berizzi]

Hello everyone,

I need to setup a 0.0.0.0/0 to 0.0.0.0/0 ipsec tunnel.
I was thinking to setup it with the new xfrm interfaces:
I don't need route all the 0.0.0.0/0 throught this vpn.

My question is how 'route based' and 'policies based'
VPNs will coexist on the same linux box.

For example, if I'm going to implement a 0.0.0.0/0 to
0.0.0.0/0 vpn with the xfrm interfaces and then I will
route the traffic only for the 155.192.168.0/24 network
throught the ipsec0 device (for example), and then I
implement a classic policy based vpn (without the xfrm
interface) with the following traffic selectors
166.172.16.0/24 and 177.16.172.0/24, what will happen?
Will the linux kernel process the packets for the
166.172.16.0/24 and 177.16.172.0/24 into the right ipsec
policy?

Thanks

Marco

[strongSwan] fortiOS multiple pair of selectors per CHILD_SA

[Marco Berizzi]

I have successfully established an ipsec IKEv2 tunnel
with a fortigate 1200D/FortiOS v5.2.4

It is the first device where I'm able to get multiple
pair of selectors per CHILD_SA.

The tricky thing to pay attention, is the comma separated
list sequence, in the remote_ts parameter.
For example, this sequence was rejected by the remote
peer:

remote_ts = 192.168.32.0/24,10.20.29.75/32

with the following error message:

[IKE] received TS_UNACCEPTABLE notify, no CHILD_SA built
[IKE] failed to establish CHILD_SA, keeping IKE_SA

instead the following one was working:

remote_ts = 10.20.29.75/32,192.168.32.0/24

Is this the expected behavior by RFC?

Re: [strongSwan] Security Comparison

[Marco Berizzi]

Hi Andreas,

> actually X25519 DH group 31 has a security strength of 128 bits, similar
> to ECP-256, although the Curve25519 characteristics are much better
> than those of the ECP-256 NIST curve.

thanks for the correction.

[strongSwan] Security Comparison

[Marco Berizzi]

Hi Tobias,

I think this is an underestimated point. Deserves more attention.

> The cryptographic strength of all ciphers in a cipher suite should be
> consistent.  For instance, using AES-256 for ESP is basically wasted
> when using MODP-2048 because that has only an estimated strength of 112
> bits (same for ECP-256 whose estimated strength is 128 bits).

Adding your above remark to [3] would be extremely useful.

According to this paper [1] MODP-1536 is broken (< 112 bits of security
strength), and according to this nist publication [2], the only way to
be consistent with AES-256 is ECP-521 (diffie hellmann group 21) or x25519
(diffie hellmann group 31).

The MODP-3072 or ECP-256 is the minimum for being consistent with AES-128.

So a simple consistent table could be:

AES-128 ==>> MODP-3072 or ECP-256
AES-192 ==>> MODP-8192 or ECP-384
AES-256 ==>> ECP521 or x25519

[1] 
https://csrc.nist.gov/csrc/media/publications/sp/800-131a/rev-1/final/documents/sp800-131a_r1_draft.pdf
[2] 
https://nvlpubs.nist.gov/nistpubs/specialpublications/nist.sp.800-57pt1r4.pdf
[3] https://wiki.strongswan.org/projects/strongswan/wiki/SecurityRecommendations

Re: [strongSwan] ipsec statusall: missing number of packets output

[Marco Berizzi]

Hi Tobias,
 
> Hi Marco,
> 
> > Kindly I would like to ask if there is any know reason
> > why ipsec statusall sometimes doesn't print the number
> > of packets for the child_sa.
> 
> The number of packets is printed if a last use time can be determined
> via the respective policy.  Check the log for errors regarding querying
> the inbound policy (you could increase the log level for knl to see a
> bit more about the interaction with the kernel).

After nearly 2 months it happened again:

ts-20.96.144.0{126302}:  INSTALLED, TUNNEL, reqid 244, ESP SPIs: cd63dff4_i 
5215984b_o
ts-20.96.144.0{126302}:  AES_CBC_256/HMAC_SHA2_256_128/ECP_384, 2988620 bytes_i 
(6591 pkts, 314s ago), 2048852 bytes_o, rekeying in 5 hours
ts-20.96.144.0{126302}:   10.28.155.0/24 === 20.96.144.0/23
ts-20.96.216.0{126305}:  INSTALLED, TUNNEL, reqid 246, ESP SPIs: c5504cbc_i 
5d35c82a_o
ts-20.96.216.0{126305}:  AES_CBC_256/HMAC_SHA2_256_128/ECP_384, 169442 bytes_i, 
40867 bytes_o (169 pkts, 301s ago), rekeying in 6 hours
ts-20.96.216.0{126305}:   10.28.155.0/24 === 
20.96.216.0/21ts-20.96.226.0{126325}:  INSTALLED, TUNNEL, reqid 247, ESP SPIs: 
c28f61dc_i e0a84ea4_o
ts-20.96.226.0{126325}:  AES_CBC_256/HMAC_SHA2_256_128/ECP_384, 58816 bytes_i, 
61681 bytes_o (243 pkts, 261s ago), rekeying in 6 hours
ts-20.96.226.0{126325}:   10.28.155.0/24 === 20.96.226.0/24

Now, charon is logging to /var/log/charon.log (setup copied
and pasted from [1].

What should I grep? :-)

I have also the output from 'ip -s x p' and 'ip -s x s'

[1] https://wiki.strongswan.org/projects/strongswan/wiki/HelpRequests)

Re: [strongSwan] UNSUPPORTED_CRITICAL_PAYLOAD

[Marco Berizzi]

Hi Tobias,

> As strongSwan is the initiator of the exchange and the peer is a
> Windows 10 host I'd guess that this is a rekeying.  So it could also
> be because it doesn't like being responder of a rekeying (Windows
> has/had the same problem with IKEv2 CHILD_SA rekeyings, see [1]).

You are right. My fault. The problem was the lifetime/ikelifetime:
I have decreased it on the strongSwan side and I forgot to update the
windows clients. So strongSwan become the initiator and the problem
has been popped up.

Sorry for the spam.

[strongSwan] UNSUPPORTED_CRITICAL_PAYLOAD

[Marco Berizzi]

Hello everyone,

I'm getting a lot of this kind of UNSUPPORTED_CRITICAL_PAYLOAD
from many windows 10 laptops.
Anyone has an idea of what could the problem be?

generating QUICK_MODE request 3970887770 [ HASH SA No KE ID ID ]
sending packet: from 10.81.110.254[500] to 10.81.126.89[500] (396 bytes)
received packet: from 10.81.126.89[500] to 10.81.110.254[500] (76 bytes)
parsed INFORMATIONAL_V1 request 1775796517 [ HASH N(CRIT) ]
received UNSUPPORTED_CRITICAL_PAYLOAD error notify

Thanks

Re: [strongSwan] ipsec statusall: missing number of packets output

[Marco Berizzi]

Hi Tobias,

> The number of packets is printed if a last use time can be determined
> via the respective policy.

thanks for the explanation. Indeed that policy was problematic:
packets were going out, but not viceversa.
After an "ipsec down child_sa" and "ipsec up child_sa" traffic
was full duplex again. But I need to understand why this is
happening. This is an ikev2 tunnel to a CrapPoint R77.30:
every few days this problem is popping up.

> Check the log for errors regarding querying
> the inbound policy (you could increase the log level for knl to see a
> bit more about the interaction with the kernel).

this is my log configuration:

stderr {
# more detailed loglevel for a specific subsystem, overriding the
# default loglevel.
ike = 2
knl = 3
}

is it enough knl = 3 ?

[strongSwan] ipsec statusall: missing number of packets output

[Marco Berizzi]

Hello everyone,

Kindly I would like to ask if there is any know reason
why ipsec statusall sometimes doesn't print the number
of packets for the child_sa. Here is an example for the
bytes_i:

ts-net{453}:  AES_CBC_256/HMAC_SHA2_256_128/ECP_384, 1467110312 bytes_i, 
3075678241 bytes_o (2443951 pkts, 49s ago), rekeying in 3 hours

Instead here is another example where the output is
complete:

ts-net{1165}: AES_CBC_256/HMAC_SHA2_256_128/ECP_384, 8452 bytes_i (211 pkts, 
19s ago), 9360 bytes_o (213 pkts, 168s ago), rekeying in 7 hours

strongswan version is 5.6.3dr1

Thanks

Re: [strongSwan] multiple traffic selectors per child_sa

[Marco Berizzi]

Hi Tobias,

Thanks for the nice explanation.

> This is not a negotiated feature.  You might just see a peer narrowing
> the traffic selectors to only one the client proposed.  But it could
> also do that for other reasons (e.g. a mismatching configuration).
> Support for multiple traffic selectors is a core feature of IKEv2, but
> due to traffic selector narrowing it's easy to avoid having to implement
> it I guess.

> There is a notify that could be sent, ADDITIONAL_TS_POSSIBLE, which
> indicates that some of the not selected TS could be applied in a
> separate CHILD_SA (but which ones, or in which combination, is not
> communicated).  Not sure if anybody implements that (we currently don't
> have any support for it).  Another notify we don't support is
> SINGLE_PAIR_REQUIRED, which indicates that the responder requires
> separate CHILD_SAs for each pair of IP addresses that could match the
> proposed ranges (but the RFC discourages its use and recommends to just
> narrow the TS).

unfortunately I see only this endless log when my remote_ts is
like this on my swanctl.conf:

remote_ts = 
10.213.56.0/21,10.213.100.0/24,10.213.14.0/23,10.213.10.0/23,10.213.29.0/24,10.213.118.0/24,10.213.124.0/24,10.213.249.0/24,10.213.16.0/24,10.213.126.0/24,10.213.154.0/24

May 11 08:58:48 Enceladus charon: 09[KNL] creating rekey job for CHILD_SA 
ESP/0xc3d57caa/205.223.229.254 
May 11 08:58:48 Enceladus charon: 09[IKE] establishing CHILD_SA 
customer-networks{1890} reqid 248 
May 11 08:58:48 Enceladus charon: 12[KNL] creating rekey job for CHILD_SA 
ESP/0xe2f3c155/91.240.166.5 
May 11 08:58:48 Enceladus charon: 09[ENC] generating CREATE_CHILD_SA request 
304 [ N(REKEY_SA) SA No KE TSi TSr ] 
May 11 08:58:48 Enceladus charon: 09[NET] sending packet: from 
205.223.229.254[500] to 91.240.166.5[500] (656 bytes) 
May 11 08:58:48 Enceladus charon: 13[NET] received packet: from 
91.240.166.5[500] to 205.223.229.254[500] (528 bytes) 
May 11 08:58:48 Enceladus charon: 13[ENC] parsed CREATE_CHILD_SA response 304 [ 
SA No KE TSi TSr ] 
May 11 08:58:48 Enceladus charon: 13[IKE] inbound CHILD_SA 
customer-networks{1890} established with SPIs c48dde95_i 3c072ec0_o and TS 
10.28.157.0/24 === 10.213.56.0/21 
May 11 08:58:48 Enceladus charon: 13[IKE] outbound CHILD_SA 
customer-networks{1890} established with SPIs c48dde95_i 3c072ec0_o and TS 
10.28.157.0/24 === 10.213.56.0/21 
May 11 08:58:48 Enceladus charon: 13[IKE] closing CHILD_SA 
customer-networks{1889} with SPIs c3d57caa_i (174062 bytes) e2f3c155_o (21692 
bytes) and TS 10.28.157.0/24 === 10.213.56.0/21 
May 11 08:58:48 Enceladus charon: 13[IKE] sending DELETE for ESP CHILD_SA with 
SPI c3d57caa 
May 11 08:58:48 Enceladus charon: 13[ENC] generating INFORMATIONAL request 305 
[ D ] 
May 11 08:58:48 Enceladus charon: 13[NET] sending packet: from 
205.223.229.254[500] to 91.240.166.5[500] (96 bytes) 
May 11 08:58:48 Enceladus charon: 08[NET] received packet: from 
91.240.166.5[500] to 205.223.229.254[500] (96 bytes) 
May 11 08:58:48 Enceladus charon: 08[ENC] parsed INFORMATIONAL response 305 [ D 
] 
May 11 08:58:48 Enceladus charon: 08[IKE] received DELETE for ESP CHILD_SA with 
SPI e2f3c155 
May 11 08:58:48 Enceladus charon: 08[IKE] CHILD_SA closed 
May 11 08:58:49 Enceladus charon: 03[KNL] creating rekey job for CHILD_SA 
ESP/0xc48dde95/205.223.229.254 
May 11 08:58:49 Enceladus charon: 03[IKE] establishing CHILD_SA 
customer-networks{1891} reqid 248 
May 11 08:58:49 Enceladus charon: 09[KNL] creating rekey job for CHILD_SA 
ESP/0x3c072ec0/91.240.166.5 
May 11 08:58:49 Enceladus charon: 03[ENC] generating CREATE_CHILD_SA request 
306 [ N(REKEY_SA) SA No KE TSi TSr ] 
May 11 08:58:49 Enceladus charon: 03[NET] sending packet: from 
205.223.229.254[500] to 91.240.166.5[500] (656 bytes) 
May 11 08:58:49 Enceladus charon: 13[NET] received packet: from 
91.240.166.5[500] to 205.223.229.254[500] (528 bytes) 
May 11 08:58:49 Enceladus charon: 13[ENC] parsed CREATE_CHILD_SA response 306 [ 
SA No KE TSi TSr ] 
May 11 08:58:49 Enceladus charon: 13[IKE] inbound CHILD_SA 
customer-networks{1891} established with SPIs cd9fa1a2_i 803676f9_o and TS 
10.28.157.0/24 === 10.213.56.0/21 
May 11 08:58:49 Enceladus charon: 13[IKE] outbound CHILD_SA 
customer-networks{1891} established with SPIs cd9fa1a2_i 803676f9_o and TS 
10.28.157.0/24 === 10.213.56.0/21 
May 11 08:58:49 Enceladus charon: 13[IKE] closing CHILD_SA 
customer-networks{1890} with SPIs c48dde95_i (511517 bytes) 3c072ec0_o (69571 
bytes) and TS 10.28.157.0/24 === 10.213.56.0/21 
May 11 08:58:49 Enceladus charon: 13[IKE] sending DELETE for ESP CHILD_SA with 
SPI c48dde95 
May 11 08:58:49 Enceladus charon: 13[ENC] generating INFORMATIONAL request 307 
[ D ] 
May 11 08:58:49 Enceladus charon: 13[NET] sending packet: from 
205.223.229.254[500] to 91.240.166.5[500] (96 bytes) 
[every second it will start again...]

However I will try to do another test and I will update
this thread with more detailed information.

[strongSwan] multiple traffic selectors per child_sa

[Marco Berizzi]

Hello everyone,

Kindly I would like to ask, if there is a way to
know if a remote IKEv2 peer supports multiple
traffic selectors per CHILD_SA.

For example strongswan is going to log this kind
of message when tfc is not supported by the other
IKEv2 peer:

received ESP_TFC_PADDING_NOT_SUPPORTED, not using ESPv3 TFC padding

TIA

Re: [strongSwan] multiple id for same ipsec peer

[Marco Berizzi]

Hi Tobias,

> There is currently no exact equivalent for
> the `also` keyword in swanctl.conf

a nice feature to add in a future relase :-)

Re: [strongSwan] starting strongswan without starter

[Marco Berizzi]

Hi Andreas, Hi everyone,

thanks but there is no 'start-stop-daemon' on Slackware.
I will keep building strongswan without the 'disable-stroke'
as suggested by Tobias.

As a suggestion, it would be beautiful to get starter
working also without the presence of the /etc/ipsec.conf :-)

[strongSwan] starting strongswan without starter

[Marco Berizzi]

Hello everyone,

I have compiled strongswan on slackware linux with:

--disable-stroke

and the starter is not builded anymore.

Slackware is one the the few distro which is
not (yet) systemd based.

Which is the correct way to start strongswan
without 'ipsec start' ?

[strongSwan] multiple id for same ipsec peer

[Marco Berizzi]

Hello everyone,

I'm running strongswan 5.6.3dr1 on Slackware linux.
On this strongswan box it is configured an ikev2 tunnel
to a customer checkpoint R77.30 gateway.

Sometimes, for an unknown reason, the checkpoint will
try to initiate the IKE_SA, but instead of using its
public ip address as the id, it is using another ip
address. Here is the relevant log:

12[NET] received packet: from customer_public[500] to my_public[500] (260 
bytes) 
12[ENC] parsed IKE_SA_INIT request 0 [ SA KE No N(NATD_S_IP) N(NATD_D_IP) ] 
12[IKE] customer_public is initiating an IKE_SA 
12[ENC] generating IKE_SA_INIT response 0 [ SA KE No N(NATD_S_IP) N(NATD_D_IP) 
N(MULT_AUTH) ] 
12[NET] sending packet: from my_public[500] to customer_public[500] (280 bytes) 
04[NET] received packet: from customer_public[500] to my_public[500] (336 
bytes) 
04[ENC] parsed IKE_AUTH request 1 [ IDi AUTH N((47997)) SA TSi TSr 
N(INIT_CONTACT) V N(ESP_TFC_PAD_N) N(NON_FIRST_FRAG) ] 
04[CFG] looking for peer configs matching 
my_public[%any]...customer_public[192.168.53.22] 
04[CFG] selected peer config 'customer-10.10.92.0' 
04[IKE] authentication of '192.168.53.22' with pre-shared key successful 
04[IKE] received ESP_TFC_PADDING_NOT_SUPPORTED, not using ESPv3 TFC padding 
04[IKE] authentication of 'my_public' (myself) with pre-shared key 
04[IKE] IKE_SA customer-10.10.92.0[10] established between 
my_public[my_public]...customer_public[192.168.53.22] 

I have bypassed this checkpoint crazy behaviour
adding another conn section to the ipsec.conf file,
and configuring it only as responder (auto=add):

conn customer
left=my_public
right=customer_public
leftsubnet=10.28.155.0/24
leftauth=secret
rightauth=secret
leftid=my_public
rightid=customer_public

conn customer-10.10.92.0
auto=route
also=customer

conn customer-10.10.92.0-192.168.53.22
auto=add
also=customer
rightid=192.168.53.22

Now I would like to move this configuration to the
new swanctl.conf file format.

I would like to ask if this swanctl.conf file is
equivalent to the above ipsec.conf:

connections {

   customer {
  local_addrs  = my_public
  remote_addrs = customer_public

  local {
 auth = psk
 id = my_public
  }
  remote {
 auth = psk
 id = customer_public
 id = 192.168.53.22
  }
  children {
 customer-networks {
local_ts  = 10.28.155.0/24
remote_ts = 10.10.92.0
start_action = trap
esp_proposals = aes256-sha384-ecp521
 }
  }
  proposals = aes256-sha384-ecp521
  send_cert = never
  send_certreq = no
   }
}

secrets {
   ike-customer {
  id = customer_public
  id = 192.168.53.22
  secret = "blablabla"
   }
}

Thanks

Re: [strongSwan] ipsec.conf working vs swanctl.conf not working

[Marco Berizzi]

Hi Tobias,

> > [NET] sending packet: from 205.223.229.254[500] to 31.169.105.210[500] (68 
> > bytes)
> > [NET] received packet: from 31.169.105.210[500] to 205.223.229.254[500] (40 
> > bytes)
> > [ENC] parsed INFORMATIONAL_V1 request 2534754901 [ N(PLD_MAL) ]

> Could indicate a wrong password.  As that seems to be a response to the
> first encrypted message.

yes indeed, fixing the psk did the trick.
Thanks for the prompt feedback.

Re: [strongSwan] ipsec.conf working vs swanctl.conf not working

[Marco Berizzi]

Hi Tobias,

> So you're using IKEv1 now?  (Was IKEv2 in your original mail, and you
> should definitely prefer that if you can.)

yes this is another customer. I should have opened another thread.

> Different IKE proposals.  With ipsec.conf the default proposal(s) are
> added to whatever you configure in ike/esp unless that ends with a !.
> With swanctl.conf the default proposal(s) have to be added explicitly to
> the IKE/ESP proposals (e.g. in your example `proposals =
> 3des-sha1-modp1024, default`) .  So that indicates your configured
> proposal is incorrect.  But that's a completely different problem than
> the one you had before with IKEv2.

thanks for the explanation.
I have found the problematic parameter:

reauth_time

decreasing from 24h to 20h I got this message:

[IKE] initiating Main Mode IKE_SA cbt[874] to 31.169.105.210
[ENC] generating ID_PROT request 0 [ SA V V V V V ]
[NET] sending packet: from 205.223.229.254[500] to 31.169.105.210[500] (248 
bytes)
[NET] received packet: from 31.169.105.210[500] to 205.223.229.254[500] (140 
bytes)
[ENC] parsed ID_PROT response 0 [ SA V V V ]
[ENC] received unknown vendor ID: 4f:45:68:79:4c:64:41:43:65:63:66:61
[IKE] received DPD vendor ID
[IKE] received NAT-T (RFC 3947) vendor ID
[ENC] generating ID_PROT request 0 [ KE No NAT-D NAT-D ]
[NET] sending packet: from 205.223.229.254[500] to 31.169.105.210[500] (244 
bytes)
[NET] received packet: from 31.169.105.210[500] to 205.223.229.254[500] (228 
bytes)
[ENC] parsed ID_PROT response 0 [ KE No NAT-D NAT-D ]
[ENC] generating ID_PROT request 0 [ ID HASH ]
[NET] sending packet: from 205.223.229.254[500] to 31.169.105.210[500] (68 
bytes)
[NET] received packet: from 31.169.105.210[500] to 205.223.229.254[500] (40 
bytes)
[ENC] parsed INFORMATIONAL_V1 request 2534754901 [ N(PLD_MAL) ]
[ENC] ignoring unprotected INFORMATIONAL from 31.169.105.210
[IKE] message verification failed
[IKE] ignore malformed INFORMATIONAL request
[IKE] INFORMATIONAL_V1 request with message ID 2534754901 processing failed
[IKE] sending retransmit 1 of request message ID 0, seq 3
[NET] sending packet: from 205.223.229.254[500] to 31.169.105.210[500] (68 
bytes)
[NET] received packet: from 31.169.105.210[500] to 205.223.229.254[500] (40 
bytes)
[ENC] parsed INFORMATIONAL_V1 request 1470134926 [ N(PLD_MAL) ]
[ENC] ignoring unprotected INFORMATIONAL from 31.169.105.210
[IKE] message verification failed
[IKE] ignore malformed INFORMATIONAL request
[IKE] INFORMATIONAL_V1 request with message ID 1470134926 processing failed

Re: [strongSwan] ipsec.conf working vs swanctl.conf not working

[Marco Berizzi]

Hi Tobias,

> The other end sends that notify back because it couldn't authenticate
> the initiator, so check the log there.

Unfortunately I have no access to the other ipsec peer.
I have also tried with another customer and I'm getting
the same behavior.

Here are the two outputs:

(non working)
[IKE] initiating Main Mode IKE_SA cbt[494] to 31.169.105.210
[ENC] generating ID_PROT request 0 [ SA V V V V V ]
[NET] sending packet: from 205.223.229.254[500] to 31.169.105.210[500] (180 
bytes)

Why only 180 bytes?

[NET] received packet: from 31.169.105.210[500] to 205.223.229.254[500] (40 
bytes)
[ENC] parsed INFORMATIONAL_V1 request 0 [ N(NO_PROP) ]
[IKE] received NO_PROPOSAL_CHOSEN error notify


(working)
initiating Main Mode IKE_SA cbt[499] to 31.169.105.210
generating ID_PROT request 0 [ SA V V V V V ]
sending packet: from 205.223.229.254[500] to 31.169.105.210[500] (248 bytes)

this time strongswan send a 248 bytes ike packet?

received packet: from 31.169.105.210[500] to 205.223.229.254[500] (140 bytes)
parsed ID_PROT response 0 [ SA V V V ]
received unknown vendor ID: 4f:45:68:79:4c:64:41:43:65:63:66:61
received DPD vendor ID
received NAT-T (RFC 3947) vendor ID
generating ID_PROT request 0 [ KE No NAT-D NAT-D ]
sending packet: from 205.223.229.254[500] to 31.169.105.210[500] (244 bytes)
received packet: from 31.169.105.210[500] to 205.223.229.254[500] (228 bytes)
parsed ID_PROT response 0 [ KE No NAT-D NAT-D ]
generating ID_PROT request 0 [ ID HASH ]
sending packet: from 205.223.229.254[500] to 31.169.105.210[500] (68 bytes)
received packet: from 31.169.105.210[500] to 205.223.229.254[500] (76 bytes)
parsed ID_PROT response 0 [ ID HASH V ]
received unknown vendor ID: 49:4b:45:76:32
IKE_SA cbt[499] established between 
205.223.229.254[205.223.229.254]...31.169.105.210[31.169.105.210]
scheduling reauthentication in 85571s
maximum IKE_SA lifetime 86111s
generating QUICK_MODE request 4227161388 [ HASH SA No ID ID ]
sending packet: from 205.223.229.254[500] to 31.169.105.210[500] (204 bytes)
received packet: from 31.169.105.210[500] to 205.223.229.254[500] (156 bytes)
parsed QUICK_MODE response 4227161388 [ HASH SA No ID ID ]
CHILD_SA cbt{788} established with SPIs c2384552_i b807ce0a_o and TS 
10.28.131.200/29 === 192.168.170.128/28
generating QUICK_MODE request 4227161388 [ HASH ]
connection 'cbt' established successfully

These are the two config. I'm not able to catch the
configuration bug:

connections {

   cbt {
  local_addrs  = 205.223.229.254
  remote_addrs = 31.169.105.210

  local {
 auth = psk
 id = 205.223.229.254
  }
  remote {
 auth = psk
 id = 31.169.105.210
  }
  children {
 cbt-networks {
local_ts  = 10.28.131.200/29
remote_ts = 192.168.170.128/28

start_action = trap
esp_proposals = 3des-sha1
rekey_time = 3600
# rekey_bytes = 460800
 }
  }
  version = 1
  # mobike = no
  proposals = 3des-sha1-modp1024
  reauth_time = 24h
  keyingtries = 0
  send_cert = never
  send_certreq = no
  # encap = yes
  # unique = never
   }
}

secrets {

   ike-cbt {
  id = 31.169.105.210
  secret = 0sblabla
   }
}


conn cbt
left=205.223.229.254
right=31.169.105.210
leftsubnet=10.28.131.200/29
rightsubnet=192.168.170.128/28
authby=secret
auto=route
esp=3des-sha1
compress=no
leftid=205.223.229.254
rightid=31.169.105.210
keyingtries=%forever
lifetime=1h
ikelifetime=86400
ike=3des-sha1-modp1024

Re: [strongSwan] ipsec.conf working vs swanctl.conf not working

[Marco Berizzi]

> mobike = no

> By the way I don't understand why strongswan is
> sending packets to 4500/udp.

Ok I found that "mobike = no" change the swap to the 4500/udp

However, I don't understand why the psk authentication is failing.

[strongSwan] ipsec.conf working vs swanctl.conf not working

[Marco Berizzi]

Hello everyone,

I'm running strongswan 5.6.3dr1 on Slackware linux.

I would like to migrate the configuration files from
the old ipsec.conf style to the new swanctl.conf
I'm experimenting a crazy behavior between an old
working configuration and the new non working one.
Here is the old working config:

conn customer
left=205.223.229.254
right=217.118.9.36
leftsubnet=10.68.63.3
leftsendcert=no
rightsendcert=no
leftauth=secret
rightauth=secret
ike=aes256-sha512-ecp521
esp=aes256-sha512-ecp521
compress=no
leftid=205.223.229.254
rightid=217.118.9.36
keyingtries=%forever
lifetime=4h
ikelifetime=24h
keyexchange=ikev2

conn customer-172.16.10.0
rightsubnet=172.16.10.0/24
auto=route
also=customer

and here is the new non working config:

connections {

   customer {
  local_addrs  = 205.223.229.254
  remote_addrs = 217.118.9.36

  local {
 auth = psk
 id = 205.223.229.254
  }
  remote {
 auth = psk
 id = 217.118.9.36
  }
  children {
 customer-networks {
local_ts  = 10.68.63.3/32
remote_ts = 172.16.10.0/24

start_action = route
esp_proposals = aes256-sha512-ecp521
rekey_time = 14400
rekey_bytes = 460800
 }
  }
  version = 2
  mobike = no
  proposals = aes256-sha512-ecp521
  reauth_time = 24h
  keyingtries = 0
  send_cert = never
  send_certreq = no
  encap = yes
   }
}

secrets {

   ike-customer {
  id = 217.118.9.36
  id = 205.223.229.254
  secret = 0sblablabla
   }
}

Here is the output from the ipsec up:

initiating IKE_SA customer-172.16.10.0[47423] to 217.118.9.36
generating IKE_SA_INIT request 0 [ SA KE No N(NATD_S_IP) N(NATD_D_IP) 
N(FRAG_SUP) N(HASH_ALG) N(REDIR_SUP) ]
sending packet: from 205.223.229.254[500] to 217.118.9.36[500] (880 bytes)
received packet: from 217.118.9.36[500] to 205.223.229.254[500] (450 bytes)
parsed IKE_SA_INIT response 0 [ SA KE No V V N(NATD_S_IP) N(NATD_D_IP) 
N(FRAG_SUP) V ]
received Cisco Delete Reason vendor ID
received Cisco Copyright (c) 2009 vendor ID
received FRAGMENTATION vendor ID
authentication of '205.223.229.254' (myself) with pre-shared key
establishing CHILD_SA customer-172.16.10.0{64813}
generating IKE_AUTH request 1 [ IDi N(INIT_CONTACT) IDr AUTH SA TSi TSr 
N(MOBIKE_SUP) N(ADD_4_ADDR) N(ADD_4_ADDR) N(EAP_ONLY) N(MSG_ID_SYN_SUP) ]
sending packet: from 205.223.229.254[4500] to 217.118.9.36[4500] (432 bytes)
received packet: from 217.118.9.36[4500] to 205.223.229.254[4500] (304 bytes)
parsed IKE_AUTH response 1 [ V IDr AUTH SA TSi TSr N(ESP_TFC_PAD_N) 
N(NON_FIRST_FRAG) ]
authentication of '217.118.9.36' with pre-shared key successful
IKE_SA customer-172.16.10.0[47423] established between 
205.223.229.254[205.223.229.254]...217.118.9.36[217.118.9.36]
scheduling reauthentication in 85491s
maximum IKE_SA lifetime 86031s
received ESP_TFC_PADDING_NOT_SUPPORTED, not using ESPv3 TFC padding
CHILD_SA customer-172.16.10.0{64813} established with SPIs c1fbb908_i 
33cdcd59_o and TS 10.68.68.3/32 === 172.16.10.0/24
connection 'customer-172.16.10.0' established successfully


By the way I don't understand why strongswan is
sending packets to 4500/udp.

and here is the output from swanctl:

[IKE] initiating IKE_SA customer[47454] to 217.118.9.36
[ENC] generating IKE_SA_INIT request 0 [ SA KE No N(NATD_S_IP) N(NATD_D_IP) 
N(FRAG_SUP) N(HASH_ALG) N(REDIR_SUP) ]
[NET] sending packet: from 205.223.229.254[500] to 217.118.9.36[500] (340 bytes)
[NET] received packet: from 217.118.9.36[500] to 205.223.229.254[500] (450 
bytes)
[ENC] parsed IKE_SA_INIT response 0 [ SA KE No V V N(NATD_S_IP) N(NATD_D_IP) 
N(FRAG_SUP) V ]
[IKE] received Cisco Delete Reason vendor ID
[IKE] received Cisco Copyright (c) 2009 vendor ID
[IKE] received FRAGMENTATION vendor ID
[CFG] no IDi configured, fall back on IP address
[IKE] authentication of '205.223.229.254' (myself) with pre-shared key
[IKE] establishing CHILD_SA customer-networks{64861}
[ENC] generating IKE_AUTH request 1 [ IDi AUTH SA TSi TSr N(EAP_ONLY) 
N(MSG_ID_SYN_SUP) ]
[NET] sending packet: from 205.223.229.254[500] to 217.118.9.36[500] (288 bytes)
[NET] received packet: from 217.118.9.36[500] to 205.223.229.254[500] (96 bytes)
[ENC] parsed IKE_AUTH response 1 [ N(AUTH_FAILED) ]
[IKE] received AUTHENTICATION_FAILED notify error
initiate failed: establishing CHILD_SA 'customer-networks' failed

This time strongswan doesn't send packets to 4500/udp

What am I missing on the swanctl configuration?

TIA

Here is the more detailed output from swanctl:

[MGR] checkout IKE_SA by config
[JOB] watcher got notification, rebuilding
[JOB]   watching 9 for reading
[JOB]   watching 13 for reading
[JOB]   watching 14 for reading
[JOB]   watching 15 for reading
[IKE] queueing IKE_VENDOR task
[IKE] queueing 

Re: [strongSwan] infinite loop for ipsec up/down command

[Marco Berizzi]

Marco Berizzi wrote:
 
Tobias Brunner wrote:
 
> Hi Marco,
>
> > I'm running strongswan 5.6.2 on Slackware linux 64 bit
>
> Check the current master.  It includes fixes for issues like these (see
> [1]).

Just for record: when I issue for the 2nd time the ipsec up command
strongswan will not loop anymore:

establishing CHILD_SA customer-10.14.143.0{3323}
generating CREATE_CHILD_SA request 2 [ SA No KE TSi TSr ]
sending packet: from 205.223.229.254[4500] to 193.104.231.4[4500] (320 bytes)
received packet: from 193.104.231.4[4500] to 205.223.229.254[4500] (80 bytes)
parsed CREATE_CHILD_SA response 2 [ N(INVAL_KE) ]
peer didn't accept DH group ECP_384, it requested ECP_384
establishing CHILD_SA customer-10.14.143.0{3324}
generating CREATE_CHILD_SA request 3 [ SA No KE TSi TSr ]
sending packet: from 205.223.229.254[4500] to 193.104.231.4[4500] (320 bytes)
received packet: from 193.104.231.4[4500] to 205.223.229.254[4500] (80 bytes)
parsed CREATE_CHILD_SA response 3 [ N(INVAL_KE) ]
already retried with DH group ECP_384, ignorerequested ECP_384
failed to establish CHILD_SA, keeping IKE_SA
^C

but I must press ^C to get again the bash prompt.

Re: [strongSwan] infinite loop for ipsec up/down command

[Marco Berizzi]

Tobias Brunner wrote:
 
> Hi Marco,
> 
> > I'm running strongswan 5.6.2 on Slackware linux 64 bit
> 
> Check the current master.  It includes fixes for issues like these (see
> [1]).

Hi Tobias,

thanks a lot for the quick response. 
git cloned master, compiled and installed: problem is fixed.

Thanks again for the support.

Marco

[strongSwan] infinite loop for ipsec up/down command

[Marco Berizzi]

Hello everyone,

I'm running strongswan 5.6.2 on Slackware linux 64 bit

I'm experimenting a pretty strange behavior with an
ipsec tunnel.

When I issue for the first time the 'ipsec up' command
I get:

ipsec up customer-10.14.143.0

initiating IKE_SA customer-10.14.143.0[21570] to 193.104.231.4
generating IKE_SA_INIT request 0 [ SA KE No N(NATD_S_IP) N(NATD_D_IP) 
N(FRAG_SUP) N(HASH_ALG) N(REDIR_SUP) ]
sending packet: from 205.223.229.254[500] to 193.104.231.4[500] (844 bytes)
received packet: from 193.104.231.4[500] to 205.223.229.254[500] (268 bytes)
parsed IKE_SA_INIT response 0 [ SA KE No N(NATD_S_IP) N(NATD_D_IP) 
N(CHDLESS_SUP) ]
remote host is behind NAT
authentication of '205.223.229.254' (myself) with pre-shared key
establishing CHILD_SA customer-10.14.143.0{13527}
generating IKE_AUTH request 1 [ IDi N(INIT_CONTACT) IDr AUTH SA TSi TSr 
N(MOBIKE_SUP) N(ADD_4_ADDR) N(ADD_4_ADDR) N(EAP_ONLY) N(MSG_ID_SYN_SUP) ]
sending packet: from 205.223.229.254[4500] to 193.104.231.4[4500] (384 bytes)
received packet: from 193.104.231.4[4500] to 205.223.229.254[4500] (272 bytes)
parsed IKE_AUTH response 1 [ IDr AUTH N(CRASH_DET) SA TSi TSr N(ESP_TFC_PAD_N) 
N(NON_FIRST_FRAG) ]
authentication of '193.104.231.4' with pre-shared key successful
IKE_SA customer-10.14.143.0[21570] established between 
205.223.229.254[205.223.229.254]...193.104.231.4[193.104.231.4]
scheduling reauthentication in 13519s
maximum IKE_SA lifetime 14059s
received ESP_TFC_PADDING_NOT_SUPPORTED, not using ESPv3 TFC padding
CHILD_SA customer-10.14.143.0{13527} established with SPIs cce55dc7_i 
f0a09095_o and TS 10.68.63.3/32 === 10.14.143.0/24
connection 'customer-10.14.143.0' established successfully

if I try to run again the same 'ipsec up', strongswan
will enter in an infinite loop:

ipsec up customer-10.14.143.0

establishing CHILD_SA customer-10.14.143.0{13530}
generating CREATE_CHILD_SA request 2 [ SA No KE TSi TSr ]
sending packet: from 205.223.229.254[4500] to 193.104.231.4[4500] (416 bytes)
received packet: from 193.104.231.4[4500] to 205.223.229.254[4500] (80 bytes)
parsed CREATE_CHILD_SA response 2 [ N(INVAL_KE) ]
peer didn't accept DH group ECP_384, it requested ECP_384
establishing CHILD_SA customer-10.14.143.0{13531}
generating CREATE_CHILD_SA request 3 [ SA No KE TSi TSr ]
sending packet: from 205.223.229.254[4500] to 193.104.231.4[4500] (416 bytes)
received packet: from 193.104.231.4[4500] to 205.223.229.254[4500] (80 bytes)
parsed CREATE_CHILD_SA response 3 [ N(INVAL_KE) ]
peer didn't accept DH group ECP_384, it requested ECP_384
establishing CHILD_SA customer-10.14.143.0{13532}
generating CREATE_CHILD_SA request 4 [ SA No KE TSi TSr ]
sending packet: from 205.223.229.254[4500] to 193.104.231.4[4500] (416 bytes)
received packet: from 193.104.231.4[4500] to 205.223.229.254[4500] (80 bytes)
parsed CREATE_CHILD_SA response 4 [ N(INVAL_KE) ]
peer didn't accept DH group ECP_384, it requested ECP_384
establishing CHILD_SA customer-10.14.143.0{13533}
generating CREATE_CHILD_SA request 5 [ SA No KE TSi TSr ]
sending packet: from 205.223.229.254[4500] to 193.104.231.4[4500] (416 bytes)
received packet: from 193.104.231.4[4500] to 205.223.229.254[4500] (80 bytes)
parsed CREATE_CHILD_SA response 5 [ N(INVAL_KE) ]
peer didn't accept DH group ECP_384, it requested ECP_384
establishing CHILD_SA customer-10.14.143.0{13534}
generating CREATE_CHILD_SA request 6 [ SA No KE TSi TSr ]
sending packet: from 205.223.229.254[4500] to 193.104.231.4[4500] (416 bytes)
received packet: from 193.104.231.4[4500] to 205.223.229.254[4500] (80 bytes)
parsed CREATE_CHILD_SA response 6 [ N(INVAL_KE) ]
peer didn't accept DH group ECP_384, it requested ECP_384
establishing CHILD_SA customer-10.14.143.0{13535}
[...]

till I press ctrl+C

If I try to issue the 'ipsec down' command I get the
same infinite output:

ipsec down customer-10.14.143.0

received packet: from 193.104.231.4[4500] to 205.223.229.254[4500] (80 bytes)
parsed CREATE_CHILD_SA response 353 [ N(INVAL_KE) ]
peer didn't accept DH group ECP_384, it requested ECP_384
establishing CHILD_SA customer-10.14.143.0{13882}
generating CREATE_CHILD_SA request 354 [ SA No KE TSi TSr ]
sending packet: from 205.223.229.254[4500] to 193.104.231.4[4500] (416 bytes)
received packet: from 193.104.231.4[4500] to 205.223.229.254[4500] (80 bytes)
parsed CREATE_CHILD_SA response 354 [ N(INVAL_KE) ]
peer didn't accept DH group ECP_384, it requested ECP_384
establishing CHILD_SA customer-10.14.143.0{13883}
generating CREATE_CHILD_SA request 355 [ SA No KE TSi TSr ]
sending packet: from 205.223.229.254[4500] to 193.104.231.4[4500] (416 bytes)
received packet: from 193.104.231.4[4500] to 205.223.229.254[4500] (80 bytes)
parsed CREATE_CHILD_SA response 355 [ N(INVAL_KE) ]
peer didn't accept DH group ECP_384, it requested ECP_384
establishing CHILD_SA customer-10.14.143.0{13884}
generating CREATE_CHILD_SA request 356 [ SA No KE TSi TSr ]
sending packet: from 205.223.229.254[4500] to 193.104.231.4[4500] (416 bytes)
received 

[strongSwan] ipsec tunnel throughput measurement

[Marco Berizzi]

Hello everyone,

I have completed some speed test between two slackware linux
4.14 system running strongswan. The purpose is to estimate
the network throughput inside an ipsec tunnel. Strongswan will
not affect results, but I hope this message will be still
informative for users subscribed to this list.

Here is the network schema:

++ ++  ++
| linux  | | linux  |  | linux  |
| iperf  +-+ ipsec  +---ipsec tunnel---+ ipsec  +---dummy0 interface
| client | | gateway|  | gateway|   linux iperf server
++ ++  ++

MTU=1500bytes for all systems
The two ipsec gateway are running on Intel i5-3470@3.20GHz
AES-NI extension are enabled on this processor and the
kernel is built with them enabled as externals modules.
NIC models on the ipsec gateways are Intel Corporation I350
and Intel Corporation 82579LM

The following esp configuration where tested:

aes256-sha384-modp4096
camellia256-sha384-modp4096
camellia128-sha384-modp4096
chacha20poly1305-ntru256
3des-sha384

with the following tcp mss: 200 bytes, 500 bytes, 1000 bytes
and the maximum permitted by the ipsec tunnel.

And here are the results. Summary: chacha20 is the winner
followed by aes256 and camellia128.

maximum MSS:

throughput without any tunnel ipsec (only routing):
0.00-10.00  sec  1.09 GBytes   933 Mbits/secsender
0.00-10.04  sec  1.09 GBytes   929 Mbits/secreceiver

chacha20poly1305
0.00-10.00  sec  1.06 GBytes   908 Mbits/secsender
0.00-10.05  sec  1.05 GBytes   901 Mbits/secreceiver

aes256-sha384
0.00-10.00  sec  1.04 GBytes   896 Mbits/secsender
0.00-10.05  sec  1.04 GBytes   889 Mbits/secreceiver

camellia128-sha384
0.00-10.00  sec   949 MBytes   796 Mbits/secsender
0.00-10.04  sec   947 MBytes   791 Mbits/secreceiver

camellia256-sha384
0.00-10.00  sec   805 MBytes   676 Mbits/secsender
0.00-10.05  sec   804 MBytes   671 Mbits/secreceiver

3des-sha384
0.00-10.00  sec   280 MBytes   235 Mbits/secsender
0.00-10.05  sec   279 MBytes   233 Mbits/secreceiver


1000 bytes MSS:

throughput without any tunnel ipsec (only routing):
0.00-10.00  sec  1.06 GBytes   912 Mbits/secsender
0.00-10.04  sec  1.06 GBytes   907 Mbits/secreceiver

chacha20poly1305
0.00-10.00  sec  1.02 GBytes   874 Mbits/secsender
0.00-10.05  sec  1.01 GBytes   867 Mbits/secreceiver

aes256-sha384
0.00-10.00  sec  1016 MBytes   852 Mbits/secsender
0.00-10.05  sec  1013 MBytes   846 Mbits/secreceiver

camellia128-sha384
0.00-10.00  sec   861 MBytes   723 Mbits/secsender
0.00-10.04  sec   859 MBytes   718 Mbits/secreceiver

camellia256-sha384
0.00-10.00  sec   735 MBytes   617 Mbits/secsender
0.00-10.04  sec   733 MBytes   612 Mbits/secreceiver

3des-sha384
0.00-10.00  sec   264 MBytes   221 Mbits/secsender
0.00-10.05  sec   262 MBytes   219 Mbits/secreceiver


500 bytes MSS:

throughput without any tunnel ipsec (only routing):
0.00-10.00  sec   992 MBytes   832 Mbits/secsender
0.00-10.04  sec   990 MBytes   827 Mbits/secreceiver

chacha20poly1305
0.00-10.00  sec   920 MBytes   772 Mbits/secsender
0.00-10.05  sec   918 MBytes   766 Mbits/secreceiver

aes256-sha384
0.00-10.00  sec   879 MBytes   738 Mbits/secsender
0.00-10.04  sec   877 MBytes   732 Mbits/secreceiver

camellia128-sha384
0.00-10.00  sec   684 MBytes   574 Mbits/secsender
0.00-10.04  sec   681 MBytes   569 Mbits/secreceiver

camellia256-sha384
0.00-10.00  sec   593 MBytes   498 Mbits/secsender
0.00-10.04  sec   591 MBytes   493 Mbits/secreceiver

3des-sha384
0.00-10.00  sec   231 MBytes   194 Mbits/secsender
0.00-10.05  sec   229 MBytes   191 Mbits/secreceiver


200 bytes MSS:

throughput without any tunnel ipsec (only routing):
0.00-10.00  sec   795 MBytes   667 Mbits/secsender
0.00-10.04  sec   792 MBytes   662 Mbits/secreceiver

chacha20poly1305
0.00-10.00  sec   549 MBytes   460 Mbits/secsender
0.00-10.04  sec   546 MBytes   456 Mbits/secreceiver

aes256-sha384
0.00-10.00  sec   499 MBytes   418 Mbits/secsender
0.00-10.04  sec   496 MBytes   414 Mbits/secreceiver

camellia128-sha384
0.00-10.00  sec   403 MBytes   338 Mbits/secsender
0.00-10.04  sec   399 MBytes   333 Mbits/secreceiver

camellia256-sha384
0.00-10.00  sec   362 MBytes   303 Mbits/secsender
0.00-10.04  sec   359 MBytes   300 Mbits/secreceiver

3des-sha384
0.00-10.00  sec   177 MBytes   148 Mbits/secsender
0.00-10.04  sec   173 MBytes   145 Mbits/secreceiver

Re: [strongSwan] multiple remote_ts with ikev1 file format

[Marco Berizzi]

Rich Lafferty  wrote:

> > Is there a way to not write in every section the parameters
> > common to all the children sections (rekey_time, esp_proposals…)?

> I wasn’t able to find a way to set defaults, but I’ve put my common 
> parameters in /etc/swanctl/swanctl-ipsec.conf and then > done
>  "include swanctl-ipsec.conf” in each child config. If someone else knows a 
> better way, though, I’m all ears!

Thanks a lot Rich for the tips.

[strongSwan] multiple remote_ts with ikev1 file format

[Marco Berizzi]

Hello everyone,

I would like to finally drop the ipsec.conf and ipsec.secrets
configuration files from my strongswan ipsec gateway.
I have a couple of questions to ask.

I'm running strongswan 5.6.2 on Slackware linux (still systemd
free).

On my test bed, ipsec.conf and ipsec.secrets are those shipped
with strongswan: they are both empty.

I'm starting strongswan with the old 'ipsec start', and after I
issue the command: 'swanctl -q' for loading the configuration
files under /etc/swanctl/conf.d/*

Am I right? Or is there a smarter way to start strongswan without
the old 'ipsec' script?

The second question is about the file format when multiple remote_ts
need to be defined when ikev1 must be used.
Here is my example:

children {
  net-0ab1 {
  local_ts  = 10.139.10.0/23
  remote_ts = 10.177.0.0/16
  rekey_time = 8h
  start_action = trap
  esp_proposals = aes128-sha1-modp1024,aes256-sha1-modp1024
  }
net-0ab4 {
  local_ts  = 10.139.10.0/23
  remote_ts = 10.180.0.0/16
  rekey_time = 8h
  start_action = trap
  esp_proposals = aes128-sha1-modp1024,aes256-sha1-modp1024
  }
}

Is there a way to not write in every section the parameters
common to all the children sections (rekey_time, esp_proposals...)?

Thanks in advance

[strongSwan] child_sa not dropped the ike_sa are deleted

[Marco Berizzi]

Hello everyone,

I'm running strongswan 5.6.1 on slackware linux 64 bit
I have found a problem with my setup. The down_client:)
in the updown script is not executed when the IKE_SA is
dropped. Here is my config setup:

conn rw-generali
right=%any
compress=yes
leftupdown=/etc/ipsec.d/updown/_updown.strongswan.X11
keylife=10h
ikelifetime=12h
rekey=yes
keyingtries=1
ike=aes128-sha1-modp1024,aes128-sha1-modp2048,aes256-sha384-ecp384
esp=aes128-sha1-modp1024,aes128-sha1-modp2048,aes256-sha256-ecp384
rightsubnet=10.0.0.0/8,172.16.0.0/12,192.168.0.0/16,100.64.0.0/10

conn rw-generali-10.180.0.0_internal
also=rw-generali
auto=add
leftsubnet=10.180.0.0/16
left=10.81.110.254

conn rw-generali-10.177.0.0_internal
also=rw-generali
auto=add
leftsubnet=10.177.0.0/16
left=10.81.110.254

Here is the relevant log when the IKE_SA is dropped:

Jan 26 21:38:14 Pleiadi charon: 08[IKE] initiator did not reauthenticate as 
requested 
Jan 26 21:38:14 Pleiadi charon: 08[IKE] reauthenticating IKE_SA 
rw-generali-10.180.0.0_internal[17] actively 
Jan 26 21:38:14 Pleiadi charon: 08[IKE] initiating Main Mode IKE_SA 
rw-generali-10.180.0.0_internal[94] to 10.81.126.175 
Jan 26 21:38:14 Pleiadi charon: 08[ENC] generating ID_PROT request 0 [ SA V V V 
V V ] 
Jan 26 21:38:14 Pleiadi charon: 08[NET] sending packet: from 10.81.110.254[500] 
to 10.81.126.175[500] (312 bytes) 
Jan 26 21:38:18 Pleiadi charon: 15[IKE] sending retransmit 1 of request message 
ID 0, seq 1 
Jan 26 21:38:18 Pleiadi charon: 15[NET] sending packet: from 10.81.110.254[500] 
to 10.81.126.175[500] (312 bytes) 
Jan 26 21:38:25 Pleiadi charon: 12[IKE] sending retransmit 2 of request message 
ID 0, seq 1 
Jan 26 21:38:25 Pleiadi charon: 12[NET] sending packet: from 10.81.110.254[500] 
to 10.81.126.175[500] (312 bytes) 
Jan 26 21:38:38 Pleiadi charon: 13[IKE] sending retransmit 3 of request message 
ID 0, seq 1 
Jan 26 21:38:38 Pleiadi charon: 13[NET] sending packet: from 10.81.110.254[500] 
to 10.81.126.175[500] (312 bytes) 
[...]
Jan 26 21:47:14 Pleiadi charon: 13[IKE] deleting IKE_SA 
rw-generali-10.180.0.0_internal[17] between 
10.81.110.254[CN=strongSWAN]...10.81.126.175[CN=Maddalena] 
Jan 26 21:47:14 Pleiadi charon: 13[IKE] sending DELETE for IKE_SA 
rw-generali-10.180.0.0_internal[17] 
Jan 26 21:47:14 Pleiadi charon: 13[ENC] generating INFORMATIONAL_V1 request 
1418042332 [ HASH D ] 
Jan 26 21:47:14 Pleiadi charon: 13[NET] sending packet: from 10.81.110.254[500] 
to 10.81.126.175[500] (92 bytes) 

As you may see the mobile user CHILD_SA are not dropped
because strongswan is not logging the '-' at Jan 26 21:47:14
Only the IKE_SA is dropped.

Jan 26 17:57:45 Pleiadi vpn: + CN=Maddalena 10.81.126.175 -- 10.81.110.254 == 
10.180.0.0/16
Jan 26 17:58:08 Pleiadi vpn: + CN=Maddalena 10.81.126.175 -- 10.81.110.254 == 
10.177.0.0/16
Jan 29 08:59:30 Pleiadi vpn: + CN=Maddalena 10.81.126.175 -- 10.81.110.254 == 
10.180.0.0/16
Jan 29 09:09:34 Pleiadi vpn: + CN=Maddalena 10.81.126.175 -- 10.81.110.254 == 
10.177.0.0/16
Jan 29 09:15:20 Pleiadi vpn: - CN=Maddalena 10.81.126.175 -- 10.81.110.254 == 
10.177.0.0/16
Jan 29 09:18:21 Pleiadi vpn: + CN=Maddalena 10.81.126.175 -- 10.81.110.254 == 
10.177.0.0/16
Jan 29 09:23:55 Pleiadi vpn: - CN=Maddalena 10.81.126.175 -- 10.81.110.254 == 
10.177.0.0/16
Jan 29 09:58:09 Pleiadi vpn: + CN=Maddalena 10.81.126.175 -- 10.81.110.254 == 
10.177.0.0/16

Is the the expected behaviour?

Re: [strongSwan] checkpoint interoperability problem

[Marco Berizzi]

Hello everyone.

Just for record: in agreement with the customer switching to IKEv2 and enabling 
forceencaps=yes have resolved the  interoperability problem.

The forceencaps=yes has been setup because the checkpoint was replying with udp 
datagrams instead of ESP packets for an unknown reason.

Checkpoint customer is running R77.30

Re: [strongSwan] roadwarrior ike/esp SA are not dropped after lifetime expiration

[Marco Berizzi]

> Yes indeed dpd should do the trick. 

unfortunately windows 7 and windows 10 doesn't support dpd. Charon is logging 
these messages:

DPD not supported by peer, disabled 

So dpd was not an option.

inactivity= is going to kill only the child sa. As pointed by Noel setting 
charon.inactivity_close_ike is going to kill also the ike sa. But I didn't want 
to change a system wide settings.

So I have opted for setting:

rekey=yes
keyingtries=1

Re: [strongSwan] roadwarrior ike/esp SA are not dropped after lifetime expiration

[Marco Berizzi]

Giuseppe De Marco 

[strongSwan] roadwarrior ike/esp SA are not dropped after lifetime expiration

[Marco Berizzi]

Hello everyone,

I'm running strongswan 5.6.1 on slackware linux 64 bit
I have found a little problem with my setup. Sometimes
mobile users main mode and quick mode are not dropped
after ike/esp lifetime. Here is my config setup:

conn rw-mobile
right=%any
compress=yes
leftcert=osw-cert.pem
leftupdown=/etc/ipsec.d/updown/_updown.strongswan.X11
keylife=80m
ikelifetime=8h
rekey=no
keyingtries=1
leftid=fsw...@aive.it
ike=aes128-sha1-modp1024,aes128-sha1-modp2048,aes256-sha384-ecp384
esp=aes128-sha1-modp1024,aes128-sha1-modp2048,aes256-sha256-ecp384

conn mobile
also=rw-mobile
auto=add
leftsubnet=10.180.0.0/16
rightsubnet=10.0.0.0/8,172.16.0.0/12,192.168.0.0/16,100.64.0.0/10
left=82.184.99.254

And here is an example of ipsec statusall output:

mobile[393]: ESTABLISHED 3 days ago, 
82.184.99.254[CN=Gateway]...195.46.216.198[CN=Jessica]
mobile[393]: IKEv1 SPIs: 15ae977b997e4475_i 3e72597006e642fe_r*, rekeying 
disabled
mobile[393]: IKE proposal: 
AES_CBC_256/HMAC_SHA2_384_192/PRF_HMAC_SHA2_384/ECP_384
mobile{298}:  INSTALLED, TUNNEL, reqid 260, ESP in UDP SPIs: c5a4f249_i 
a21eed36_o
mobile{298}:  AES_CBC_256/HMAC_SHA2_256_128/ECP_384, 20978 bytes_i (365 pkts, 
268111s ago), 417068 bytes_o (373 pkts, 268111s ago), rekeying disabled
mobile{298}:   10.180.0.0/16 === 10.247.200.180/32

As you can see this IKE/ESP SA is not dropped after more
than 74 hours.
The mobile user is defunct but strongswan will not remove
that IKE/ESP SA till when the user will reconnect.

Is this the expected behaviour?

[strongSwan] checkpoint interoperability problem

[Marco Berizzi]

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