[strongSwan] Planning an upgrade of strongswan from 4.4.1 to 5.2.1

Thomas Egerer hakke_007 at gmx.de
Sat Jan 9 23:17:54 CET 2016 

On 01/09/2016 02:52 PM, CJ Fearnley wrote:
> I cleared the 3DEC_CBC hurdle by installing libstrongswan-standard-plugins
> 
> Now three clients have connected. Whoo hoo!
> 
> However, I'm getting this behavior with one of the other clients:
> 
> Jan  9 08:45:57 cw1 ipsec[19931]: 05[NET] received packet: from 67.151.41.186[500] to 216.130.102.66 [500] (292 bytes)
> Jan  9 08:45:57 cw1 ipsec[19931]: 05[IKE] received retransmit of request with ID 3004727439, but no response to retransmit
> 
> What does that mean?
It means 67.151.41.186 can reach 216.130.102.66 but apparently not the
other way around. Does not look like a NATted connection to me, unless
your NAT router does not (need to) changed the port (500).
Unfortunately you stripped the information of what the retransmitted
packet originally contained, also having a look on the log of the peer
(67.151.41.186) probably wouldn't hurt.

Cheers,
Thomas
> 
> On Sat, Jan 09, 2016 at 08:58:42PM +0800, Rayson Zhu wrote:
>> Both peers should use identical cipher algorithms.
>> The former message you got shows that your local peer uses
>> aes128-sha256-modp2048 but the remote peer is configured to use
>> 3des-sha1-modp1024.
>> The latter one shows your local peer doesn't support for 3des, maybe caused
>> by lack of some libraries. By the way, 3des is an outdated encryption
>> algorithm.
>>
>>
>>
>> On Sat, Jan 9, 2016 at 8:32 PM, CJ Fearnley <cjf at linuxforce.net> wrote:
>>
>>> I added those two lines to the conn %default section. Then I ran "ipsec
>>> restart". There failure messages have changed slightly:
>>>
>>> Jan  9 07:23:18 cw1 ipsec[19452]: 12[IKE] 67.151.55.146 is initiating a
>>> Main Mode IKE_SA
>>> Jan  9 07:23:18 cw1 ipsec[19452]: 12[CFG] received proposals:
>>> IKE:3DES_CBC/HMAC_SHA1_96/PRF_HMAC_SHA
>>> 1/MODP_1024
>>> Jan  9 07:23:18 cw1 ipsec[19452]: 12[CFG] configured proposals:
>>> IKE:AES_CBC_128/HMAC_SHA2_256_128/PR
>>> F_HMAC_SHA2_256/MODP_2048
>>> Jan  9 07:23:18 cw1 ipsec[19452]: 12[IKE] no proposal found
>>> Jan  9 07:23:18 cw1 ipsec[19452]: 12[ENC] generating INFORMATIONAL_V1
>>> request 1836105202 [ N(NO_PROP
>>> ) ]
>>>
>>> So I tried
>>>     ike = 3des-sha1-modp1024!
>>>     esp = 3des-sha1-modp1024!
>>>
>>> But now I run into this:
>>>
>>> Jan  9 07:29:28 cw1 ipsec[19697]: 13[IKE] 67.151.55.146 is initiating a
>>> Main Mode IKE_SA
>>> Jan  9 07:29:29 cw1 charon: 15[NET] received packet: from
>>> 67.151.55.146[500] to 216.130.102.66[500] (200 bytes)
>>> Jan  9 07:29:29 cw1 charon: 15[ENC] parsed ID_PROT request 0 [ KE No V ]
>>> Jan  9 07:29:29 cw1 charon: 15[ENC] received unknown vendor ID:
>>> 70:03:cb:c1:09:7d:be:9c:26:00:ba:69:83:bc:8b:35
>>> Jan  9 07:29:29 cw1 charon: 15[IKE] sending cert request for "C=US,
>>> [redacted ...]"
>>> Jan  9 07:29:29 cw1 charon: 15[IKE] ENCRYPTION_ALGORITHM 3DES_CBC (key
>>> size 0) not supported!
>>> Jan  9 07:29:29 cw1 charon: 15[IKE] key derivation for RSA signature failed
>>> Jan  9 07:29:29 cw1 charon: 15[ENC] generating INFORMATIONAL_V1 request
>>> 1044526370 [ HASH N(INVAL_KE) ]
>>>
>>> And I'm stuck again.
>>>
>>> On Sat, Jan 09, 2016 at 02:15:51PM +0800, Rayson Zhu wrote:
>>>> Hi, try specifying IKE & ESP cipher suits explicitly for all peers. For
>>>> example
>>>> ike = aes128-sha256-modp2048!
>>>> esp = aes128-sha256-modp2048!
>>>>
>>>> On Sat, Jan 9, 2016 at 2:04 PM, CJ Fearnley <cjf at linuxforce.net> wrote:
>>>>
>>>>> Well, my upgrade from strongswan 4.4.1-5.7 to 5.2.1-6+deb8u1 (Debian
>>>>> Squeeze to Jessie on new hardware) is not going well. No connections
>>>>> have re-established.
>>>>>
>>>>> I'm using the same ipsec.conf that worked on 4.4.1-5.7. See the
>>> referenced
>>>>> e-mail from Dec 9th when I asked about the upgrade process.
>>>>>
>>>>> Each client is generating this pattern in the logs over and over:
>>>>>
>>>>> Jan  9 01:01:07 cw1 charon: 06[IKE] 67.151.55.146 is initiating a Main
>>>>> Mode IKE_SA
>>>>> Jan  9 01:01:07 cw1 charon: 06[CFG] received proposals:
>>>>> IKE:3DES_CBC/HMAC_SHA1_96/PRF_HMAC_SHA1/MODP_1024
>>>>> Jan  9 01:01:07 cw1 charon: 06[CFG] configured proposals:
>>>>> IKE:AES_CBC_128/HMAC_SHA1_96/PRF_HMAC_SHA1/MODP_2048,
>>>>> IKE:3DES_CBC/HMAC_SHA1_96/PRF_HMAC_SHA1/MODP_1536,
>>>>>
>>> IKE:AES_CBC_128/AES_CBC_192/AES_CBC_256/HMAC_SHA1_96/HMAC_MD5_96/HMAC_SHA2_256_128/HMAC_SHA2_384_192/HMAC_SHA2_512_256/AES_XCBC_96/PRF_HMAC_SHA1/PRF_HMAC_MD5/PRF_HMAC_SHA2_256/PRF_HMAC_SHA2_384/PRF_HMAC_SHA2_512/PRF_AES128_XCBC/MODP_2048/MODP_2048_224/MODP_2048_256/MODP_1536/MODP_3072/MODP_4096/MODP_8192/MODP_1024/MODP_1024_160
>>>>> Jan  9 01:01:07 cw1 charon: 06[IKE] no proposal found
>>>>> Jan  9 01:01:07 cw1 charon: 06[ENC] generating INFORMATIONAL_V1 request
>>>>> 3117715548 [ N(NO_PROP) ]
>>>>>
>>>>> I have double checked that I copied from backups the contents of
>>>>> /etc/ipsec.d/cacerts
>>>>> /etc/ipsec.d/certs
>>>>> /etc/ipsec.d/private
>>>>>
>>>>> Do I need to add some encryption plugins? Or can I simply specify using
>>>>> the ike= configuration option for the actual algorithm used by the
>>>>> Netgears FVG318?
>>>>>
>>>>> I tried adding the sha1 hmac xcbc and x509 modules to the load = line
>>>>> in /etc/strongswan.d/charon.conf. No go.
>>>>>
>>>>> The output of
>>>>> $ sudo ipsec version
>>>>> Linux strongSwan U5.2.1/K3.16.0-4-amd64
>>>>> Institute for Internet Technologies and Applications
>>>>> University of Applied Sciences Rapperswil, Switzerland
>>>>> See 'ipsec --copyright' for copyright information.
>>>>>
>>>>> On Wed, Dec 09, 2015 at 08:12:42PM -0500, CJ Fearnley wrote:
>>>>>> I have a working strongswan system running the Debian package at
>>> version
>>>>>> 4.4.1-5.7 (Squeeze oldoldstable). In a week or so, I'll be replacing
>>>>>> the box with a fresh install of Debian running 5.2.1-6+deb8u1
>>> (Jessie).
>>>>>>
>>>>>> I have two questions:
>>>>>>
>>>>>> 1. Have any config options changed in strongswan that I need to
>>> study?
>>>>>>
>>>>>> 2. Are there any issues with strongswan in connecting with a Netgear
>>>>>>    FVG318 of various vintages. All of our clients connect with this
>>>>>>    model of Netgear which is the only thing we've been able to get
>>>>>>    working with certificates.
>>>>>>
>>>>>> Here is a cleaned up version of /etc/ipsec.conf:
>>>>>>
>>>>>> config setup
>>>>>>     charonstart=yes
>>>>>>     plutostart=yes
>>>>>>     virtual_private=%v4:
>>>>> 10.0.0.0/8,%v4:192.168.0.0/16,%v4:172.16.0.0/12,%v4:!192.168.101.0/24
>>>>>>     uniqueids=no
>>>>>>
>>>>>> conn %default
>>>>>>     mobike=no
>>>>>>     keyexchange=ikev1
>>>>>>     left=xxx.xxx.xxx.xx
>>>>>>     leftsubnet=192.168.xxx.0/24
>>>>>>     auto=add
>>>>>>
>>>>>> conn someplace
>>>>>>     rightsubnet=192.168.yyy.0/24
>>>>>>     right=%any
>>>>>>     leftid="C=US, ST=ST, L=Some City, O=Some Company, CN=
>>>>> something.example.com, E=some at example.com"
>>>>>>     leftcert=something.crt
>>>>>>     leftsendcert=always
>>>>>>
>>>>>> plus a half-dozen others of similar nature.
>>>>>>
>>>>>> All of the systems that connect to this are various vintages of the
>>>>>> Netgear FVG318.
>>>>>>
>>>>>> Are there any known compatibility issues with strongswan 5.2.1 and
>>> the
>>>>>> Netgear FVG318?
>>>>>>
>>>>>> Have there been any relevant changes to the syntax of ipsec.conf
>>> since
>>>>>> 4.4.1 and 5.2.1-6+deb8u1?
>>>>>>
>>>>>> Any general strongswan relevant advice for planning such an upgrade?
>>>>>
>>>>> --
>>>>> CJ Fearnley                 |   LinuxForce Inc.
>>>>> cjf at LinuxForce.net          |   IT Projects & Systems Maintenance
>>>>> http://www.LinuxForce.net   |   http://blog.remoteresponder.net
>>>>> _______________________________________________
>>>>> Users mailing list
>>>>> Users at lists.strongswan.org
>>>>> https://lists.strongswan.org/mailman/listinfo/users
>>>>>
>>>
>>> --
>>> CJ Fearnley                 |   LinuxForce Inc.
>>> cjf at LinuxForce.net          |   IT Projects & Systems Maintenance
>>> http://www.LinuxForce.net   |   http://blog.remoteresponder.net
>>>
>

More information about the Users mailing list