<html>
<head>
<meta content="text/html; charset=ISO-8859-1"
http-equiv="Content-Type">
</head>
<body text="#000000" bgcolor="#FFFFFF">
I found the problem -- it's on the Z-10's end. Disregard please;
this has to go up the chain with BB.<br>
<br>
<div class="moz-cite-prefix">On 4/27/2013 2:30 PM, Karl Denninger
wrote:<br>
</div>
<blockquote cite="mid:517C2772.4000301@denninger.net" type="cite">
<meta http-equiv="content-type" content="text/html;
charset=ISO-8859-1">
Perusing the lists I see that this has come up before with the
Playbook and was never resolved. Perhaps I can obtain enough
understanding to fix this for everyone, or point someone to where
the problem resides.<br>
<br>
The configuration is StrongSwan 5.0.3 with the following in
ipsec.conf:<br>
<br>
<br>
# ipsec.conf - strongSwan IPsec configuration file<br>
<br>
# basic configuration<br>
<br>
config setup<br>
# strictcrlpolicy=yes<br>
# uniqueids = no<br>
<br>
# Add connections here.<br>
<br>
# Sample VPN connections<br>
<br>
conn %default<br>
keyingtries=1<br>
keyexchange=ikev2<br>
<br>
conn remote<br>
left=%any<br>
leftsubnet=0.0.0.0/0<br>
right=%any<br>
rightsourceip=192.168.2.0/24<br>
<a moz-do-not-send="true"
class="moz-txt-link-abbreviated"
href="mailto:rightid=karl@denninger.net">rightid=karl@denninger.net</a><br>
rightauth=psk<br>
leftauth=pubkey<br>
leftcert=genesis.pem<br>
<a moz-do-not-send="true"
class="moz-txt-link-abbreviated"
href="mailto:leftid=@genesis.denninger.net">leftid=@genesis.denninger.net</a><br>
auto=add<br>
<br>
Ipsec.secrets contains:<br>
#<br>
# Our certificate for the gateway<br>
: RSA genesis.pem<br>
<br>
#<br>
# Passwords<br>
#<br>
%any : PSK "TheSecret"<br>
<br>
(Actually, no, it's not "TheSecret", but you get the idea.)<br>
<br>
With ipsec.conf authenticating with "leftauth=psk" and BOTH
gateway and remote using the login of an email address (which can
be anything) and the PSK, <i><b>it works</b></i>.<br>
<br>
When I try to use a machine certificate to authenticate the server
after loading my private CA into the Z10 and then connecting using
that for server identity (and a PSK for the client) <u><b>instead</b></u>
of a PSK for both, it fails with this:<br>
<br>
<br>
Apr 27 14:15:27 NewFS charon: 07[NET] received packet: from
208.54.70.231[26100] to 70.169.168.7[500] (400 bytes)<br>
Apr 27 14:15:27 NewFS charon: 07[ENC] parsed IKE_SA_INIT request 0
[ SA KE No N(NATD_S_IP) N(NATD_D_IP) ]<br>
Apr 27 14:15:27 NewFS charon: 07[IKE] 208.54.70.231 is initiating
an IKE_SA<br>
Apr 27 14:15:27 NewFS charon: 07[IKE] remote host is behind NAT<br>
Apr 27 14:15:27 NewFS charon: 07[IKE] sending cert request for
"C=US, ST=Florida, L=Niceville, O=Cuda Systems LLC, CN=Cuda
Systems LLC CA, <a moz-do-not-send="true"
class="moz-txt-link-abbreviated"
href="mailto:E=customer-service@cudasystems.net">E=customer-service@cudasystems.net</a>"<br>
Apr 27 14:15:27 NewFS charon: 07[ENC] generating IKE_SA_INIT
response 0 [ SA KE No N(NATD_S_IP) N(NATD_D_IP) CERTREQ
N(MULT_AUTH) ]<br>
Apr 27 14:15:27 NewFS charon: 07[NET] sending packet: from
70.169.168.7[500] to 208.54.70.231[26100] (337 bytes)<br>
Apr 27 14:15:28 NewFS charon: 14[NET] received packet: from
208.54.70.231[51135] to 70.169.168.7[4500] (332 bytes)<br>
Apr 27 14:15:28 NewFS charon: 14[ENC] parsed IKE_AUTH request 1 [
IDi CERTREQ AUTH CP(ADDR MASK DNS DNS NBNS NBNS VER)
N(INIT_CONTACT) N(MOBIKE_SUP) N(ESP_TFC_PAD_N) N(NON_FIRST_FRAG)
SA TSi TSr ]<br>
Apr 27 14:15:28 NewFS charon: 14[CFG] looking for peer configs
matching 70.169.168.7[%any]...208.54.70.231[<a
moz-do-not-send="true" class="moz-txt-link-abbreviated"
href="mailto:karl@denninger.net">karl@denninger.net</a>]<br>
Apr 27 14:15:28 NewFS charon: 14[CFG] selected peer config
'remote'<br>
<b>Apr 27 14:15:28 NewFS charon: 14[IKE] tried 1 shared key for
'%any' - '<a moz-do-not-send="true"
class="moz-txt-link-abbreviated"
href="mailto:karl@denninger.net">karl@denninger.net</a>', but
MAC mismatched [0 1]</b><br>
Apr 27 14:15:28 NewFS charon: 14[IKE] received
ESP_TFC_PADDING_NOT_SUPPORTED, not using ESPv3 TFC padding<br>
Apr 27 14:15:28 NewFS charon: 14[IKE] peer supports MOBIKE<br>
Apr 27 14:15:28 NewFS charon: 14[ENC] generating IKE_AUTH response
1 [ N(AUTH_FAILED) ]<br>
Apr 27 14:15:28 NewFS charon: 14[NET] sending packet: from
70.169.168.7[4500] to 208.54.70.231[51135] (76 bytes)<br>
<br>
I added the two additional debugging flags in the line highlighted
to get a handle on what was failing in the tests up above. The
reason the failure occurs is that that this test fails in
psk_authenticator.c @ ~136:<br>
<br>
if (auth_data.len &&
chunk_equals(auth_data, recv_auth_data))<br>
{<br>
DBG1(DBG_IKE, "authentication of '%Y' with
%N successful<br>
",<br>
other_id, auth_method_names,
AUTH_PSK);<br>
authenticated = TRUE;<br>
}<br>
key_chunk++;<br>
<br>
The above test looking for the key match succeeds (otherwise the
other value would be incremented, and it is not.)<br>
<br>
Inserting further debugging code shows that while the length of
both of those structures (auth_data and recv_auth_data) are
identical (20 bytes) the contents are indeed not identical, nor is
there any part of them that are identical.<br>
<br>
If we're matching against %any for the PSK, however,<i><b> why do
we care what the MAC address is</b></i> (assuming the error
message is correct -- what's actually in that "auth_data" and
"recv_auth_data" structure at that point?)<br>
<br>
Again note that if I authenticate against a PSK for both left and
right it works -- that's all I changed on both client and server
and I get this:<br>
<br>
Apr 27 14:27:09 NewFS charon: 12[NET] received packet: from
208.54.70.231[26100] to 70.169.168.7[500] (400 bytes)<br>
Apr 27 14:27:09 NewFS charon: 12[ENC] parsed IKE_SA_INIT request 0
[ SA KE No N(NATD_S_IP) N(NATD_D_IP) ]<br>
Apr 27 14:27:09 NewFS charon: 12[IKE] 208.54.70.231 is initiating
an IKE_SA<br>
Apr 27 14:27:09 NewFS charon: 12[IKE] remote host is behind NAT<br>
Apr 27 14:27:09 NewFS charon: 12[IKE] sending cert request for
"C=US, ST=Florida, L=Niceville, O=Cuda Systems LLC, CN=Cuda
Systems LLC CA, <a moz-do-not-send="true"
class="moz-txt-link-abbreviated"
href="mailto:E=customer-service@cudasystems.net">E=customer-service@cudasystems.net</a>"<br>
Apr 27 14:27:09 NewFS charon: 12[ENC] generating IKE_SA_INIT
response 0 [ SA KE No N(NATD_S_IP) N(NATD_D_IP) CERTREQ
N(MULT_AUTH) ]<br>
Apr 27 14:27:09 NewFS charon: 12[NET] sending packet: from
70.169.168.7[500] to 208.54.70.231[26100] (337 bytes)<br>
Apr 27 14:27:10 NewFS charon: 14[NET] received packet: from
208.54.70.231[47985] to 70.169.168.7[4500] (332 bytes)<br>
Apr 27 14:27:10 NewFS charon: 14[ENC] parsed IKE_AUTH request 1 [
IDi AUTH CP(ADDR MASK DNS DNS NBNS NBNS VER) N(INIT_CONTACT)
N(MOBIKE_SUP) N(ESP_TFC_PAD_N) N(NON_FIRST_FRAG) SA TSi TSr ]<br>
Apr 27 14:27:10 NewFS charon: 14[CFG] looking for peer configs
matching 70.169.168.7[%any]...208.54.70.231[<a
moz-do-not-send="true" class="moz-txt-link-abbreviated"
href="mailto:karl@denninger.net">karl@denninger.net</a>]<br>
Apr 27 14:27:10 NewFS charon: 14[CFG] selected peer config 'BB10'<br>
Apr 27 14:27:10 NewFS charon: 14[IKE] authentication of '<a
moz-do-not-send="true" class="moz-txt-link-abbreviated"
href="mailto:karl@denninger.net">karl@denninger.net</a>' with
pre-shared key successful<br>
Apr 27 14:27:10 NewFS charon: 14[IKE] Auth_data: [20 {random
string}] recv_auth_data: [20 {same random string}]<br>
Apr 27 14:27:10 NewFS charon: 14[IKE] received
ESP_TFC_PADDING_NOT_SUPPORTED, not using ESPv3 TFC padding<br>
Apr 27 14:27:10 NewFS charon: 14[IKE] peer supports MOBIKE<br>
Apr 27 14:27:10 NewFS charon: 14[CFG] no IDr configured, fall back
on IP address<br>
Apr 27 14:27:10 NewFS charon: 14[IKE] authentication of
'70.169.168.7' (myself) with pre-shared key<br>
Apr 27 14:27:10 NewFS charon: 14[IKE] IKE_SA BB10[1] established
between 70.169.168.7[70.169.168.7]...208.54.70.231[<a
moz-do-not-send="true" class="moz-txt-link-abbreviated"
href="mailto:karl@denninger.net">karl@denninger.net</a>]<br>
Apr 27 14:27:10 NewFS charon: 14[IKE] scheduling reauthentication
in 10178s<br>
Apr 27 14:27:10 NewFS charon: 14[IKE] maximum IKE_SA lifetime
10718s<br>
Apr 27 14:27:10 NewFS charon: 14[IKE] peer requested virtual IP
%any<br>
Apr 27 14:27:10 NewFS charon: 14[CFG] assigning new lease to '<a
moz-do-not-send="true" class="moz-txt-link-abbreviated"
href="mailto:karl@denninger.net">karl@denninger.net</a>'<br>
Apr 27 14:27:10 NewFS charon: 14[IKE] assigning virtual IP
192.168.2.1 to peer '<a moz-do-not-send="true"
class="moz-txt-link-abbreviated"
href="mailto:karl@denninger.net">karl@denninger.net</a>'<br>
Apr 27 14:27:10 NewFS charon: 14[IKE] CHILD_SA BB10{1} established
with SPIs cb36c83d_i 39abf852_o and TS 0.0.0.0/0 ===
192.168.2.1/32 <br>
Apr 27 14:27:10 NewFS charon: 14[ENC] generating IKE_AUTH response
1 [ IDr AUTH CP(ADDR DNS) N(ESP_TFC_PAD_N) SA TSi TSr N(AUTH_LFT)
N(MOBIKE_SUP) N(ADD_4_ADDR) N(ADD_4_ADDR) ]<br>
Apr 27 14:27:10 NewFS charon: 14[NET] sending packet: from
70.169.168.7[4500] to 208.54.70.231[47985] (284 bytes)<br>
<br>
Ideas?<br>
<br>
<div class="moz-signature">-- <br>
-- Karl Denninger<br>
<a moz-do-not-send="true" href="http://market-ticker.org"><i>The
Market Ticker ®</i></a><br>
Cuda Systems LLC</div>
<br>
<fieldset class="mimeAttachmentHeader"></fieldset>
<br>
<pre wrap="">_______________________________________________
Users mailing list
<a class="moz-txt-link-abbreviated" href="mailto:Users@lists.strongswan.org">Users@lists.strongswan.org</a>
<a class="moz-txt-link-freetext" href="https://lists.strongswan.org/mailman/listinfo/users">https://lists.strongswan.org/mailman/listinfo/users</a></pre>
</blockquote>
<br>
<div class="moz-signature">-- <br>
-- Karl Denninger<br>
<a href="http://market-ticker.org"><i>The Market Ticker ®</i></a><br>
Cuda Systems LLC</div>
</body>
</html>