Hi, I'm trying to talk IPSEC to a Cisco VPN 3000 series machine, but only get few promising results. Looking at the exchange I can see this (I'm 1.2.3.4, the Cisco, not under my control, is 4.3.2.1):
Packet capture: 14:11:14.364288 0:e0:81:64:2:d 0:2:16:48:b1:c2 0800 206: 1.2.3.4.500 > 4.3.2.1.500: [udp sum ok] isakmp v1.0 exchange ID_PROT cookie: ce6919fa8d52a1d4->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 = AES_CBC attribute HASH_ALGORITHM = SHA attribute AUTHENTICATION_METHOD = PRE_SHARED attribute GROUP_DESCRIPTION = MODP_1536 attribute LIFE_TYPE = SECONDS attribute LIFE_DURATION = 3600 attribute KEY_LENGTH = 256 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 64, id 6920, len 192) 14:11:14.413914 0:2:16:48:b1:c2 0:e0:81:64:2:d 0800 170: 4.3.2.1.500 > 1.2.3.4.500: [udp sum ok] isakmp v1.0 exchange ID_PROT cookie: ce6919fa8d52a1d4->a7c8e3ef0094e91d msgid: 00000000 len: 128 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 = AES_CBC attribute KEY_LENGTH = 256 attribute HASH_ALGORITHM = SHA attribute GROUP_DESCRIPTION = MODP_1536 attribute AUTHENTICATION_METHOD = PRE_SHARED attribute LIFE_TYPE = SECONDS attribute LIFE_DURATION = 3600 payload: VENDOR len: 20 (supports v2 NAT-T, draft-ietf-ipsec-nat-t-ike-02) payload: VENDOR len: 24 (ttl 113, id 56325, len 156) 14:11:14.423901 0:e0:81:64:2:d 0:2:16:48:b1:c2 0800 334: 1.2.3.4.500 > 4.3.2.1.500: [udp sum ok] isakmp v1.0 exchange ID_PROT cookie: ce6919fa8d52a1d4->a7c8e3ef0094e91d msgid: 00000000 len: 292 payload: KEY_EXCH len: 196 payload: NONCE len: 20 payload: NAT-D len: 24 payload: NAT-D len: 24 (ttl 64, id 2820, len 320) 14:11:14.538259 0:2:16:48:b1:c2 0:e0:81:64:2:d 0800 410: 4.3.2.1.500 > 1.2.3.4.500: [udp sum ok] isakmp v1.0 exchange ID_PROT cookie: ce6919fa8d52a1d4->a7c8e3ef0094e91d msgid: 00000000 len: 368 payload: KEY_EXCH len: 196 payload: NONCE len: 24 payload: VENDOR len: 20 payload: VENDOR len: 12 payload: VENDOR len: 20 payload: VENDOR len: 20 payload: NAT-D len: 24 payload: NAT-D len: 24 (ttl 113, id 56326, len 396) 14:11:14.549862 0:e0:81:64:2:d 0:2:16:48:b1:c2 0800 134: 1.2.3.4.500 > 4.3.2.1.500: [udp sum ok] isakmp v1.0 exchange ID_PROT encrypted cookie: ce6919fa8d52a1d4->a7c8e3ef0094e91d msgid: 00000000 len: 92 (ttl 64, id 28034, len 120) 14:11:14.695181 0:2:16:48:b1:c2 0:e0:81:64:2:d 0800 134: 4.3.2.1.500 > 1.2.3.4.500: [udp sum ok] isakmp v1.0 exchange ID_PROT encrypted cookie: ce6919fa8d52a1d4->a7c8e3ef0094e91d msgid: 00000000 len: 92 (ttl 113, id 56327, len 120) 14:11:25.247670 0:2:16:48:b1:c2 0:e0:81:64:2:d 0800 134: 4.3.2.1.500 > 1.2.3.4.500: [udp sum ok] isakmp v1.0 exchange INFO encrypted cookie: ce6919fa8d52a1d4->a7c8e3ef0094e91d msgid: a0230bb5 len: 92 (ttl 113, id 56333, len 120) At this point, the two gateways cycle with exchanging ID_PROT messages until the session lifetime for phase 1 expires and a complete new negotiation cycle is started. The relevant config looks much like this: [ISAKMP-THEM] Phase= 1 Transport= udp Authentication= its-me Local-Address= 1.2.3.4 Address= 4.3.2.1 ID= ID-me Remote-ID= ID-them Life= ISAKMPD-phase-1-lifetime Configuration= me-them-main-mode [me-them-main-mode] DOI= IPSEC EXCHANGE_TYPE= ID_PROT Transforms= AES-SHA-GRP5 [AES-SHA-GRP5] KEY_LENGTH= 256,256:256 GROUP_DESCRIPTION= MODP_1536 [ISAKMPD-phase-1-lifetime] LIFE_TYPE= SECONDS LIFE_DURATION= 28800,3600:38800 [me-them-connection] Phase= 2 Configuration= me-them-quick-mode Local-ID= me-net Remote-ID= them-net ISAKMP-peer= ISAKMP-THEM Life= ISAKMPD-phase-2-lifetime [me-net] ID-type= IPV4_ADDR Address= 172.16.10.1 [them-net] ID-type= IPV4_ADDR_SUBNET Network= 172.22.32.0 Netmask= 255.255.255.240 [me-them-quick-mode] DOI= IPSEC EXCHANGE_TYPE= QUICK_MODE Suites= QM-ESP-AES-SHA-256-PFS-GRP5-SUITE [ISAKMPD-phase-2-lifetime] LIFE_TYPE= SECONDS LIFE_DURATION= 28800,3600:38800 And the policy looks like this: Authorizer: "POLICY" Some notes: - _Sometimes_ it get up that way, but not on initial contact from the OpenBSD machine to the Cisco box, but only if OpenBSD is running already, and the Cisco box makes the initial contact. - When specifying a stricter policy, nothing works ("no policy"). - The lifetime in the proposal usually starts out at 3600 while the default is specified to be 28800. - When running isakmpd(8) with -R, a file name option is required: "isakmpd: option requires an argument -- R", contrary to the man page, but it would not write the report anyway, probably due to a problem in the privsep handling, or my stupidity: m_priv_local_sanitize_path: illegal path "/reportfile", replaced with "/dev/null" [priv] - or - m_priv_local_sanitize_path: illegal path "/var/empty/reportfile", replaced with "/dev/null" [priv] - Despite having only 'Authorizer: "POLICY"' in my isakmpd.policy file, I still get this: 150704.777523 Exch 10 exchange_finalize: 0xb15a00 <unnamed> <no policy> policy initiator phase 2 doi 1 exchange 5 step 1 This is stock 3.7 on AMD64. I had absolutely no luck with 3.6 on i386, where the tunnel would not even come up once. FWIW, when I see "INFO encrypted" messages, the other side sees the tunnel as up, but can't transfer any data across it. I'd like to see better what has already been negotiated, but when the tunnel is fully established, I see only two SAs, using ipsecadm, when I expect four (two outer, two inner). Best, --Toni++