'Re: [strongSwan] Help! Problem with Phase 2 SA lifetimes'

[prev in list] [next in list] [prev in thread] [next in thread] 

List:       strongswan-users
Subject:    Re: [strongSwan] Help!  Problem with Phase 2 SA lifetimes
From:       Charles Gordon <diginetsilicon () hotmail ! com>
Date:       2007-07-03 14:14:33
Message-ID: BAY106-W293F9A7949A36BA44F897CE0C0 () phx ! gbl
[Download RAW message or body]

One more time...Hi,I’m trying to debug an issue with strongSwan 2.8 and the Digi VPN \
server.  The Digi VPN server uses Treck IPSEC.  It appears that the StrongSwan agrees \
to use one phase 2 lifetime, but actuallyuses a different one.  The Digi VPN is \
configured to use 5400seconds for the phase 2 lifetime, and the StrongSwan is \
configuredto use 123 seconds.  The Digi initiates the connection and a 123 second \
lifetime is negotiated at first.  When more data istransmitted from the Digi side \
after the first lifetime expires,the Digi side renegotiates the phase 2 lifetime.  \
The Digi VPN attempts to negotiate a 5400 second lifetime again since that iswhat it \
is configured to use.  This time the StrongSwan sends backa message agreeing to the \
5400 second lifetime.  However, it doesnot use this lifetime value.  Instead, it \
times out the phase 2 connection after 123 seconds.I pasted a section of the \
StrongSwan's log below, with interestingsections marked with **** at the beginning.  \
You can see where itgets the 5400 second proposal from the Digi box, and then \
sendsback a reply agreeing to it, even though it is configured to use123 seconds. Jun \
21 15:35:16 : | parsing 4 raw bytes of ISAKMP Proposal Payload into SPIJun 21 \
15:35:16 : | SPI  6c a5 bb c4Jun 21 15:35:16 : | *****parse ISAKMP Transform Payload \
(ESP):Jun 21 15:35:16 : |    next payload type: ISAKMP_NEXT_NONEJun 21 15:35:16 : |   \
length: 40Jun 21 15:35:16 : |    transform number: 1Jun 21 15:35:16 : |    transform \
ID: ESP_3DESJun 21 15:35:16 : | ******parse ISAKMP IPsec DOI attribute:Jun 21 \
15:35:16 : |    af+type: SA_LIFE_TYPEJun 21 15:35:16 : |    length/value: 1Jun 21 \
15:35:16 : |    [1 is SA_LIFE_TYPE_SECONDS]**** Jun 21 15:35:16 : | ******parse \
ISAKMP IPsec DOI attribute:**** Jun 21 15:35:16 : |    af+type: SA_LIFE_DURATION**** \
Jun 21 15:35:16 : |    length/value: 5400Jun 21 15:35:16 : | ******parse ISAKMP IPsec \
DOI attribute:Jun 21 15:35:16 : |    af+type: SA_LIFE_TYPEJun 21 15:35:16 : |    \
length/value: 2Jun 21 15:35:16 : |    [2 is SA_LIFE_TYPE_KBYTES]Jun 21 15:35:16 : | \
******parse ISAKMP IPsec DOI attribute:Jun 21 15:35:16 : |    af+type: \
SA_LIFE_DURATION (variable length)Jun 21 15:35:16 : |    length/value: 4Jun 21 \
15:35:16 : |    long duration: 4194303Jun 21 15:35:16 : | ******parse ISAKMP IPsec \
DOI attribute:Jun 21 15:35:16 : |    af+type: ENCAPSULATION_MODEJun 21 15:35:16 : |   \
length/value: 1Jun 21 15:35:16 : |    [1 is ENCAPSULATION_MODE_TUNNEL]Jun 21 15:35:16 \
: | ******parse ISAKMP IPsec DOI attribute:Jun 21 15:35:16 : |    af+type: \
AUTH_ALGORITHMJun 21 15:35:16 : |    length/value: 1Jun 21 15:35:16 : |    [1 is \
AUTH_ALGORITHM_HMAC_MD5]Jun 21 15:35:16 : | ******parse ISAKMP IPsec DOI \
attribute:Jun 21 15:35:16 : |    af+type: GROUP_DESCRIPTIONJun 21 15:35:16 : |    \
length/value: 5Jun 21 15:35:16 : |    [5 is OAKLEY_GROUP_MODP1536]Jun 21 15:35:16 : | \
kernel_alg_esp_enc_ok(3,0): alg_id=3, alg_ivlen=8, alg_minbits=192, alg_maxbits=192, \
res=0, ret=1Jun 21 15:35:16 : | kernel_alg_esp_enc_keylen():alg_id=3, keylen=24Jun 21 \
15:35:16 : | ****emit IPsec DOI SIT:Jun 21 15:35:16 : |    IPsec DOI SIT: \
SIT_IDENTITY_ONLYJun 21 15:35:16 : | ****emit ISAKMP Proposal Payload:Jun 21 15:35:16 \
: |    next payload type: ISAKMP_NEXT_NONEJun 21 15:35:16 : |    proposal number: \
1Jun 21 15:35:16 : |    protocol ID: PROTO_IPSEC_ESPJun 21 15:35:16 : |    SPI size: \
4Jun 21 15:35:16 : |    number of transforms: 1Jun 21 15:35:16 : | netlink_get_spi: \
allocated 0x5b23bd06 for esp.0@217.91.93.51Jun 21 15:35:16 : | emitting 4 raw bytes \
of SPI into ISAKMP Proposal PayloadJun 21 15:35:16 : | SPI  5b 23 bd 06Jun 21 \
15:35:16 : | *****emit ISAKMP Transform Payload (ESP):Jun 21 15:35:16 : |    next \
payload type: ISAKMP_NEXT_NONEJun 21 15:35:16 : |    transform number: 1Jun 21 \
15:35:16 : |    transform ID: ESP_3DESJun 21 15:35:16 : | emitting 32 raw bytes of \
attributes into ISAKMP Transform Payload (ESP)***** Jun 21 15:35:16 : | attributes  \
80 01 00 01  80 02 15 18  80 01 00 02  00 02 00 04Jun 21 15:35:16 : |   00 3f ff ff  \
80 04 00 01  80 05 00 01  80 03 00 05Jun 21 15:35:16 : | emitting length of ISAKMP \
Transform Payload (ESP): 40 At this point, the Digi box thinks it has negotiated an \
SA lifetime of 5400 seconds.  However, the strongSwan times out the SA in 123 \
seconds. Has anyone run into this problem before?  Is there a fix for it? Also, can \
anyone point me towards documentation for the configuration options in ipsec.conf?  \
I’d especially like to know exactly what the options related to SA timeouts and \
rekeying do.  _________________________________________________________________
See what you’re getting into…before you go there.
http://newlivehotmail.com
_______________________________________________
Users mailing list
Users@lists.strongswan.org
https://lists.strongswan.org/mailman/listinfo/users

[prev in list] [next in list] [prev in thread] [next in thread] 