Mailing List Archive

[patch] add draft-ietf-ipsec-nat-t-ike-03
Hi all,

the attached patch against the vpnc-nortel branch adds
draft-ietf-ipsec-nat-t-ike-03
This is one part of the changes needed to make the Fritz!Box
vpn server happy.

This patch is partly taken from Florian Echtlers patch from
June 8: http://permalink.gmane.org/gmane.network.vpnc.devel/3435

The changes to the default lifetime are left out as they are adressed
differently in an upcoming patch

Best regards,

Stefan
--
Stefan Seyfried

"Dispatch war rocket Ajax to bring back his body!"
Re: [patch] add draft-ietf-ipsec-nat-t-ike-03 [ In reply to ]
On Mon, Nov 7, 2011 at 10:38 PM, Stefan Seyfried
<stefan.seyfried@googlemail.com> wrote:
> Hi all,
>
> the attached patch against the vpnc-nortel branch adds
> draft-ietf-ipsec-nat-t-ike-03
> This is one part of the changes needed to make the Fritz!Box
> vpn server happy.
>
> This patch is partly taken from Florian Echtlers patch from
> June 8: http://permalink.gmane.org/gmane.network.vpnc.devel/3435

Hi Stefan,
I will check if the patch gives any issue to Nortel connection.
If ok, I will commit it.

Does it make sense to apply it to trunk too?
Can someone test it on trunk with a connection to Cisco VPN?

Best Regards
Antonio Borneo
_______________________________________________
vpnc-devel mailing list
vpnc-devel@unix-ag.uni-kl.de
https://lists.unix-ag.uni-kl.de/mailman/listinfo/vpnc-devel
http://www.unix-ag.uni-kl.de/~massar/vpnc/
Re: [patch] add draft-ietf-ipsec-nat-t-ike-03 [ In reply to ]
On 08.11.2011 03:59, Antonio Borneo wrote:

> On Mon, Nov 7, 2011 at 10:38 PM, Stefan Seyfried
> <stefan.seyfried@googlemail.com> wrote:
>> Hi all,
>>
>> the attached patch against the vpnc-nortel branch adds
>> draft-ietf-ipsec-nat-t-ike-03
>> This is one part of the changes needed to make the Fritz!Box
>> vpn server happy.
>>
>> This patch is partly taken from Florian Echtlers patch from
>> June 8: http://permalink.gmane.org/gmane.network.vpnc.devel/3435
>
> Hi Stefan,
> I will check if the patch gives any issue to Nortel connection.
> If ok, I will commit it.
>
> Does it make sense to apply it to trunk too?


I think so. But then, I know not much about IPSEC ;-)

Actually my FritzBox works initially without this patch, but after
~300(?) seconds, the dead peer detection kicks in and kills the connection.

> Can someone test it on trunk with a connection to Cisco VPN?


Sorry, only a FritzBox available here.
--
Stefan Seyfried
Linux Consultant & Developer
Mail: seyfried@b1-systems.de GPG Key: 0x731B665B

B1 Systems GmbH
Osterfeldstraße 7 / 85088 Vohburg / http://www.b1-systems.de
GF: Ralph Dehner / Unternehmenssitz: Vohburg / AG: Ingolstadt,HRB 3537
_______________________________________________
vpnc-devel mailing list
vpnc-devel@unix-ag.uni-kl.de
https://lists.unix-ag.uni-kl.de/mailman/listinfo/vpnc-devel
http://www.unix-ag.uni-kl.de/~massar/vpnc/
Re: [patch] add draft-ietf-ipsec-nat-t-ike-03 [ In reply to ]
Antonio Borneo wrote:
> On Mon, Nov 7, 2011 at 10:38 PM, Stefan Seyfried
> <stefan.seyfried@googlemail.com> wrote:
>> Hi all,
>>
>> the attached patch against the vpnc-nortel branch adds
>> draft-ietf-ipsec-nat-t-ike-03
>> This is one part of the changes needed to make the Fritz!Box
>> vpn server happy.
>>
>> This patch is partly taken from Florian Echtlers patch from
>> June 8: http://permalink.gmane.org/gmane.network.vpnc.devel/3435
>
> Hi Stefan,
> I will check if the patch gives any issue to Nortel connection.
> If ok, I will commit it.
>
> Does it make sense to apply it to trunk too?
> Can someone test it on trunk with a connection to Cisco VPN?

Hi,
I tested current trunk p472 but my connection still dies after one hour.
Look for the "lifetime" in the current output below:


[cut]
got peer udp encapsulation port: 10000
got pfs setting: 0
Remote Application Version: Cisco Systems, Inc ASA5520 Version 8.4(1) built by builders on Mon 31-Jan-11 02:11
got address 172.16.3.219
[cut]

S7.3 QM_packet2 validate type
[2011-11-09 15:27:10]
BEGIN_PARSE
Recieved Packet Len: 92
i_cookie: 94b5b887 2ed2820e
r_cookie: f0154f34 4658fa01
payload: 08 (ISAKMP_PAYLOAD_HASH)
isakmp_version: 10
exchange_type: 05 (ISAKMP_EXCHANGE_INFORMATIONAL)
flags: 01
message_id: ad220511
len: 0000005c

PARSING PAYLOAD type: 08 (ISAKMP_PAYLOAD_HASH)
next_type: 0b (ISAKMP_PAYLOAD_N)
length: 0018
ke.data:
4a86304c 1bd8d9e1 5a28947a d152a22a 78a3359c
DONE PARSING PAYLOAD type: 08 (ISAKMP_PAYLOAD_HASH)

PARSING PAYLOAD type: 0b (ISAKMP_PAYLOAD_N)
next_type: 00 (ISAKMP_PAYLOAD_NONE)
length: 0024
n.doi: 00000001 (ISAKMP_DOI_IPSEC)
n.protocol: 01 (ISAKMP_IPSEC_PROTO_ISAKMP)
n.spi_length: 10
n.type: 6000 (ISAKMP_N_IPSEC_RESPONDER_LIFETIME)
n.spi: 94b5b887 2ed2820e f0154f34 4658fa01
n.data: 800b0001 800c0e10
t.attributes.type: 000b (IKE_ATTRIB_LIFE_TYPE)
t.attributes.u.attr_16: 0001 (IKE_LIFE_TYPE_SECONDS)
t.attributes.type: 000c (IKE_ATTRIB_LIFE_DURATION)
t.attributes.u.attr_16: 0e10
DONE PARSING PAYLOAD type: 0b (ISAKMP_PAYLOAD_N)

PARSING PAYLOAD type: 00 (ISAKMP_PAYLOAD_NONE)
PARSE_OK
hashlen: 20
u.hash.length: 20
expected_hash:
c7a2b459 af24e289 04842e6e d639de25 b7c70983
h->u.hash.data:
4a86304c 1bd8d9e1 5a28947a d152a22a 78a3359c
got ike lifetime attributes: 3600 seconds


receiving: <========================
[2011-11-09 15:27:10]
BEGIN_PARSE
Recieved Packet Len: 188
i_cookie: 94b5b887 2ed2820e
r_cookie: f0154f34 4658fa01
payload: 08 (ISAKMP_PAYLOAD_HASH)
isakmp_version: 10
exchange_type: 20 (ISAKMP_EXCHANGE_IKE_QUICK)
flags: 01
message_id: 29f1c1df
len: 000000bc

PARSING PAYLOAD type: 08 (ISAKMP_PAYLOAD_HASH)
next_type: 01 (ISAKMP_PAYLOAD_SA)
length: 0018
ke.data:
96905d8c f80e9ea5 c1c2876a b50c73c3 4a55ec25
DONE PARSING PAYLOAD type: 08 (ISAKMP_PAYLOAD_HASH)

PARSING PAYLOAD type: 01 (ISAKMP_PAYLOAD_SA)
next_type: 0a (ISAKMP_PAYLOAD_NONCE)
length: 0038
sa.doi: 00000001 (ISAKMP_DOI_IPSEC)
sa.situation: 00000001 (ISAKMP_IPSEC_SIT_IDENTITY_ONLY)

PARSING PAYLOAD type: 02 (ISAKMP_PAYLOAD_P)
next_type: 00 (ISAKMP_PAYLOAD_NONE)
length: 002c
p.number: 01
p.prot_id: 03 (ISAKMP_IPSEC_PROTO_IPSEC_ESP)
p.spi_size: 04
length: 01
p.spi: 3a902206

PARSING PAYLOAD type: 03 (ISAKMP_PAYLOAD_T)
next_type: 00 (ISAKMP_PAYLOAD_NONE)
length: 0020
t.number: 01
t.id: 0c (ISAKMP_IPSEC_ESP_AES)
t.attributes.type: 0001 (ISAKMP_IPSEC_ATTRIB_SA_LIFE_TYPE)
t.attributes.u.attr_16: 0001 (IPSEC_LIFE_SECONDS)
t.attributes.type: 0002 (ISAKMP_IPSEC_ATTRIB_SA_LIFE_DURATION)
t.attributes.u.lots.length: 0004
t.attributes.u.lots.data: 0020c49b
t.attributes.type: 0004 (ISAKMP_IPSEC_ATTRIB_ENCAP_MODE)
t.attributes.u.attr_16: 0001 (IPSEC_ENCAP_TUNNEL)
t.attributes.type: 0005 (ISAKMP_IPSEC_ATTRIB_AUTH_ALG)
t.attributes.u.attr_16: 0002 (IPSEC_AUTH_HMAC_SHA)
t.attributes.type: 0006 (ISAKMP_IPSEC_ATTRIB_KEY_LENGTH)
t.attributes.u.attr_16: 00c0
DONE PARSING PAYLOAD type: 03 (ISAKMP_PAYLOAD_T)

PARSING PAYLOAD type: 00 (ISAKMP_PAYLOAD_NONE)
DONE PARSING PAYLOAD type: 02 (ISAKMP_PAYLOAD_P)

PARSING PAYLOAD type: 00 (ISAKMP_PAYLOAD_NONE)
DONE PARSING PAYLOAD type: 01 (ISAKMP_PAYLOAD_SA)

PARSING PAYLOAD type: 0a (ISAKMP_PAYLOAD_NONCE)
next_type: 05 (ISAKMP_PAYLOAD_ID)
length: 0018
ke.data:
41ea40f4 41453cfb 184252e2 8765e14b 3a1bffd3
DONE PARSING PAYLOAD type: 0a (ISAKMP_PAYLOAD_NONCE)

PARSING PAYLOAD type: 05 (ISAKMP_PAYLOAD_ID)
next_type: 05 (ISAKMP_PAYLOAD_ID)
length: 000c
id.type: 01 (ISAKMP_IPSEC_ID_IPV4_ADDR)
id.protocol: 00
id.port: 0000
id.data: ac1003db
DONE PARSING PAYLOAD type: 05 (ISAKMP_PAYLOAD_ID)

PARSING PAYLOAD type: 05 (ISAKMP_PAYLOAD_ID)
next_type: 0b (ISAKMP_PAYLOAD_N)
length: 0010
id.type: 04 (ISAKMP_IPSEC_ID_IPV4_ADDR_SUBNET)
id.protocol: 00
id.port: 0000
id.data: 00000000 00000000
DONE PARSING PAYLOAD type: 05 (ISAKMP_PAYLOAD_ID)

PARSING PAYLOAD type: 0b (ISAKMP_PAYLOAD_N)
next_type: 00 (ISAKMP_PAYLOAD_NONE)
length: 0018
n.doi: 00000001 (ISAKMP_DOI_IPSEC)
n.protocol: 03 (ISAKMP_IPSEC_PROTO_IPSEC_ESP)
n.spi_length: 04
n.type: 6000 (ISAKMP_N_IPSEC_RESPONDER_LIFETIME)
n.spi: 3a902206
n.data: 80010001 80027080
t.attributes.type: 0001 (ISAKMP_IPSEC_ATTRIB_SA_LIFE_TYPE)
t.attributes.u.attr_16: 0001 (IPSEC_LIFE_SECONDS)
t.attributes.type: 0002 (ISAKMP_IPSEC_ATTRIB_SA_LIFE_DURATION)
t.attributes.u.attr_16: 7080
DONE PARSING PAYLOAD type: 0b (ISAKMP_PAYLOAD_N)

PARSING PAYLOAD type: 00 (ISAKMP_PAYLOAD_NONE)
PARSE_OK
hashlen: 20
u.hash.length: 20
expected_hash:
96905d8c f80e9ea5 c1c2876a b50c73c3 4a55ec25
h->u.hash.data:
96905d8c f80e9ea5 c1c2876a b50c73c3 4a55ec25

S7.5 QM_packet2 check reject offer
[2011-11-09 15:27:10]

S7.6 QM_packet2 check and process proposal
[2011-11-09 15:27:10]
got ipsec lifetime attributes: 2147483 seconds
IPSEC SA selected aes192-sha1
got ipsec lifetime attributes: 28800 seconds
authing NULL package!
size = 24, blksz = 8, padding = 0

sending: ========================>
BEGIN_PARSE
Recieved Packet Len: 52
i_cookie: 94b5b887 2ed2820e
r_cookie: f0154f34 4658fa01
payload: 08 (ISAKMP_PAYLOAD_HASH)
isakmp_version: 10
exchange_type: 20 (ISAKMP_EXCHANGE_IKE_QUICK)
flags: 01
message_id: 29f1c1df
len: 00000034

PARSING PAYLOAD type: 08 (ISAKMP_PAYLOAD_HASH)
next_type: 00 (ISAKMP_PAYLOAD_NONE)
length: 0018
ke.data:
ed8e876d ab6b3efb 980b7a8a e6e9f904 1efd76b0
DONE PARSING PAYLOAD type: 08 (ISAKMP_PAYLOAD_HASH)

PARSING PAYLOAD type: 00 (ISAKMP_PAYLOAD_NONE)
PARSE_OK

S7.7 QM_packet3 sent
[2011-11-09 15:27:10]

S7.8 setup ipsec tunnel
[2011-11-09 15:27:10]
generating 44 bytes keymat (cnt=3)
generating 44 bytes keymat (cnt=3)

S7.9 main loop (receive and transmit ipsec packets)
[2011-11-09 15:27:10]
rx.key_cry:
2b786131 621de9cc 491b1083 1cbcec7b 64225c59 a5248e5c
rx.key_md:
d12dcc19 f8b78c2d 16f48f14 a9841821 32062deb
tx.key_cry:
4e6a0d82 65c59880 b7f9cc28 ee8875ef cca0d077 aa7fa938
tx.key_md:
687f0e2c 3b5fc06c 9ce08295 932251b4 cf24e2c5
remote -> local spi: 0x1a819fcd
local -> remote spi: 0x3a902206
VPNC started in background (pid: 4520)...



Maybe I should turn on more aggressive debug log? Grr. Could the defaults
be adjusted so that STDERR receives some messages when vpnc is being killed
for whatever reason? Thanks,
Martin
_______________________________________________
vpnc-devel mailing list
vpnc-devel@unix-ag.uni-kl.de
https://lists.unix-ag.uni-kl.de/mailman/listinfo/vpnc-devel
http://www.unix-ag.uni-kl.de/~massar/vpnc/
Re: [patch] add draft-ietf-ipsec-nat-t-ike-03 [ In reply to ]
Hi,
a short follow-up which shows the various time limits?

# grep -i time /tmp/vpnc.log
got ike lifetime attributes: 2147483 seconds
n.type: 6000 (ISAKMP_N_IPSEC_RESPONDER_LIFETIME)
got ike lifetime attributes: 3600 seconds
n.type: 6000 (ISAKMP_N_IPSEC_RESPONDER_LIFETIME)
got ipsec lifetime attributes: 2147483 seconds
got ipsec lifetime attributes: 28800 seconds
#

Martin

Martin Mokrejs wrote:
>
>
> Antonio Borneo wrote:
>> On Mon, Nov 7, 2011 at 10:38 PM, Stefan Seyfried
>> <stefan.seyfried@googlemail.com> wrote:
>>> Hi all,
>>>
>>> the attached patch against the vpnc-nortel branch adds
>>> draft-ietf-ipsec-nat-t-ike-03
>>> This is one part of the changes needed to make the Fritz!Box
>>> vpn server happy.
>>>
>>> This patch is partly taken from Florian Echtlers patch from
>>> June 8: http://permalink.gmane.org/gmane.network.vpnc.devel/3435
>>
>> Hi Stefan,
>> I will check if the patch gives any issue to Nortel connection.
>> If ok, I will commit it.
>>
>> Does it make sense to apply it to trunk too?
>> Can someone test it on trunk with a connection to Cisco VPN?
>
> Hi,
> I tested current trunk p472 but my connection still dies after one hour.
> Look for the "lifetime" in the current output below:
>
>
> [cut]
> got peer udp encapsulation port: 10000
> got pfs setting: 0
> Remote Application Version: Cisco Systems, Inc ASA5520 Version 8.4(1) built by builders on Mon 31-Jan-11 02:11
> got address 172.16.3.219
> [cut]
>
> S7.3 QM_packet2 validate type
> [2011-11-09 15:27:10]
> BEGIN_PARSE
> Recieved Packet Len: 92
> i_cookie: 94b5b887 2ed2820e
> r_cookie: f0154f34 4658fa01
> payload: 08 (ISAKMP_PAYLOAD_HASH)
> isakmp_version: 10
> exchange_type: 05 (ISAKMP_EXCHANGE_INFORMATIONAL)
> flags: 01
> message_id: ad220511
> len: 0000005c
>
> PARSING PAYLOAD type: 08 (ISAKMP_PAYLOAD_HASH)
> next_type: 0b (ISAKMP_PAYLOAD_N)
> length: 0018
> ke.data:
> 4a86304c 1bd8d9e1 5a28947a d152a22a 78a3359c
> DONE PARSING PAYLOAD type: 08 (ISAKMP_PAYLOAD_HASH)
>
> PARSING PAYLOAD type: 0b (ISAKMP_PAYLOAD_N)
> next_type: 00 (ISAKMP_PAYLOAD_NONE)
> length: 0024
> n.doi: 00000001 (ISAKMP_DOI_IPSEC)
> n.protocol: 01 (ISAKMP_IPSEC_PROTO_ISAKMP)
> n.spi_length: 10
> n.type: 6000 (ISAKMP_N_IPSEC_RESPONDER_LIFETIME)
> n.spi: 94b5b887 2ed2820e f0154f34 4658fa01
> n.data: 800b0001 800c0e10
> t.attributes.type: 000b (IKE_ATTRIB_LIFE_TYPE)
> t.attributes.u.attr_16: 0001 (IKE_LIFE_TYPE_SECONDS)
> t.attributes.type: 000c (IKE_ATTRIB_LIFE_DURATION)
> t.attributes.u.attr_16: 0e10
> DONE PARSING PAYLOAD type: 0b (ISAKMP_PAYLOAD_N)
>
> PARSING PAYLOAD type: 00 (ISAKMP_PAYLOAD_NONE)
> PARSE_OK
> hashlen: 20
> u.hash.length: 20
> expected_hash:
> c7a2b459 af24e289 04842e6e d639de25 b7c70983
> h->u.hash.data:
> 4a86304c 1bd8d9e1 5a28947a d152a22a 78a3359c
> got ike lifetime attributes: 3600 seconds
>
>
> receiving: <========================
> [2011-11-09 15:27:10]
> BEGIN_PARSE
> Recieved Packet Len: 188
> i_cookie: 94b5b887 2ed2820e
> r_cookie: f0154f34 4658fa01
> payload: 08 (ISAKMP_PAYLOAD_HASH)
> isakmp_version: 10
> exchange_type: 20 (ISAKMP_EXCHANGE_IKE_QUICK)
> flags: 01
> message_id: 29f1c1df
> len: 000000bc
>
> PARSING PAYLOAD type: 08 (ISAKMP_PAYLOAD_HASH)
> next_type: 01 (ISAKMP_PAYLOAD_SA)
> length: 0018
> ke.data:
> 96905d8c f80e9ea5 c1c2876a b50c73c3 4a55ec25
> DONE PARSING PAYLOAD type: 08 (ISAKMP_PAYLOAD_HASH)
>
> PARSING PAYLOAD type: 01 (ISAKMP_PAYLOAD_SA)
> next_type: 0a (ISAKMP_PAYLOAD_NONCE)
> length: 0038
> sa.doi: 00000001 (ISAKMP_DOI_IPSEC)
> sa.situation: 00000001 (ISAKMP_IPSEC_SIT_IDENTITY_ONLY)
>
> PARSING PAYLOAD type: 02 (ISAKMP_PAYLOAD_P)
> next_type: 00 (ISAKMP_PAYLOAD_NONE)
> length: 002c
> p.number: 01
> p.prot_id: 03 (ISAKMP_IPSEC_PROTO_IPSEC_ESP)
> p.spi_size: 04
> length: 01
> p.spi: 3a902206
>
> PARSING PAYLOAD type: 03 (ISAKMP_PAYLOAD_T)
> next_type: 00 (ISAKMP_PAYLOAD_NONE)
> length: 0020
> t.number: 01
> t.id: 0c (ISAKMP_IPSEC_ESP_AES)
> t.attributes.type: 0001 (ISAKMP_IPSEC_ATTRIB_SA_LIFE_TYPE)
> t.attributes.u.attr_16: 0001 (IPSEC_LIFE_SECONDS)
> t.attributes.type: 0002 (ISAKMP_IPSEC_ATTRIB_SA_LIFE_DURATION)
> t.attributes.u.lots.length: 0004
> t.attributes.u.lots.data: 0020c49b
> t.attributes.type: 0004 (ISAKMP_IPSEC_ATTRIB_ENCAP_MODE)
> t.attributes.u.attr_16: 0001 (IPSEC_ENCAP_TUNNEL)
> t.attributes.type: 0005 (ISAKMP_IPSEC_ATTRIB_AUTH_ALG)
> t.attributes.u.attr_16: 0002 (IPSEC_AUTH_HMAC_SHA)
> t.attributes.type: 0006 (ISAKMP_IPSEC_ATTRIB_KEY_LENGTH)
> t.attributes.u.attr_16: 00c0
> DONE PARSING PAYLOAD type: 03 (ISAKMP_PAYLOAD_T)
>
> PARSING PAYLOAD type: 00 (ISAKMP_PAYLOAD_NONE)
> DONE PARSING PAYLOAD type: 02 (ISAKMP_PAYLOAD_P)
>
> PARSING PAYLOAD type: 00 (ISAKMP_PAYLOAD_NONE)
> DONE PARSING PAYLOAD type: 01 (ISAKMP_PAYLOAD_SA)
>
> PARSING PAYLOAD type: 0a (ISAKMP_PAYLOAD_NONCE)
> next_type: 05 (ISAKMP_PAYLOAD_ID)
> length: 0018
> ke.data:
> 41ea40f4 41453cfb 184252e2 8765e14b 3a1bffd3
> DONE PARSING PAYLOAD type: 0a (ISAKMP_PAYLOAD_NONCE)
>
> PARSING PAYLOAD type: 05 (ISAKMP_PAYLOAD_ID)
> next_type: 05 (ISAKMP_PAYLOAD_ID)
> length: 000c
> id.type: 01 (ISAKMP_IPSEC_ID_IPV4_ADDR)
> id.protocol: 00
> id.port: 0000
> id.data: ac1003db
> DONE PARSING PAYLOAD type: 05 (ISAKMP_PAYLOAD_ID)
>
> PARSING PAYLOAD type: 05 (ISAKMP_PAYLOAD_ID)
> next_type: 0b (ISAKMP_PAYLOAD_N)
> length: 0010
> id.type: 04 (ISAKMP_IPSEC_ID_IPV4_ADDR_SUBNET)
> id.protocol: 00
> id.port: 0000
> id.data: 00000000 00000000
> DONE PARSING PAYLOAD type: 05 (ISAKMP_PAYLOAD_ID)
>
> PARSING PAYLOAD type: 0b (ISAKMP_PAYLOAD_N)
> next_type: 00 (ISAKMP_PAYLOAD_NONE)
> length: 0018
> n.doi: 00000001 (ISAKMP_DOI_IPSEC)
> n.protocol: 03 (ISAKMP_IPSEC_PROTO_IPSEC_ESP)
> n.spi_length: 04
> n.type: 6000 (ISAKMP_N_IPSEC_RESPONDER_LIFETIME)
> n.spi: 3a902206
> n.data: 80010001 80027080
> t.attributes.type: 0001 (ISAKMP_IPSEC_ATTRIB_SA_LIFE_TYPE)
> t.attributes.u.attr_16: 0001 (IPSEC_LIFE_SECONDS)
> t.attributes.type: 0002 (ISAKMP_IPSEC_ATTRIB_SA_LIFE_DURATION)
> t.attributes.u.attr_16: 7080
> DONE PARSING PAYLOAD type: 0b (ISAKMP_PAYLOAD_N)
>
> PARSING PAYLOAD type: 00 (ISAKMP_PAYLOAD_NONE)
> PARSE_OK
> hashlen: 20
> u.hash.length: 20
> expected_hash:
> 96905d8c f80e9ea5 c1c2876a b50c73c3 4a55ec25
> h->u.hash.data:
> 96905d8c f80e9ea5 c1c2876a b50c73c3 4a55ec25
>
> S7.5 QM_packet2 check reject offer
> [2011-11-09 15:27:10]
>
> S7.6 QM_packet2 check and process proposal
> [2011-11-09 15:27:10]
> got ipsec lifetime attributes: 2147483 seconds
> IPSEC SA selected aes192-sha1
> got ipsec lifetime attributes: 28800 seconds
> authing NULL package!
> size = 24, blksz = 8, padding = 0
>
> sending: ========================>
> BEGIN_PARSE
> Recieved Packet Len: 52
> i_cookie: 94b5b887 2ed2820e
> r_cookie: f0154f34 4658fa01
> payload: 08 (ISAKMP_PAYLOAD_HASH)
> isakmp_version: 10
> exchange_type: 20 (ISAKMP_EXCHANGE_IKE_QUICK)
> flags: 01
> message_id: 29f1c1df
> len: 00000034
>
> PARSING PAYLOAD type: 08 (ISAKMP_PAYLOAD_HASH)
> next_type: 00 (ISAKMP_PAYLOAD_NONE)
> length: 0018
> ke.data:
> ed8e876d ab6b3efb 980b7a8a e6e9f904 1efd76b0
> DONE PARSING PAYLOAD type: 08 (ISAKMP_PAYLOAD_HASH)
>
> PARSING PAYLOAD type: 00 (ISAKMP_PAYLOAD_NONE)
> PARSE_OK
>
> S7.7 QM_packet3 sent
> [2011-11-09 15:27:10]
>
> S7.8 setup ipsec tunnel
> [2011-11-09 15:27:10]
> generating 44 bytes keymat (cnt=3)
> generating 44 bytes keymat (cnt=3)
>
> S7.9 main loop (receive and transmit ipsec packets)
> [2011-11-09 15:27:10]
> rx.key_cry:
> 2b786131 621de9cc 491b1083 1cbcec7b 64225c59 a5248e5c
> rx.key_md:
> d12dcc19 f8b78c2d 16f48f14 a9841821 32062deb
> tx.key_cry:
> 4e6a0d82 65c59880 b7f9cc28 ee8875ef cca0d077 aa7fa938
> tx.key_md:
> 687f0e2c 3b5fc06c 9ce08295 932251b4 cf24e2c5
> remote -> local spi: 0x1a819fcd
> local -> remote spi: 0x3a902206
> VPNC started in background (pid: 4520)...
>
>
>
> Maybe I should turn on more aggressive debug log? Grr. Could the defaults
> be adjusted so that STDERR receives some messages when vpnc is being killed
> for whatever reason? Thanks,
> Martin
> _______________________________________________
> vpnc-devel mailing list
> vpnc-devel@unix-ag.uni-kl.de
> https://lists.unix-ag.uni-kl.de/mailman/listinfo/vpnc-devel
> http://www.unix-ag.uni-kl.de/~massar/vpnc/
>
>
_______________________________________________
vpnc-devel mailing list
vpnc-devel@unix-ag.uni-kl.de
https://lists.unix-ag.uni-kl.de/mailman/listinfo/vpnc-devel
http://www.unix-ag.uni-kl.de/~massar/vpnc/
Re: [patch] add draft-ietf-ipsec-nat-t-ike-03 [ In reply to ]
On 09.11.2011 16:46, Martin Mokrejs wrote:

>
>
> Antonio Borneo wrote:
>> On Mon, Nov 7, 2011 at 10:38 PM, Stefan Seyfried
>> <stefan.seyfried@googlemail.com> wrote:
>>> Hi all,
>>>
>>> the attached patch against the vpnc-nortel branch adds
>>> draft-ietf-ipsec-nat-t-ike-03
>>> This is one part of the changes needed to make the Fritz!Box
>>> vpn server happy.
>>>
>>> This patch is partly taken from Florian Echtlers patch from
>>> June 8: http://permalink.gmane.org/gmane.network.vpnc.devel/3435
>>
>> Hi Stefan,
>> I will check if the patch gives any issue to Nortel connection.
>> If ok, I will commit it.
>>
>> Does it make sense to apply it to trunk too?
>> Can someone test it on trunk with a connection to Cisco VPN?
>
> Hi,
> I tested current trunk p472 but my connection still dies after one hour.


See http://permalink.gmane.org/gmane.network.vpnc.devel/3512
It's butt ugly, but it works for me ;-)

> Look for the "lifetime" in the current output below:


Everything correct AFAICT.

Use "--debug 2 --no-detach" and you'll see the seconds counting...
--
Stefan Seyfried

"Dispatch war rocket Ajax to bring back his body!"
_______________________________________________
vpnc-devel mailing list
vpnc-devel@unix-ag.uni-kl.de
https://lists.unix-ag.uni-kl.de/mailman/listinfo/vpnc-devel
http://www.unix-ag.uni-kl.de/~massar/vpnc/
Re: [patch] add draft-ietf-ipsec-nat-t-ike-03 [ In reply to ]
Stefan Seyfried wrote:
> On 09.11.2011 16:46, Martin Mokrejs wrote:
>
>>
>>
>> Antonio Borneo wrote:
>>> On Mon, Nov 7, 2011 at 10:38 PM, Stefan Seyfried
>>> <stefan.seyfried@googlemail.com> wrote:
>>>> Hi all,
>>>>
>>>> the attached patch against the vpnc-nortel branch adds
>>>> draft-ietf-ipsec-nat-t-ike-03
>>>> This is one part of the changes needed to make the Fritz!Box
>>>> vpn server happy.
>>>>
>>>> This patch is partly taken from Florian Echtlers patch from
>>>> June 8: http://permalink.gmane.org/gmane.network.vpnc.devel/3435
>>>
>>> Hi Stefan,
>>> I will check if the patch gives any issue to Nortel connection.
>>> If ok, I will commit it.
>>>
>>> Does it make sense to apply it to trunk too?
>>> Can someone test it on trunk with a connection to Cisco VPN?
>>
>> Hi,
>> I tested current trunk p472 but my connection still dies after one hour.
>
>
> See http://permalink.gmane.org/gmane.network.vpnc.devel/3512
> It's butt ugly, but it works for me ;-)

Ahh, thought it was applied by Antonio to trunk few days ago. It does not
Apply for me to p472:

$ patch -p1 < /tmp/vpnc-restart-after-timeout.diff
patching file tunip.c
patching file vpnc.c
Hunk #1 FAILED at 3774.
Hunk #2 FAILED at 3842.
2 out of 2 hunks FAILED -- saving rejects to file vpnc.c.rej
$

Will try to find some time to apply manually in the next days but if you could
send me an updated version for trunk I will gladly test that ASAP. ;) Thanks.

>
>> Look for the "lifetime" in the current output below:
>
>
> Everything correct AFAICT.
>
> Use "--debug 2 --no-detach" and you'll see the seconds counting...

Hmm, I have in /etc/vpnc/default.conf:

Debug 3

So why wasn't that picked up? Because vpnc detached from tty?

Thanks,
martin


_______________________________________________
vpnc-devel mailing list
vpnc-devel@unix-ag.uni-kl.de
https://lists.unix-ag.uni-kl.de/mailman/listinfo/vpnc-devel
http://www.unix-ag.uni-kl.de/~massar/vpnc/
Re: [patch] add draft-ietf-ipsec-nat-t-ike-03 [ In reply to ]
On 09.11.2011 18:01, Martin Mokrejs wrote:

> Ahh, thought it was applied by Antonio to trunk few days ago. It does not
> Apply for me to p472:
>
> $ patch -p1 < /tmp/vpnc-restart-after-timeout.diff
> patching file tunip.c
> patching file vpnc.c
> Hunk #1 FAILED at 3774.
> Hunk #2 FAILED at 3842.
> 2 out of 2 hunks FAILED -- saving rejects to file vpnc.c.rej
> $


It is against the nortel branch


> Will try to find some time to apply manually in the next days but if you could
> send me an updated version for trunk I will gladly test that ASAP. ;) Thanks.


just use the nortel branch.

Best regards,

Stefan
--
Stefan Seyfried

"Dispatch war rocket Ajax to bring back his body!"
_______________________________________________
vpnc-devel mailing list
vpnc-devel@unix-ag.uni-kl.de
https://lists.unix-ag.uni-kl.de/mailman/listinfo/vpnc-devel
http://www.unix-ag.uni-kl.de/~massar/vpnc/
Re: [patch] add draft-ietf-ipsec-nat-t-ike-03 [ In reply to ]
Stefan Seyfried wrote:
> On 09.11.2011 18:01, Martin Mokrejs wrote:
>
>> Ahh, thought it was applied by Antonio to trunk few days ago. It does not
>> Apply for me to p472:
>>
>> $ patch -p1 < /tmp/vpnc-restart-after-timeout.diff
>> patching file tunip.c
>> patching file vpnc.c
>> Hunk #1 FAILED at 3774.
>> Hunk #2 FAILED at 3842.
>> 2 out of 2 hunks FAILED -- saving rejects to file vpnc.c.rej
>> $
>
>
> It is against the nortel branch
>
>
>> Will try to find some time to apply manually in the next days but if you could
>> send me an updated version for trunk I will gladly test that ASAP. ;) Thanks.
>
>
> just use the nortel branch.

Well I applied manually the vpnc.c changes to my trunk checkout and recompiled.
I still do get my connection broken to Cisco:

[cut]
lifetime status: 3360 of 28800 seconds used, 3180|107 of 0 kbytes used
lifetime status: 3369 of 28800 seconds used, 3180|107 of 0 kbytes used
lifetime status: 3379 of 28800 seconds used, 3180|107 of 0 kbytes used
lifetime status: 3388 of 28800 seconds used, 3180|107 of 0 kbytes used
lifetime status: 3398 of 28800 seconds used, 3180|107 of 0 kbytes used
lifetime status: 3407 of 28800 seconds used, 3180|107 of 0 kbytes used
lifetime status: 3417 of 28800 seconds used, 3180|107 of 0 kbytes used
lifetime status: 3420 of 28800 seconds used, 3180|107 of 0 kbytes used
got late ike packet: 308 bytes
got packet with wrong cookies
lifetime status: 3426 of 28800 seconds used, 3180|107 of 0 kbytes used
lifetime status: 3428 of 28800 seconds used, 3180|107 of 0 kbytes used
got late ike packet: 308 bytes
got packet with wrong cookies
lifetime status: 3435 of 28800 seconds used, 3180|107 of 0 kbytes used
lifetime status: 3436 of 28800 seconds used, 3180|107 of 0 kbytes used
got late ike packet: 308 bytes
got packet with wrong cookies
lifetime status: 3444 of 28800 seconds used, 3180|107 of 0 kbytes used
lifetime status: 3445 of 28800 seconds used, 3180|107 of 0 kbytes used
got late ike packet: 308 bytes
got packet with wrong cookies
lifetime status: 3452 of 28800 seconds used, 3180|107 of 0 kbytes used
got late ike packet: 68 bytes

S7.1 QM_packet1
[2011-11-10 09:11:26]

S7.2 QM_packet2 send_receive
[2011-11-10 09:11:26]

S7.3 QM_packet2 validate type
[2011-11-10 09:11:26]
got delete for old connection, ignoring..
vpnc: no response from target
#


>
> Best regards,
>
> Stefan
_______________________________________________
vpnc-devel mailing list
vpnc-devel@unix-ag.uni-kl.de
https://lists.unix-ag.uni-kl.de/mailman/listinfo/vpnc-devel
http://www.unix-ag.uni-kl.de/~massar/vpnc/
Re: [patch] add draft-ietf-ipsec-nat-t-ike-03 [ In reply to ]
Hi Martin,

On 10.11.2011 09:30, Martin Mokrejs wrote:

> Well I applied manually the vpnc.c changes to my trunk checkout and recompiled.
> I still do get my connection broken to Cisco:


But it is a different issue:

>
> [cut]

[...]

> lifetime status: 3444 of 28800 seconds used, 3180|107 of 0 kbytes used
> lifetime status: 3445 of 28800 seconds used, 3180|107 of 0 kbytes used
> got late ike packet: 308 bytes
> got packet with wrong cookies
> lifetime status: 3452 of 28800 seconds used, 3180|107 of 0 kbytes used
> got late ike packet: 68 bytes


Lifetime not exceeded

>
> S7.1 QM_packet1
> [2011-11-10 09:11:26]
>
> S7.2 QM_packet2 send_receive
> [2011-11-10 09:11:26]
>
> S7.3 QM_packet2 validate type
> [2011-11-10 09:11:26]
> got delete for old connection, ignoring..


No idea what this is - rekeying?

> vpnc: no response from target


Did this work for longer time before the recent changes?
--
Stefan Seyfried
Linux Consultant & Developer
Mail: seyfried@b1-systems.de GPG Key: 0x731B665B

B1 Systems GmbH
Osterfeldstraße 7 / 85088 Vohburg / http://www.b1-systems.de
GF: Ralph Dehner / Unternehmenssitz: Vohburg / AG: Ingolstadt,HRB 3537
_______________________________________________
vpnc-devel mailing list
vpnc-devel@unix-ag.uni-kl.de
https://lists.unix-ag.uni-kl.de/mailman/listinfo/vpnc-devel
http://www.unix-ag.uni-kl.de/~massar/vpnc/
Re: [patch] add draft-ietf-ipsec-nat-t-ike-03 [ In reply to ]
Hi Stefan,

Stefan Seyfried wrote:
> Hi Martin,
>
> On 10.11.2011 09:30, Martin Mokrejs wrote:
>
>> Well I applied manually the vpnc.c changes to my trunk checkout and recompiled.
>> I still do get my connection broken to Cisco:
>
>
> But it is a different issue:
>
>>
>> [cut]
>
> [...]
>
>> lifetime status: 3444 of 28800 seconds used, 3180|107 of 0 kbytes used
>> lifetime status: 3445 of 28800 seconds used, 3180|107 of 0 kbytes used
>> got late ike packet: 308 bytes
>> got packet with wrong cookies
>> lifetime status: 3452 of 28800 seconds used, 3180|107 of 0 kbytes used
>> got late ike packet: 68 bytes
>
>
> Lifetime not exceeded
>
>>
>> S7.1 QM_packet1
>> [2011-11-10 09:11:26]
>>
>> S7.2 QM_packet2 send_receive
>> [2011-11-10 09:11:26]
>>
>> S7.3 QM_packet2 validate type
>> [2011-11-10 09:11:26]
>> got delete for old connection, ignoring..
>
>
> No idea what this is - rekeying?
>
>> vpnc: no response from target
>
>
> Did this work for longer time before the recent changes?

No, never ever since about a year when I started using vpnc. I only have 1 hour
connections from Linux, and have no such problem under Cisco client from MS Win.

Martin
_______________________________________________
vpnc-devel mailing list
vpnc-devel@unix-ag.uni-kl.de
https://lists.unix-ag.uni-kl.de/mailman/listinfo/vpnc-devel
http://www.unix-ag.uni-kl.de/~massar/vpnc/
Re: [patch] add draft-ietf-ipsec-nat-t-ike-03 [ In reply to ]
I re-tried a nortel branch to be sure but hit same problem. This time I increased the debug
so attached is what is happening at about the same lifetime in a repeated case. Now I will
stopping bugging the list with my issue unless somebody asks for more details/testing.
Thanks to all for your patience, ;)
Martin

Martin Mokrejs wrote:
> Hi Stefan,
>
> Stefan Seyfried wrote:
>> Hi Martin,
>>
>> On 10.11.2011 09:30, Martin Mokrejs wrote:
>>
>>> Well I applied manually the vpnc.c changes to my trunk checkout and recompiled.
>>> I still do get my connection broken to Cisco:
>>
>>
>> But it is a different issue:
>>
>>>
>>> [cut]
>>
>> [...]
>>
>>> lifetime status: 3444 of 28800 seconds used, 3180|107 of 0 kbytes used
>>> lifetime status: 3445 of 28800 seconds used, 3180|107 of 0 kbytes used
>>> got late ike packet: 308 bytes
>>> got packet with wrong cookies
>>> lifetime status: 3452 of 28800 seconds used, 3180|107 of 0 kbytes used
>>> got late ike packet: 68 bytes
>>
>>
>> Lifetime not exceeded
>>
>>>
>>> S7.1 QM_packet1
>>> [2011-11-10 09:11:26]
>>>
>>> S7.2 QM_packet2 send_receive
>>> [2011-11-10 09:11:26]
>>>
>>> S7.3 QM_packet2 validate type
>>> [2011-11-10 09:11:26]
>>> got delete for old connection, ignoring..
>>
>>
>> No idea what this is - rekeying?
>>
>>> vpnc: no response from target
>>
>>
>> Did this work for longer time before the recent changes?
>
> No, never ever since about a year when I started using vpnc. I only have 1 hour
> connections from Linux, and have no such problem under Cisco client from MS Win.
>
> Martin
> _______________________________________________
> vpnc-devel mailing list
> vpnc-devel@unix-ag.uni-kl.de
> https://lists.unix-ag.uni-kl.de/mailman/listinfo/vpnc-devel
> http://www.unix-ag.uni-kl.de/~massar/vpnc/
>
>
Re: [patch] add draft-ietf-ipsec-nat-t-ike-03 [ In reply to ]
On Thu, Nov 10, 2011 at 7:47 PM, Martin Mokrejs
<mmokrejs@fold.natur.cuni.cz> wrote:
> I re-tried a nortel branch to be sure but hit same problem. This time I increased the debug
> so attached is what is happening at about the same lifetime in a repeated case. Now I will
> stopping bugging the list with my issue unless somebody asks for more details/testing.
> Thanks to all for your patience, ;)
> Martin

Hi Martin,
I'm not willing to commit Stefan's patch as is.
At least I would like to have this functionality selectable by user.
Further suggests below.

Stefan tested its patch with his Fritz!Box server and, for what I
know, should also work with the Nortel server I normally connect to.

With my Nortel server I got these lines "grep-ing" the output log:
got ike lifetime attributes: 31536000 seconds
got ipsec lifetime attributes: 28800 seconds
The first is 1 year, the second is 8 hours.
Of course the ipsec timeout will expire earlier.
I also have no way to reach the ike timeout, since Nortel server has a
mandatory feature to reset all the connections once per day at a
predefined hour, so no way to stay connected for longer than 24 hours.
I expect Stefan get similar situation where ipsec timeout expires
before ike one, since his patch just looks at s->ipsec.life.seconds

Your case is the opposite; from your log:
got ike lifetime attributes: 3600 seconds
got ipsec lifetime attributes: 28800 seconds
The ike timeout expires before the ipsec one.
Are you able to modify Stefan's patch to cover this case? You should
look for s->ike.life.seconds

For me, a good fix/patch
a) should check all the possible conditions:
- s->ike.life.seconds
- s->ike.life.kbytes
- s->ipsec.life.seconds
- s->ipsec.life.kbytes
b) should be disabled by default to prefer ike and ipsec keys
renegotiation, if this feature is implemented and working.
c) user should be able to enable this feature by command line or
configuration file only if he/she really needs it.

Of course, comments are welcome.

Best Regards,
Antonio Borneo
_______________________________________________
vpnc-devel mailing list
vpnc-devel@unix-ag.uni-kl.de
https://lists.unix-ag.uni-kl.de/mailman/listinfo/vpnc-devel
http://www.unix-ag.uni-kl.de/~massar/vpnc/
Re: [patch] add draft-ietf-ipsec-nat-t-ike-03 [ In reply to ]
Hi Antonio,
maybe I could hack Stefan's patch but programming in C is not my usual work.
But I could test an extra patch. Sorry for the late reply I was away for several
days.
Thanks,
Martin

Antonio Borneo wrote:
> On Thu, Nov 10, 2011 at 7:47 PM, Martin Mokrejs
> <mmokrejs@fold.natur.cuni.cz> wrote:
>> I re-tried a nortel branch to be sure but hit same problem. This time I increased the debug
>> so attached is what is happening at about the same lifetime in a repeated case. Now I will
>> stopping bugging the list with my issue unless somebody asks for more details/testing.
>> Thanks to all for your patience, ;)
>> Martin
>
> Hi Martin,
> I'm not willing to commit Stefan's patch as is.
> At least I would like to have this functionality selectable by user.
> Further suggests below.
>
> Stefan tested its patch with his Fritz!Box server and, for what I
> know, should also work with the Nortel server I normally connect to.
>
> With my Nortel server I got these lines "grep-ing" the output log:
> got ike lifetime attributes: 31536000 seconds
> got ipsec lifetime attributes: 28800 seconds
> The first is 1 year, the second is 8 hours.
> Of course the ipsec timeout will expire earlier.
> I also have no way to reach the ike timeout, since Nortel server has a
> mandatory feature to reset all the connections once per day at a
> predefined hour, so no way to stay connected for longer than 24 hours.
> I expect Stefan get similar situation where ipsec timeout expires
> before ike one, since his patch just looks at s->ipsec.life.seconds
>
> Your case is the opposite; from your log:
> got ike lifetime attributes: 3600 seconds
> got ipsec lifetime attributes: 28800 seconds
> The ike timeout expires before the ipsec one.
> Are you able to modify Stefan's patch to cover this case? You should
> look for s->ike.life.seconds
>
> For me, a good fix/patch
> a) should check all the possible conditions:
> - s->ike.life.seconds
> - s->ike.life.kbytes
> - s->ipsec.life.seconds
> - s->ipsec.life.kbytes
> b) should be disabled by default to prefer ike and ipsec keys
> renegotiation, if this feature is implemented and working.
> c) user should be able to enable this feature by command line or
> configuration file only if he/she really needs it.
>
> Of course, comments are welcome.
>
> Best Regards,
> Antonio Borneo
>
>
_______________________________________________
vpnc-devel mailing list
vpnc-devel@unix-ag.uni-kl.de
https://lists.unix-ag.uni-kl.de/mailman/listinfo/vpnc-devel
http://www.unix-ag.uni-kl.de/~massar/vpnc/