> And you're 100% sure IKE isn't trying to initiate? Did you:
>
> ikeadm set debug all /tmp/logfile
>
> before trying?
IKE wasn't initiating because the local_addr needed to be 0.0.0.0/0 to
match anything, not 0.0.0.0. I'm surprised that /var/log/in.iked log
is so verbose about what interfaces it is listening on, but does not
seem to log any other activity.
After correcting the configuration problem, IKE does initiate, but fails
May 20 01:13:07: Handling data on PF_KEY socket:
SADB msg: message type 6
(ACQUIRE), SA type 0 (UNSPEC),
pid 0, sequence number 4294967274,
error code 0 (Error 0), diag
code 0 (No diagnostic), length 25
May 20 01:13:07: Inner addresses present,
May 20 01:13:07: Doing ACQUIRE....
May 20 01:13:07: Trying to get Phase 1...
May 20 01:13:07: Looking for an existing Phase 1 SA...
May 20 01:13:07: Searching rulebase for src = 192.168.1.17[0]
May 20 01:13:07: dst = 128.2.5.212[0]
May 20 01:13:07: Examining rule list.
May 20 01:13:07: rule 'server2 isam' 0x1;
May 20 01:13:07: local addr
0.0.0.0[2824]-255.255.255.255[2824];
May 20 01:13:07: remote addr 128.2.5.212[2824]
May 20 01:13:07: [basic match]
May 20 01:13:07: Selected rule: 'server2 isam'
May 20 01:13:07: Checking lifetimes in "server2 isam"
May 20 01:13:07: Starting Phase 1 negotiation...
May 20 01:13:07: Constructing local identity payload...
May 20 01:13:07: Local ID type: fqdn(any:0,[0..25]=erehwon.isam.vpn.cmu.local)
May 20 01:13:07: Constructing Phase 1 Transforms:
Our Proposal:
Rule: "server2 isam" ; transform 0
auth_method = 3 (RSA-signatures)
hash_alg = 2 (sha1)
encr_alg = 5 (3des-cbc)
oakley_group = 2
May 20 01:13:07: Constructing Phase 1 Transforms:
Our Proposal:
Rule: "server2 isam" ; transform 1
auth_method = 3 (RSA-signatures)
hash_alg = 2 (sha1)
encr_alg = 5 (3des-cbc)
oakley_group = 2
May 20 01:13:07: Phase 1 exchange type=2 (IP), 2 transform(s).
May 20 01:13:07: Looking for 192.168.1.17[0] in IKE daemon context...
May 20 01:13:07: Sending out Vendor IDs, if needed: NAT-T state 0 (INIT)
May 20 01:13:07: New Phase 1 negotiation!
May 20 01:13:07: Waiting for IKE results.
May 20 01:13:07: IKE library: Using default remote port for NAT-T, if active.
May 20 01:13:07: Vendor ID from peer:
May 20 01:13:07: 0x4a131c81070358455c5728f20e95452f
May 20 01:13:07: NAT-Traversal (RFC 3947)
May 20 01:13:07: Using NAT-D (RFC 3947 VID)
May 20 01:13:07: Vendor ID from peer:
May 20 01:13:07: 0x4048b7d56ebce88525e7de7f00d6c2d3c0000000
May 20 01:13:07: Could not find VID description
May 20 01:13:07: Determining P1 nonce data length.
May 20 01:13:07: NAT-T state 1 (VID)
May 20 01:13:07: IKE library: Using default remote port for NAT-T, if active.
May 20 01:13:07: IKE error: type 10 (Invalid protocol ID), decrypted
1, received 1
May 20 01:13:07: Policy Manager phase 1 info not found! (message type
10 (Invalid protocol ID))
May 20 01:13:07: Notifying library that P2 SA is freed.
May 20 01:13:07: Local IP = 192.168.1.17, Remote IP = 128.2.5.212,
(last 5 lines repeat)
dumping packets now shows that the responder (the cisco gateway) is
sending an INVALID-PAYLOAD-TYPE notification in response to the second
packet sent by the initiator. It seems to be rejecting the NAT-D
payload (the notification data contains the single octet 0x14, which
_may_ represent the payload type that was rejected), even though the
RFC3947 negotiation seems to have succeeded.
(http://www.contrib.andrew.cmu.edu/~cg2vunreleased/osol-cisco-ike-natt-fail.cap
if anyone's curious)
I guess given that there's a phase 1 interoperability problem that
appears to be cisco's fault, and that in.iked does not have source
available, I'm out of luck for the time being. (I wonder if racoon
will work with solaris's PF_KEY....)
_______________________________________________
networking-discuss mailing list
networking-discuss@opensolaris.org
