Hekan Olsson wrote:
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.)
Sure enough, Haakan; this turned out to be the problem.
We reconfigured the PIX not to use mode configuration for this
connection and the SA came up.
This means that Hans-Jvrg can spare himself the work of trying to sort
it out :)
Now, the next problem -- traffic isn't passing... but that's for another
post :)
-Stephen-
