<html>
<head>
<meta content="text/html; charset=ISO-8859-1"
http-equiv="Content-Type">
</head>
<body text="#000000" bgcolor="#FFFFFF">
<br>
<div class="moz-cite-prefix">On 4/19/2013 10:24 AM, Karl Denninger
wrote:<br>
</div>
<blockquote cite="mid:51716197.9070803@denninger.net" type="cite">
<meta content="text/html; charset=ISO-8859-1"
http-equiv="Content-Type">
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 moz-do-not-send="true" 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
moz-do-not-send="true"
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 moz-do-not-send="true" href="http://market-ticker.org"><i>The
Market Ticker ®</i></a><br>
Cuda Systems LLC</div>
<br>
</blockquote>
<br>
I got the connection to come up <u><b>and I can go to my local IP
address</b></u>.<br>
<br>
However, any attempt to get out beyond there fails, including an
attempt to get to the DNS server on the inside address.<br>
<br>
This is what I have now in the logs:<br>
<br>
<br>
Apr 19 14:17:53 NewFS charon: 14[NET] received packet: from
208.54.90.249[38265] to 70.169.168.7[500] (400 bytes)<br>
Apr 19 14:17:53 NewFS charon: 14[ENC] parsed IKE_SA_INIT request 0 [
SA KE No N(NATD_S_IP) N(NATD_D_IP) ]<br>
Apr 19 14:17:53 NewFS charon: 14[IKE] 208.54.90.249 is initiating an
IKE_SA<br>
Apr 19 14:17:53 NewFS charon: 14[IKE] remote host is behind NAT<br>
Apr 19 14:17:53 NewFS charon: 14[ENC] generating IKE_SA_INIT
response 0 [ SA KE No N(NATD_S_IP) N(NATD_D_IP) N(MULT_AUTH) ]<br>
Apr 19 14:17:53 NewFS charon: 14[NET] sending packet: from
70.169.168.7[500] to 208.54.90.249[38265] (312 bytes)<br>
Apr 19 14:17:53 NewFS charon: 11[NET] received packet: from
208.54.90.249[18135] to 70.169.168.7[4500] (332 bytes)<br>
Apr 19 14:17:53 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 14:17:53 NewFS charon: 11[CFG] looking for peer configs
matching 70.169.168.7[%any]...208.54.90.249[<a class="moz-txt-link-abbreviated" href="mailto:karl@denninger.net">karl@denninger.net</a>]<br>
Apr 19 14:17:53 NewFS charon: 11[CFG] selected peer config 'remote'<br>
Apr 19 14:17:53 NewFS charon: 11[IKE] authentication of
'<a class="moz-txt-link-abbreviated" href="mailto:karl@denninger.net">karl@denninger.net</a>' with pre-shared key successful<br>
Apr 19 14:17:53 NewFS charon: 11[IKE] received
ESP_TFC_PADDING_NOT_SUPPORTED, not using ESPv3 TFC padding<br>
Apr 19 14:17:53 NewFS charon: 11[IKE] peer supports MOBIKE<br>
Apr 19 14:17:53 NewFS charon: 11[IKE] authentication of
'70.169.168.7' (myself) with pre-shared key<br>
Apr 19 14:17:53 NewFS charon: 11[IKE] IKE_SA remote[1] established
between
70.169.168.7[70.169.168.7]...208.54.90.249[<a class="moz-txt-link-abbreviated" href="mailto:karl@denninger.net">karl@denninger.net</a>]<br>
Apr 19 14:17:53 NewFS charon: 11[IKE] scheduling reauthentication in
9813s<br>
Apr 19 14:17:53 NewFS charon: 11[IKE] maximum IKE_SA lifetime 10353s<br>
Apr 19 14:17:53 NewFS charon: 11[IKE] peer requested virtual IP %any<br>
Apr 19 14:17:53 NewFS charon: 11[CFG] assigning new lease to
'<a class="moz-txt-link-abbreviated" href="mailto:karl@denninger.net">karl@denninger.net</a>'<br>
Apr 19 14:17:53 NewFS charon: 11[IKE] assigning virtual IP
192.168.2.1 to peer '<a class="moz-txt-link-abbreviated" href="mailto:karl@denninger.net">karl@denninger.net</a>'<br>
Apr 19 14:17:53 NewFS charon: 11[IKE] CHILD_SA remote{1} established
with SPIs c6b9c3fd_i 7f22007d_o and TS 192.168.1.0/24 ===
192.168.2.1/32 <br>
Apr 19 14:17:53 NewFS charon: 11[ENC] generating IKE_AUTH response 1
[ IDr AUTH CP(ADDR DNS 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 19 14:17:53 NewFS charon: 11[NET] sending packet: from
70.169.168.7[4500] to 208.54.90.249[18135] (284 bytes)<br>
<br>
And:<br>
[root@NewFS /usr/local/etc]# ipsec status<br>
Security Associations (1 up, 0 connecting):<br>
remote[1]: ESTABLISHED 20 seconds ago,
70.169.168.7[70.169.168.7]...208.54.90.249[<a class="moz-txt-link-abbreviated" href="mailto:karl@denninger.net">karl@denninger.net</a>]<br>
remote{1}: INSTALLED, TUNNEL, ESP in UDP SPIs: c6b9c3fd_i
7f22007d_o<br>
remote{1}: 192.168.1.0/24 === 192.168.2.1/32 <br>
<br>
A browse directly to 70.169.168.7, which has a running HTTP server
on it, returns the page. <br>
<br>
However, an attempt to connect to any other IP address (including
the DNS server on the internal address) fails.<br>
<br>
Obviously I have a routing problem -- any ideas on where to start
tracking this down? I see nothing in the netstat -r table at all.
The problem persists even if I assign the right pool out of part of
the class "C" that is otherwise on the LAN interface but unused and
tcpdump on either interface for the pool-assigned address returns
nothing. The firewall's verbose logging is not showing anything
blocked either.<br>
<br>
I cannot use leftfirewall as I do not have iptables (this is
FreeBSD) but I do have ipfw and can craft pretty-much whatever I
need -- so long as I know what I'm looking for. <br>
<br>
Hints (or places to look) appreciated :-)<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>