hello,
dec 18 snap, running on i386
given is an ipsec gateway (i think it's running some older openswan or
some other swan) to which i need to connect, establishing a net-net
tunnel. the parameters needed are "IKE rekeying 1440 minutes (24
hours), IPSEC 3600 seconds (1 hour), both with 3DES/SHA1, no PFS", and
these are carved in stone, i was told.
i can't seem to get isakmpd to establish a tunnel with that site. it
seems as if phase 1 would have been negotiatied fine, but when isakmpd
then sends an `initial contact', then gets back an ipv4_addr, then
things literally stop happening here.
i checked isakmpd packet dumps on other machines, and from what i
gather, here my isakmpd is the one who should start entering into
phase 2 negotiations, but that never happens.
that's what the packet log tells me (X.Y.Z.185 is isakmpd, the local
side; A.B.C.42 is the remote side)
Dec 20 03:45:23.465777 0.0.0.0.500 A.B.C.42.500: [udp sum ok] isakmp v1.0 exchange ID_PRT
cookie: 636b40261faa87b0->0000000000000000 msgid: 00000000 len: 164
payload: SA len: 56 DI: 1(IPSEC) situation: IDENTITYNLY
payload: PRPSAL len: 44 proposal: 1 proto: ISAKMP spisz: 0 xforms: 1
payload: TRANSFRM len: 36
transform: 0 ID: ISAKMP
attribute ENCRYPTIN_ALGRITHM = 3DES_CBC
attribute HASH_ALGRITHM = SHA
attribute AUTHENTICATIN_METHD = PRE_SHARED
attribute GRUP_DESCRIPTIN = MDP_1024
attribute LIFE_TYPE = SECNDS
attribute LIFE_DURATIN = 00015180
payload: VENDR len: 20 (supports v2 NAT-T, draft-ietf-ipsec-nat-t-ike-02)
payload: VENDR len: 20 (supports v3 NAT-T, draft-ietf-ipsec-nat-t-ike-03)
payload: VENDR len: 20 (supports NAT-T, RFC 3947)
payload: VENDR len: 20 (supports DPD v1.0) [ttl 0] (id 1, len 192)
Dec 20 03:45:23.530916 A.B.C.42.500 X.Y.Z.185.500: [udp sum ok] isakmp v1.0 exchange ID_PRT
cookie: 636b40261faa87b0->83821d77d8a07cd2 msgid: 00000000 len: 84
payload: SA len: 56 DI: 1(IPSEC) situation: IDENTITYNLY
payload: PRPSAL len: 44 proposal: 1 proto: ISAKMP spisz: 0 xforms: 1
payload: TRANSFRM len: 36
transform: 1 ID: ISAKMP
attribute ENCRYPTIN_ALGRITHM = 3DES_CBC
attribute HASH_ALGRITHM = SHA
attribute AUTHENTICATIN_METHD = PRE_SHARED
attribute GRUP_DESCRIPTIN = MDP_1024
attribute LIFE_TYPE = SECNDS
attribute LIFE_DURATIN = 00015180 [ttl 0] (id 1, len 112)
Dec 20 03:45:23.548557 X.Y.Z.185.500 A.B.C.42.500: [udp sum ok] isakmp v1.0 exchange ID_PRT
cookie: 636b40261faa87b0->83821d77d8a07cd2 msgid: 00000000 len: 180
payload: KEY_EXCH len: 132
payload: NNCE len: 20 [ttl 0] (id 1, len 208)
Dec 20 03:45:24.141436 A.B.C.42.500 X.Y.Z.185.500: [udp sum ok] isakmp v1.0 exchange ID_PRT
cookie: 636b40261faa87b0->83821d77d8a07cd2 msgid: 00000000 len: 184
payload: KEY_EXCH len: 132
payload: NNCE len: 24 [ttl 0] (id 1, len 212)
Dec 20 03:45:24.162027 X.Y.Z.185.500 A.B.C.42.500: [udp sum ok] isakmp v1.0 exchange ID_PRT
cookie: 636b40261faa87b0->83821d77d8a07cd2 msgid: 00000000 len: 92
payload: ID len: 12 type: IPV4_ADDR = X.Y.Z.185
payload: HASH len: 24
payload: NTIFICATIN len: 28
notification: INITIAL CNTACT (636b40261faa87b0->83821d77d8a07cd2) [ttl 0] (id 1, len 120)
Dec 20 03:45:24.899941 A.B.C.42.500 X.Y.Z.185.500: [udp sum ok] isakmp v1.0 exchange ID_PRT
cookie: 636b40261faa87b0->83821d77d8a07cd2 msgid: 00000000 len: 68
payload: ID len: 12 type: IPV4_ADDR = A.B.C.42
payload: HASH len: 24 [ttl 0] (id 1, len 96)
and then silence. there's nothing not even down the road (i waited for
like 20 minutes for something, anything to happen) as `no proposal
chosen', or any other kind of message that would give a clue as to
where to start.
with an other peer, at this point i also see
Dec 20 03:55:29.817971 me.500 otherpeer.500: [udp sum ok] isakmp v1.0 exchange ID_PRT
cookie: 857f6ffe85cd2ad6->3d173193c107d434 msgid: 00000000 len: 228
payload: KEY_EXCH len: 132
payload: NNCE len: 20
payload: NAT-D-DRAFT len: 24
payload: NAT-D-DRAFT len: 24 [ttl 0] (id 1, len 256)
Dec 20 03:55:29.914622 otherpeer.500 me.500: [udp sum ok] isakmp v1.0 exchange ID_PRT
cookie: 857f6ffe85cd2ad6->3d173193c107d434 msgid: 00000000 len: 228
payload: KEY_EXCH len: 132
payload: NNCE len: 20
payload: NAT-D-DRAFT len: 24
payload: NAT-D-DRAFT len: 24 [ttl 0] (id 1, len 256)
and this is when phase2 negotiations actually begin, and eventually
complete, and a tunnel is established. the only difference i see in
this case is that this latter peer supports some features, which at
the end aren't being used, but still get negotiated to some extent. i
don't know whether this is a useful piece of information.
following is the isakmpd.conf i'm trying to use. i set
default-phase-{1,2}-lifetime so that even in the proposal it alredy
send 86400 seconds for p1, but that didn't seem to make a difference
either
[General]
Retransmits=5
Exchange-max-time=120
Check-interval=1
Default-phase-1-lifetime=86400,60:86400
Default-phase-2-lifetime=3600,60:86400
[Phase 1]
A.B.C.42=ISAKMP-Peer-Remote-peer
[Phase 2]
Connections=
[ISAKMP-Peer-Remote-peer]
Phase=1
Transport=udp
Address=A.B.C.42
Configuration=Remote-peer-main-mode
Authentication=
[Remote-peer-main-mode]
EXCHANGE_TYPE=ID_PRT
Transforms=3DES-SHA-GRP2
[Remote-peer-quick-mode]
EXCHANGE_TYPE=QUICK_MDE
Transforms=QM-ESP-3DES-SHA-SUITE
[]
Phase=2
ISAKMP-Peer=ISAKMP-Peer-Remote-peer
Configuration=Remote-peer-quick-mode
Remote-ID=
Local-ID=Net-Local-192-168-102-0-24
[Net-Local-192-168-102-0-24]
ID-type=IPV4_ADDR_SUBNET
Network=192.168.102.0
Netmask=255.255.255.0
[]
ID-type=IPV4_ADDR_SUBNET
Network=192.168.168.0
Netmask=255.255.255.0
i managed to get a tunnel up with this peer, using astaro security
linux and it's clicky interface to openswan, so at least to *some*
extent and/or in *some* way, the peer must have produced a working
configuration at their side.
on the astaro box i did the same settings in click-language that are
above in isakmpd.conf-talk. the tunnel came up fine with that, but
understandably i wouldn't quite like to keep that solution.
(as a side note, i just remembered ike-scan, and ran it against the
peer. it says:
Main Mode Handshake returned SA=(Enc=3DES Hash=SHA1 Auth=PSK
Group=2:modp1024 LifeType=Seconds LifeDuration(4)=0x00007080)
so i tried with 28800 seconds as well, same result.)
any insight is greatly appreciated.
thanks,

Tue, 20 Dec 2005, Matthew Closson wrote:

matt, all,

[Remote-peer-quick-mode]
EXCHANGE_TYPE= QUICK_MDE
Transforms= QM-ESP-3DES-SHA-SUITE

notice the typo (s/Transforms/Suites/ for correct operation) that only
became obvious after a healthy dose of sleep.

thanks anyway.