<html>
<head>
<meta content="text/html; charset=UTF-8" http-equiv="Content-Type">
</head>
<body text="#000000" bgcolor="#FFFFFF">
On 4/19/2013 9:31 AM, Martin Willi wrote:<br>
<blockquote cite="mid:1366381865.2724.19.camel@martin" type="cite">
<pre wrap="">Hi Karl,
</pre>
<blockquote type="cite">
<pre wrap="">11[IKE] ignoring IKE_AUTH in established IKE_SA state
</pre>
</blockquote>
<pre wrap="">
That message is triggered by a bug, see [1]. It prevents charon as a
responder to retransmit the last IKE_AUTH message. Applying the patch at
[1] should fix that issue.
</pre>
<blockquote type="cite">
<pre wrap="">It appears that the phone is either never seeing the AUTH response.
</pre>
</blockquote>
<pre wrap="">
Because of that bug, only one is sent. Hard to say if your Z-10 is happy
if it gets the retransmit, but trying the patch should give some
insight.
If it doesn't work, your device is probably not happy about the IKE_AUTH
response at all.
Regards
Martin
[1]<a class="moz-txt-link-freetext" href="https://lists.strongswan.org/pipermail/users/2013-March/008919.html">https://lists.strongswan.org/pipermail/users/2013-March/008919.html</a>
</pre>
</blockquote>
<br>
Looks like there's something the phone doesn't like; with the
patches in (and on 5.0.3 rather than the 5.0.1 off the ports
collection) I get this, attempting connection over the cellular
network:<br>
<br>
(Notes interspersed; please advise if I have this interpretation
right or wrong...)<br>
<br>
Apr 19 10:16:00 NewFS charon: 16[NET] received packet: from
208.54.35.243[37785] to 70.169.168.7[500] (400 bytes)<br>
Apr 19 10:16:00 NewFS charon: 16[ENC] parsed IKE_SA_INIT request 0 [
SA KE No N(NATD_S_IP) N(NATD_D_IP) ]<br>
Apr 19 10:16:00 NewFS charon: 16[IKE] 208.54.35.243 is initiating an
IKE_SA<br>
Apr 19 10:16:00 NewFS charon: 16[IKE] remote host is behind NAT<br>
<br>
This is true, the cellular connection is behind a NAT.<br>
<br>
Apr 19 10:16:00 NewFS charon: 16[ENC] generating IKE_SA_INIT
response 0 [ SA KE No N(NATD_S_IP) N(NATD_D_IP) N(MULT_AUTH) ]<br>
Apr 19 10:16:00 NewFS charon: 16[NET] sending packet: from
70.169.168.7[500] to 208.54.35.243[37785] (312 bytes)<br>
Apr 19 10:16:00 NewFS charon: 15[NET] received packet: from
208.54.35.243[53670] to 70.169.168.7[4500] (316 bytes)<br>
Apr 19 10:16:00 NewFS charon: 15[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 19 10:16:00 NewFS charon: 15[CFG] looking for peer configs
matching 70.169.168.7[%any]...208.54.35.243[107.97.114.108]<br>
Apr 19 10:16:00 NewFS charon: 15[CFG] selected peer config 'remote'<br>
Apr 19 10:16:00 NewFS charon: 15[IKE] authentication of
'107.97.114.108' with pre-shared key successful<br>
<br>
Key authenticated; the password presented is valid.<br>
<br>
Apr 19 10:16:00 NewFS charon: 15[IKE] received
ESP_TFC_PADDING_NOT_SUPPORTED, not using ESPv3 TFC padding<br>
Apr 19 10:16:00 NewFS charon: 15[IKE] peer supports MOBIKE<br>
Apr 19 10:16:00 NewFS charon: 15[IKE] destroying duplicate IKE_SA
for peer '107.97.114.108', received INITIAL_CONTACT<br>
Apr 19 10:16:00 NewFS charon: 15[CFG] lease 192.168.2.1 by
'107.97.114.108' went offline<br>
Apr 19 10:16:00 NewFS charon: 15[IKE] authentication of
'70.169.168.7' (myself) with pre-shared key<br>
Apr 19 10:16:00 NewFS charon: 15[IKE] IKE_SA remote[2] established
between 70.169.168.7[70.169.168.7]...208.54.35.243[107.97.114.108]<br>
Apr 19 10:16:00 NewFS charon: 15[IKE] scheduling reauthentication in
10258s<br>
Apr 19 10:16:00 NewFS charon: 15[IKE] maximum IKE_SA lifetime 10798s<br>
Apr 19 10:16:00 NewFS charon: 15[IKE] peer requested virtual IP %any<br>
Apr 19 10:16:00 NewFS charon: 15[CFG] reassigning offline lease to
'107.97.114.108'<br>
Apr 19 10:16:00 NewFS charon: 15[IKE] assigning virtual IP
192.168.2.1 to peer '107.97.114.108'<br>
Apr 19 10:16:00 NewFS charon: 15[IKE] CHILD_SA remote{2} established
with SPIs c8d77ac2_i 8043556c_o and TS 192.168.1.0/24 ===
192.168.2.1/32 <br>
<br>
We now have a tunnel established, and "ipsec status" confirms this
with:<br>
<br>
[root@NewFS /usr/local/etc]# ipsec status<br>
Security Associations (1 up, 0 connecting):<br>
remote[2]: ESTABLISHED 3 minutes ago,
70.169.168.7[70.169.168.7]...208.54.35.243[107.97.114.108]<br>
remote{2}: INSTALLED, TUNNEL, ESP in UDP SPIs: c8d77ac2_i
8043556c_o<br>
remote{2}: 192.168.1.0/24 === 192.168.2.1/32 <br>
<br>
Apr 19 10:16:00 NewFS charon: 15[ENC] generating IKE_AUTH response 1
[ IDr AUTH CP(ADDR) N(ESP_TFC_PAD_N) SA TSi TSr N(AUTH_LFT)
N(MOBIKE_SUP) N(ADD_4_ADDR) N(ADD_4_ADDR) ]<br>
Apr 19 10:16:00 NewFS charon: 15[NET] sending packet: from
70.169.168.7[4500] to 208.54.35.243[53670] (268 bytes)<br>
Apr 19 10:16:11 NewFS charon: 09[NET] received packet: from
208.54.35.243[53670] to 70.169.168.7[4500] (316 bytes)<br>
Apr 19 10:16:11 NewFS charon: 09[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 19 10:16:11 NewFS charon: 09[IKE] received retransmit of request
with ID 1, retransmitting response<br>
Apr 19 10:16:11 NewFS charon: 09[NET] sending packet: from
70.169.168.7[4500] to 208.54.35.243[53670] (268 bytes)<br>
Apr 19 10:16:20 NewFS charon: 11[NET] received packet: from
208.54.35.243[53670] to 70.169.168.7[4500] (316 bytes)<br>
Apr 19 10:16:20 NewFS charon: 11[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 19 10:16:20 NewFS charon: 11[IKE] received retransmit of request
with ID 1, retransmitting response<br>
Apr 19 10:16:20 NewFS charon: 11[NET] sending packet: from
70.169.168.7[4500] to 208.54.35.243[53670] (268 bytes)<br>
<br>
We retry a few times, and the phone gives up.<br>
<br>
Bah.<br>
<br>
There IS a note in the Wiki related to FreeBSD which says:<br>
<br>
<h2 style="font-family: 'Trebuchet MS', Verdana, sans-serif;
padding: 2px 10px 1px 0px; margin: 0px 0px 10px; color: rgb(85,
85, 85); font-size: 16px; font-style: normal; font-variant:
normal; letter-spacing: normal; line-height: 16.1875px; orphans:
auto; text-align: start; text-indent: 0px; text-transform: none;
white-space: normal; widows: auto; word-spacing: 0px;
-webkit-text-size-adjust: auto; -webkit-text-stroke-width: 0px;
background-color: rgb(255, 255, 255);">Limitations<a
href="http://wiki.strongswan.org/projects/strongswan/wiki/FreeBSD#Limitations"
class="wiki-anchor" style="color: rgb(138, 0, 32);
text-decoration: none; display: inline; margin-left: 6px;
font-weight: bold;">¶</a></h2>
<ul style="margin-bottom: 1em; color: rgb(54, 0, 12); font-family:
Verdana, sans-serif; font-size: 11px; font-style: normal;
font-variant: normal; font-weight: normal; letter-spacing: normal;
line-height: 16.1875px; orphans: auto; text-align: start;
text-indent: 0px; text-transform: none; white-space: normal;
widows: auto; word-spacing: 0px; -webkit-text-size-adjust: auto;
-webkit-text-stroke-width: 0px; background-color: rgb(255, 255,
255);">
<li>Due to the lack of policy based routes, virtual IPs can not be
used (client-side).</li>
<li>The kernel-pfroute interface lacks some final tweaks to fully
support MOBIKE.</li>
</ul>
<br>
Do either of these apply? MOBIKE is claimed to be requested, but if
I'm reading this right the virtual IP problem is only applicable to
CLIENTS, so that should be ok.<br>
<br>
To test with Windows 7 against IKEv2 (to eliminate server problems)
do I need to generate certs and such along with a means to handle
MSCHAP? It appears so from the docs; is there a "cookbook" for
setting that up?<br>
<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>