[strongSwan] Attempted PSK IKEv2 VPN w/BB10 - negotiation works, now routing problems

Karl Denninger karl at denninger.net
Fri Apr 19 22:01:47 CEST 2013 

On 4/19/2013 10:24 AM, Karl Denninger wrote:
> 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
>

I got the connection to come up _*and I can go to my local IP address*_.

However, any attempt to get out beyond there fails, including an attempt
to get to the DNS server on the inside address.

This is what I have now in the logs:


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)
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) ]
Apr 19 14:17:53 NewFS charon: 14[IKE] 208.54.90.249 is initiating an IKE_SA
Apr 19 14:17:53 NewFS charon: 14[IKE] remote host is behind NAT
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) ]
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)
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)
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 ]
Apr 19 14:17:53 NewFS charon: 11[CFG] looking for peer configs matching
70.169.168.7[%any]...208.54.90.249[karl at denninger.net]
Apr 19 14:17:53 NewFS charon: 11[CFG] selected peer config 'remote'
Apr 19 14:17:53 NewFS charon: 11[IKE] authentication of
'karl at denninger.net' with pre-shared key successful
Apr 19 14:17:53 NewFS charon: 11[IKE] received
ESP_TFC_PADDING_NOT_SUPPORTED, not using ESPv3 TFC padding
Apr 19 14:17:53 NewFS charon: 11[IKE] peer supports MOBIKE
Apr 19 14:17:53 NewFS charon: 11[IKE] authentication of '70.169.168.7'
(myself) with pre-shared key
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[karl at denninger.net]
Apr 19 14:17:53 NewFS charon: 11[IKE] scheduling reauthentication in 9813s
Apr 19 14:17:53 NewFS charon: 11[IKE] maximum IKE_SA lifetime 10353s
Apr 19 14:17:53 NewFS charon: 11[IKE] peer requested virtual IP %any
Apr 19 14:17:53 NewFS charon: 11[CFG] assigning new lease to
'karl at denninger.net'
Apr 19 14:17:53 NewFS charon: 11[IKE] assigning virtual IP 192.168.2.1
to peer 'karl at denninger.net'
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
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) ]
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)

And:
[root at NewFS /usr/local/etc]# ipsec status
Security Associations (1 up, 0 connecting):
      remote[1]: ESTABLISHED 20 seconds ago,
70.169.168.7[70.169.168.7]...208.54.90.249[karl at denninger.net]
      remote{1}:  INSTALLED, TUNNEL, ESP in UDP SPIs: c6b9c3fd_i 7f22007d_o
      remote{1}:   192.168.1.0/24 === 192.168.2.1/32

A browse directly to 70.169.168.7, which has a running HTTP server on
it, returns the page. 

However, an attempt to connect to any other IP address (including the
DNS server on the internal address) fails.

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.

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. 

Hints (or places to look) appreciated :-)

-- 
-- 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/2e937ffd/attachment.html>

More information about the Users mailing list