I'm trying to set up a tunnel to a Cisco PIX.

It seems to make it past Phase 1, the trouble starts at Phase 2. I've
provided some tcpdump output below:

> 14:21:45.379077 OpenBSD.500 > Cisco_PIX.500: [udp sum ok] isakmp v1.0 exchange ID_PROT
> cookie: bf4ecb71857072fa->0000000000000000 msgid: 00000000 len: 100
> payload: SA len: 52 DOI: 1(IPSEC) situation: IDENTITY_ONLY
> payload: PROPOSAL len: 40 proposal: 1 proto: ISAKMP spisz: 0 xforms: 1
> payload: TRANSFORM len: 32
> transform: 0 ID: ISAKMP
> attribute ENCRYPTION_ALGORITHM = 3DES_CBC
> attribute HASH_ALGORITHM = MD5
> attribute AUTHENTICATION_METHOD = PRE_SHARED
> attribute GROUP_DESCRIPTION = MODP_1024
> attribute LIFE_TYPE = SECONDS
> attribute LIFE_DURATION = 3600
> payload: VENDOR len: 20 (supports DPD v1.0) [ttl 0] (id 1, len 128)
> 14:21:45.735244 Cisco_PIX.500 > OpenBSD.500: [udp sum ok] isakmp v1.0 exchange ID_PROT
> cookie: bf4ecb71857072fa->d24bb58614615ab5 msgid: 00000000 len: 80
> payload: SA len: 52 DOI: 1(IPSEC) situation: IDENTITY_ONLY
> payload: PROPOSAL len: 40 proposal: 1 proto: ISAKMP spisz: 0 xforms: 1
> payload: TRANSFORM len: 32
> transform: 1 ID: ISAKMP
> attribute ENCRYPTION_ALGORITHM = 3DES_CBC
> attribute HASH_ALGORITHM = MD5
> attribute GROUP_DESCRIPTION = MODP_1024
> attribute AUTHENTICATION_METHOD = PRE_SHARED
> attribute LIFE_TYPE = SECONDS
> attribute LIFE_DURATION = 3600 [ttl 0] (id 1, len 108)
> 14:21:45.903344 OpenBSD.500 > Cisco_PIX.500: [udp sum ok] isakmp v1.0 exchange ID_PROT
> cookie: bf4ecb71857072fa->d24bb58614615ab5 msgid: 00000000 len: 180
> payload: KEY_EXCH len: 132
> payload: NONCE len: 20 [ttl 0] (id 1, len 208)
> 14:21:46.511433 Cisco_PIX.500 > OpenBSD.500: [udp sum ok] isakmp v1.0 exchange ID_PROT
> cookie: bf4ecb71857072fa->d24bb58614615ab5 msgid: 00000000 len: 256
> payload: KEY_EXCH len: 132
> payload: NONCE len: 24
> payload: VENDOR len: 12
> payload: VENDOR len: 20 (supports DPD v1.0)
> payload: VENDOR len: 20
> payload: VENDOR len: 20 [ttl 0] (id 1, len 284)
> 14:21:46.848060 OpenBSD.500 > Cisco_PIX.500: [udp sum ok] isakmp v1.0 exchange ID_PROT
> cookie: bf4ecb71857072fa->d24bb58614615ab5 msgid: 00000000 len: 88
> payload: ID len: 12 type: IPV4_ADDR = OpenBSD
> payload: HASH len: 20
> payload: NOTIFICATION len: 28
> notification: INITIAL CONTACT (bf4ecb71857072fa->d24bb58614615ab5) [ttl 0] (id 1, len 116)
> 14:21:47.060117 Cisco_PIX.500 > OpenBSD.500: [udp sum ok] isakmp v1.0 exchange ID_PROT
> cookie: bf4ecb71857072fa->d24bb58614615ab5 msgid: 00000000 len: 68
> payload: ID len: 12 proto: 17 port: 500 type: IPV4_ADDR = Cisco_PIX
> payload: HASH len: 20 [ttl 0] (id 1, len 96)

So, at this point it looks like Phase 1 was successful. Phase 2 begins:

> 14:21:47.235581 OpenBSD.500 > Cisco_PIX.500: [udp sum ok] isakmp v1.0 exchange QUICK_MODE
> cookie: bf4ecb71857072fa->d24bb58614615ab5 msgid: 56fe089d len: 284
> payload: HASH len: 20
> payload: SA len: 52 DOI: 1(IPSEC) situation: IDENTITY_ONLY
> payload: PROPOSAL len: 40 proposal: 1 proto: IPSEC_ESP spisz: 4 xforms: 1 SPI: 0x3147c4bd
> payload: TRANSFORM len: 28
> transform: 1 ID: 3DES
> attribute LIFE_TYPE = SECONDS
> attribute LIFE_DURATION = 28800
> attribute ENCAPSULATION_MODE = TUNNEL
> attribute AUTHENTICATION_ALGORITHM = HMAC_MD5
> attribute GROUP_DESCRIPTION = 2
> payload: NONCE len: 20
> payload: KEY_EXCH len: 132
> payload: ID len: 16 type: IPV4_ADDR_SUBNET = 10.49.10.0/255.255.255.0
> payload: ID len: 16 type: IPV4_ADDR_SUBNET = 10.50.0.0/255.255.254.0 [ttl 0] (id 1, len 312)

First question -- does this look right?

> 14:21:47.598650 Cisco_PIX.500 > OpenBSD.500: [udp sum ok] isakmp v1.0 exchange TRANSACTION
> cookie: bf4ecb71857072fa->d24bb58614615ab5 msgid: 49023a8f len: 76
> payload: HASH len: 20
> payload: ATTRIBUTE len: 20 type: CFG_REQUEST Id: 0
> attribute INTERNAL_IP4_SUBNET = <none>
> attribute SUPPORTED_ATTRIBUTES = <none>
> attribute INTERNAL_IP6_SUBNET = <none> [ttl 0] (id 1, len 104)

What does this mean? This response from the PIX doesn't make any sense
to me. Is it asking for internal subnet info? Is it trying to provide
it? Why would it be putting this in as an attribute?

> 14:21:47.599642 OpenBSD.500 > Cisco_PIX.500: [udp sum ok] isakmp v1.0 exchange TRANSACTION
> cookie: bf4ecb71857072fa->d24bb58614615ab5 msgid: 49023a8f len: 123
> payload: HASH len: 20
> payload: ATTRIBUTE len: 75 type: CFG_REPLY Id: 0
> attribute INTERNAL_IP6_SUBNET = ::/0
> attribute SUPPORTED_ATTRIBUTES = <15 attributes>
> RESERVED
> RESERVED
> RESERVED
> RESERVED
> RESERVED
> RESERVED
> RESERVED
> RESERVED
> RESERVED
> RESERVED
> RESERVED
> RESERVED
> RESERVED
> RESERVED
> RESERVED
> attribute INTERNAL_IP4_SUBNET = 0.0.0.0/0.0.0.0 [ttl 0] (id 1, len 151)

OpenBSD responds -- I don't get this either.

> 14:21:47.874961 Cisco_PIX.500 > OpenBSD.500: [udp sum ok] isakmp v1.0 exchange TRANSACTION
> cookie: bf4ecb71857072fa->d24bb58614615ab5 msgid: 49023a8f len: 68
> payload: HASH len: 20
> payload: ATTRIBUTE len: 12 type: CFG_SET Id: 0
> attribute <unknown> = <none> [ttl 0] (id 1, len 96)

Strange reply...

> 14:21:47.876987 OpenBSD.500 > Cisco_PIX.500: [udp sum ok] isakmp v1.0 exchange INFO
> cookie: bf4ecb71857072fa->d24bb58614615ab5 msgid: 80603edb len: 60
> payload: HASH len: 20
> payload: NOTIFICATION len: 12
> notification: PAYLOAD MALFORMED [ttl 0] (id 1, len 88)

And this is where things grind to a halt. OpenBSD gives a "PAYLOAD
MALFORMED" notification, the PIX retries the previous packet a few more
times, then gives up and ignores all further requests.

Any ideas?

Thanks,

-Stephen-