On 29 jun 2006, at 22.33, Stephen Bosch wrote:
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:
...
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?
Yup, this is a normal first packet of a quick mode negotiation.
isakmpd now expects the 2nd packet, but instead gets a new exchange
('TRANSACTION' type, or mode-config):
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?
A guess would be the PIX regards the OpenBSD machine as (some kind of
a Cisco-specific?) client and wants to know what configuration data
it can accept. Typically that 'what are your SUPPORTED_ATTRIBUTES' part.
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.
No, and it shouldn't send this response. It's a bug. isakmpd does not
support the "client-side" of mode-config, only the server side. The
skeleton for the client-side code is there, but it was never
implemented fully. (There's a lot of things that need to work
together here, such as having the privilege separated isakmpd process
being able to add/change IP and netmask of an interface etc. The need
for client-side support has not been requested much, so we've not
done anything more here yet.)
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...
Yes. Seems the PIX did not handle isakmpd's (nonsensical) reply wery
well. :)
Plus, isakmpd will not accept a CFG_SET here, as seen by the response:
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?
See if you can convince the PIX to regard the OpenBSD box as another
gateway and not a "client"? Or perhaps tell it that the other
machine is not to be considered a Cisco-box? Or disable mode-config
(if possible)? I don't recall all the ins-and-outs of the PIX
configuration (it's a bit non-obvious at times...), but I've
configured a number of PIX:es to interoperate with isakmpd without
too much trouble. The latest was perhaps a year ago or so... perhaps
this is something added recently?
/H
