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++
