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_PROT
cookie: 636b40261faa87b0->0000000000000000 msgid: 00000000 len: 164
payload: SA len: 56 DOI: 1(IPSEC) situation: IDENTITY_ONLY
payload: PROPOSAL len: 44 proposal: 1 proto: ISAKMP spisz: 0
xforms: 1
payload: TRANSFORM len: 36
transform: 0 ID: ISAKMP
attribute ENCRYPTION_ALGORITHM = 3DES_CBC
attribute HASH_ALGORITHM = SHA
attribute AUTHENTICATION_METHOD = PRE_SHARED
attribute GROUP_DESCRIPTION = MODP_1024
attribute LIFE_TYPE = SECONDS
attribute LIFE_DURATION = 00015180
payload: VENDOR len: 20 (supports v2 NAT-T,
draft-ietf-ipsec-nat-t-ike-02)
payload: VENDOR len: 20 (supports v3 NAT-T,
draft-ietf-ipsec-nat-t-ike-03)
payload: VENDOR len: 20 (supports NAT-T, RFC 3947)
payload: VENDOR 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_PROT
cookie: 636b40261faa87b0->83821d77d8a07cd2 msgid: 00000000 len: 84
payload: SA len: 56 DOI: 1(IPSEC) situation: IDENTITY_ONLY
payload: PROPOSAL len: 44 proposal: 1 proto: ISAKMP spisz: 0
xforms: 1
payload: TRANSFORM len: 36
transform: 1 ID: ISAKMP
attribute ENCRYPTION_ALGORITHM = 3DES_CBC
attribute HASH_ALGORITHM = SHA
attribute AUTHENTICATION_METHOD = PRE_SHARED
attribute GROUP_DESCRIPTION = MODP_1024
attribute LIFE_TYPE = SECONDS
attribute LIFE_DURATION = 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_PROT
cookie: 636b40261faa87b0->83821d77d8a07cd2 msgid: 00000000 len: 180
payload: KEY_EXCH len: 132
payload: NONCE 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_PROT
cookie: 636b40261faa87b0->83821d77d8a07cd2 msgid: 00000000 len: 184
payload: KEY_EXCH len: 132
payload: NONCE 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_PROT
cookie: 636b40261faa87b0->83821d77d8a07cd2 msgid: 00000000 len: 92
payload: ID len: 12 type: IPV4_ADDR = X.Y.Z.185
payload: HASH len: 24
payload: NOTIFICATION len: 28
notification: INITIAL CONTACT (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_PROT
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_PROT
cookie: 857f6ffe85cd2ad6->3d173193c107d434 msgid: 00000000 len: 228
payload: KEY_EXCH len: 132
payload: NONCE 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_PROT
cookie: 857f6ffe85cd2ad6->3d173193c107d434 msgid: 00000000 len: 228
payload: KEY_EXCH len: 132
payload: NONCE 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= IPsec-Remote-peer-192-168-168-0-24
[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_PROT
Transforms= 3DES-SHA-GRP2
[Remote-peer-quick-mode]
EXCHANGE_TYPE= QUICK_MODE
Transforms= QM-ESP-3DES-SHA-SUITE
[IPSec-Remote-peer-192-168-168-0-24]
Phase= 2
ISAKMP-Peer= ISAKMP-Peer-Remote-peer
Configuration= Remote-peer-quick-mode
Remote-ID= Net-Remote-peer-192-168-168-0-24
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
[Net-Remote-peer-192-168-168-0-24]
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,
--
[-]
mkdir /nonexistent