[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

obsd<->linux IKE interop. question



Trying to do IKE between two routers, one Linux, one OpenBSD.  Manually
keyed connection works fine.

As I read the logs, the OpenBSD machine is agreeing to the exchange, but
the Linux box is not; but I can't figure out where they disagree.  The
Linux box is the one that's complaining, but given my (lack of)
experience it could be either side that's botched, hence the cross-post
(sorry...)

Here's an excerpt from the output of the keying daemon on the OpenBSD
side ("isakmpd -d -DA=99"):

110657.510690 Misc 60 conf_get_str:
[3DES-SHA]:ENCRYPTION_ALGORITHM->3DES_CBC
110657.510705 Misc 60 conf_get_str: [3DES-SHA]:HASH_ALGORITHM->SHA
110657.510720 Misc 60 conf_get_str:
[3DES-SHA]:AUTHENTICATION_METHOD->PRE_SHARED110657.510734 Misc 60
conf_get_str: [3DES-SHA]:GROUP_DESCRIPTION->MODP_1024
110657.510761 Misc 20 ike_phase_1_validate_prop: success
110657.510774 Mesg 30 message_negotiate_sa: proposal 0 succeeded
110657.510787 Misc 20 ipsec_decode_transform: transform 0 chosen
110657.510813 Misc 70 group_get: returning 0x118340 of group 2
110657.510829 Exch 40 exchange_run: exchange 0x120600 finished step 0,
advancing...
110657.510844 Trpt 90 transport_reference: transport 0x107780 now has 3
references
110657.510855 Mesg 90 message_alloc: allocated 0x120a00
110657.510867 SA   80 sa_reference: SA 0x120700 now has 3 references
110657.510881 Misc 30 ipsec_responder: phase 1 exchange 2 step 1
110657.510907 Exch 90 exchange_validate: checking for required SA
110657.510920 Mesg 70 message_send: message 0x120a00
110657.510936 Mesg 70 ICOOKIE: 0x8f2a221a0d78f107
110657.510951 Mesg 70 RCOOKIE: 0xc2ecb9800795cb4f
110657.510962 Mesg 70 NEXT_PAYLOAD: SA
110657.510974 Mesg 70 VERSION: 16
110657.510986 Mesg 70 EXCH_TYPE: ID_PROT
110657.510998 Mesg 70 FLAGS: [ ]
110657.511011 Mesg 70 MESSAGE_ID: 0x00000000
110657.511023 Mesg 70 LENGTH: 80
110657.511053 Mesg 70 message_send: 8f2a221a 0d78f107 c2ecb980 0795cb4f
01100200 00000000 00000050 00000034
110657.511085 Mesg 70 message_send: 00000001 00000001 00000028 00010001
00000020 00010000 800b0001 800c0e10
110657.511107 Mesg 70 message_send: 80010005 80020002 80030001 80040002 
110657.511119 Exch 40 exchange_run: exchange 0x120600 finished step 1,
advancing...


As I read this, it looks like the OBSD box is happy; proposal 0 is
chosen, reference counts are incremented; looks like something is going
right.

But on the Linux side:

[several 'parse ISAKMP Oakley attribute' sections snipped]
Jan 15 14:58:53 localhost Pluto[5699]: | ******parse ISAKMP Oakley
attribute:
Jan 15 14:58:53 localhost Pluto[5699]: |    af+type:
OAKLEY_HASH_ALGORITHM
Jan 15 14:58:53 localhost Pluto[5699]: |    length/value: 2
Jan 15 14:58:53 localhost Pluto[5699]: |    [2 is OAKLEY_SHA]
Jan 15 14:58:53 localhost Pluto[5699]: | ******parse ISAKMP Oakley
attribute:
Jan 15 11:04:56 localhost Pluto[5381]: |    af+type:
OAKLEY_AUTHENTICATION_METHOD
Jan 15 11:04:56 localhost Pluto[5381]: |    length/value: 1
Jan 15 11:04:56 localhost Pluto[5381]: |    [1 is OAKLEY_PRESHARED_KEY]
Jan 15 11:04:56 localhost Pluto[5381]: "sysvi-saecos" #2: Can't
authenticate: no preshared key.  Attribute OAKLEY_AUTHENTICATION_METHOD
Jan 15 11:04:56 localhost Pluto[5381]: "sysvi-saecos" #2: no acceptable
Oakley Transform
Jan 15 11:04:56 localhost Pluto[5381]: | state transition function for
STATE_MAIN_R0 failed: NO_PROPOSAL_CHOSEN

I'm trying to authenticate by shared secret and I'm using the 3DES-SHA
predefined transform on the OpenBSD side, because that seemed like the
simplest case for getting started.  When I've found references to the
"NO_PROPOSAL_CHOSEN" complaint in the FreeS/WAN archives, it seems that
the most likely cause is a failure to index the key string in
/etc/ipsec.secrets, but I'm indexing by IP address and I know that the
IP addresses are correct for the participating peers as listed in that
file, and the two hosts do each have the same string of characters
listed as the secret.

So I don't know where else this could be falling down, particularly
since the OpenBSD side seems to think that all is well.

Rather than soak up bandwidth with all my config files, here are
pointers to copies.

For the OpenBSD side:

http://www.sysvi.com/~mjinks/botched_configs/openbsd/isakmpd.conf
http://www.sysvi.com/~mjinks/botched_configs/openbsd/isakmpd.policy

FreeS/WAN side:

http://www.sysvi.com/~mjinks/botched_configs/freeswan/ipsec.conf
http://www.sysvi.com/~mjinks/botched_configs/freeswan/ipsec.secrets

I'd post more (larger log excerpts, tcpdump output, whatever) but I'm
not sure what would be helpful.

TIA,
-michael