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