On Wed, Oct 05, 2005 at 01:20:57AM +0000, [EMAIL PROTECTED] wrote: > Having trouble brining up a tunnel.
a nice compromise between debug output and too much info, i've found thus far is: -dDA=0 -D2=50 -D5=50 -D7=50 -D8=40 -D9=30 > Though never seems to move on to phase 2 see snip 2 <...> > isakmpd -dDA=50 > --------snip 1 -------- > 173611.209764 Exch 40 exchange_run: exchange 0x893c00 finished step 5, > advancing... > 173611.210067 Mesg 10 virtual_send_message: enabling NAT-T encapsulation for > this exchange > 173611.210410 Exch 10 exchange_finalize: 0x893c00 xpws Default-main-mode > policy responder phase 1 doi 1 exchange 2 step 6 > 173611.210685 Exch 10 exchange_finalize: icookie 90d893da9f1f4816 rcookie > 83c51437d4efd48e > 173611.210921 Exch 10 exchange_finalize: msgid 00000000 > 173611.212348 Exch 10 exchange_finalize: phase 1 done: initiator id > /C=US/ST=California/L=Martinez/O=ccchsd/OU=IS/CN=loanerxppc2.xxxx.gov, > responder id [EMAIL PROTECTED], src: 172.16.5.241 dst: 172.16.4.230 > 17361 what does it look like after that? does it get into "EXCH_TYPE: QUICK_MODE" (mesg:70) or do you see any "exchange_establish_p2" ? (exch:10) that looks similar to the 'phase 1 done' up there. after that there should be a bunch of pf_key_v2 stuff ( misc/sdep 50 at least, 80 for more ). yours should have 'winxp' in them, or whatever the name of the '[phase 2]:connections=' is set to. iirc, you should be able to see, some time thereafter, what the reason for failure is. also look for mesg:50 lines who tell you what you're seeing back from the responder wrt proposals. > ----------snip 2 --------- > 5555ghri_fw:root:/etc/isakmpd #isakmpd -dD9=99 > 173331.863667 Default log_debug_cmd: log level changed from 0 to 99 for class > 9 [priv] > 173332.317663 Plcy 30 policy_init: initializing > 173332.321123 Default x509_read_from_dir: PEM_read_X509 failed for ca.srl > 173338.331292 Plcy 90 x509_generate_kn: generating KeyNote policy for > certificate 0x88da00 > 173338.332119 Plcy 60 x509_generate_kn: added credential > 173338.332481 Plcy 80 x509_generate_kn: added credential: > Authorizer: > "DN:/C=US/ST=California/L=Martinez/O=ccchsd/OU=IS/CN=555ghrifw.xxxx.gov" > Licensees: "DN:/C=US/ST=California/L=Martinez/O=ccchsd/OU=IS/CN=loanerxppc2. > 173338.335104 Plcy 30 keynote_cert_obtain: failed to open > "/etc/isakmpd/keynote//[EMAIL PROTECTED]/credentials" i wouldn't worry about that unless you're actually using keynote, which it seems you aren't. > [Default-main-mode] > DOI= IPSEC > EXCHANGE_TYPE= ID_PROT > Transforms= 3DES-SHA-RSA_SIG > > # Encryption/Authentication suite definitions > > [3DES-SHA-RSA_SIG] > ENCRYPTION_ALGORITHM= 3DES_CBC > HASH_ALGORITHM= SHA > AUTHENTICATION_METHOD= RSA_SIG > ENCAPSULATION_MODE= TUNNEL > AUTHENTICATION_ALGORITHM= HMAC_SHA this looks a bit mixed up to me. 'encapsulation_mode' and 'authentication_algorithm' are IPsec (phase2) parameters, whereas 'encryption_algorithm' and 'hash_algorithm' are IKE (phase1). you shouldn't have to redefine this, it's one of the predefinitions that makes -D0=95 or higher so painful: configuration value not found [3DES-SHA-RSA_SIG]:ENCRYPTION_ALGORITHM [3DES-SHA-RSA_SIG]:ENCRYPTION_ALGORITHM->3DES_CBC configuration value not found [3DES-SHA-RSA_SIG]:HASH_ALGORITHM [3DES-SHA-RSA_SIG]:HASH_ALGORITHM->SHA configuration value not found [3DES-SHA-RSA_SIG]:AUTHENTICATION_METHOD [3DES-SHA-RSA_SIG]:AUTHENTICATION_METHOD->RSA_SIG configuration value not found [3DES-SHA-RSA_SIG]:GROUP_DESCRIPTION [3DES-SHA-RSA_SIG]:GROUP_DESCRIPTION->MODP_1024 configuration value not found [3DES-SHA-RSA_SIG]:Life [3DES-SHA-RSA_SIG]:Life->LIFE_MAIN_MODE i *believe* (but do not know for sure) that isakmp just usually ignores settings that don't make sense to it, provided that they don't collide with other names. so, as long as isakmpd isn't redefining the entire section, but simply adding/overwriting whatever the predefinition is, you're probably not doing any real damage by redefining the 3des-sha-rsa_sig, but i don't think it is providing a benefit. > 5555ghri_fw:root:/etc/isakmpd #cat isakmpd.policy if it works with shared secrets, does it also work with isakmpd -K ? (or a policy file that says nothing more than 'Authorizer: "POLICY"') or was that the XP box working with shared secrets to the remote host rather than the openbsd box working with shared secrets to the remote host? > KeyNote-Version: 2 > Comment: This policy accepts ESP SAs from a remote that uses the right > password > $OpenBSD: policy,v 1.6 2001/06/20 16:36:19 angelos Exp $ > $EOM: policy,v 1.6 2000/10/09 22:08:30 angelos Exp $ > Authorizer: "POLICY" > Licensees: > "DN:/C=US/ST=California/L=Martinez/O=ccchsd/OU=IS/CN=555ghrifw.ccchsd.gov" || > "passphrase:1234" || "passphrase:0291ff014dccdd03874d9e8e4cdf3e6" > Conditions: app_domain == "IPsec policy" && > esp_present == "yes" && > esp_enc_alg != "null" -> "true"; > > # --- [EMAIL PROTECTED] --- > authorizer: "[EMAIL PROTECTED]" > licensees:"DN:" > conditions: remote_id_type =="ASN1 DN" && > remote_id =="" -> "true"; for one of these sections to match, doesn't the 'authorizer' section have to be == to the 'licensee' part above it ( this is how the example in keynote(5) is laid out )? though, if it a 'licensee' doesn't match a subordinate 'authorizer', perhaps it simply means that no conditions or further licensee delegations descend from it. jared -- [ openbsd 3.8 GENERIC ( sep 27 ) // i386 ]
