[strongSwan] Attempted PSK IKEv2 VPN w/BB10 - fails negotiation

Fri Apr 19 17:24:07 CEST 2013

On 4/19/2013 9:31 AM, Martin Willi wrote:
> Hi Karl,
>
>> 11[IKE] ignoring IKE_AUTH in established IKE_SA state
> 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.
>
>> It appears that the phone is either never seeing the AUTH response. 
> 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]https://lists.strongswan.org/pipermail/users/2013-March/008919.html
>

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:

(Notes interspersed; please advise if I have this interpretation right
or wrong...)

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)
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) ]
Apr 19 10:16:00 NewFS charon: 16[IKE] 208.54.35.243 is initiating an IKE_SA
Apr 19 10:16:00 NewFS charon: 16[IKE] remote host is behind NAT

This is true, the cellular connection is behind a NAT.

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) ]
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)
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)
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 ]
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]
Apr 19 10:16:00 NewFS charon: 15[CFG] selected peer config 'remote'
Apr 19 10:16:00 NewFS charon: 15[IKE] authentication of '107.97.114.108'
with pre-shared key successful

Key authenticated; the password presented is valid.

Apr 19 10:16:00 NewFS charon: 15[IKE] received
ESP_TFC_PADDING_NOT_SUPPORTED, not using ESPv3 TFC padding
Apr 19 10:16:00 NewFS charon: 15[IKE] peer supports MOBIKE
Apr 19 10:16:00 NewFS charon: 15[IKE] destroying duplicate IKE_SA for
peer '107.97.114.108', received INITIAL_CONTACT
Apr 19 10:16:00 NewFS charon: 15[CFG] lease 192.168.2.1 by
'107.97.114.108' went offline
Apr 19 10:16:00 NewFS charon: 15[IKE] authentication of '70.169.168.7'
(myself) with pre-shared key
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]
Apr 19 10:16:00 NewFS charon: 15[IKE] scheduling reauthentication in 10258s
Apr 19 10:16:00 NewFS charon: 15[IKE] maximum IKE_SA lifetime 10798s
Apr 19 10:16:00 NewFS charon: 15[IKE] peer requested virtual IP %any
Apr 19 10:16:00 NewFS charon: 15[CFG] reassigning offline lease to
'107.97.114.108'
Apr 19 10:16:00 NewFS charon: 15[IKE] assigning virtual IP 192.168.2.1
to peer '107.97.114.108'
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

We now have a tunnel established, and "ipsec status" confirms this with:

[root at NewFS /usr/local/etc]# ipsec status
Security Associations (1 up, 0 connecting):
      remote[2]: ESTABLISHED 3 minutes ago,
70.169.168.7[70.169.168.7]...208.54.35.243[107.97.114.108]
      remote{2}:  INSTALLED, TUNNEL, ESP in UDP SPIs: c8d77ac2_i 8043556c_o
      remote{2}:   192.168.1.0/24 === 192.168.2.1/32

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) ]
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)
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)
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 ]
Apr 19 10:16:11 NewFS charon: 09[IKE] received retransmit of request
with ID 1, retransmitting response
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)
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)
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 ]
Apr 19 10:16:20 NewFS charon: 11[IKE] received retransmit of request
with ID 1, retransmitting response
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)

We retry a few times, and the phone gives up.

Bah.

There IS a note in the Wiki related to FreeBSD which says:

    Limitations¶
    <http://wiki.strongswan.org/projects/strongswan/wiki/FreeBSD#Limitations>

  * Due to the lack of policy based routes, virtual IPs can not be used
    (client-side).
  * The kernel-pfroute interface lacks some final tweaks to fully
    support MOBIKE.

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.

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?

-- 
-- Karl Denninger
/The Market Ticker ®/ <http://market-ticker.org>
Cuda Systems LLC
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.strongswan.org/pipermail/users/attachments/20130419/f0268f0c/attachment.html>