[Openswan Users] L2TP Windows XP Client with openswan

[Urmo]

Hi,

I have a hard time getting windows xp sp2 native vpn clients to connect my
openswan server. Here's the setup: most of the clients are usually behind
some nat (dudes working at home) and the idea is to give them access to the
office LAN. Openswan (latest release, 2.3.0) is compiled from sources and
runs on a debian distro with a custom built 2.6.8 kernel (ipsec enabled).
Server running openswan is also acting as a firewall, so it has public and
private NICs. Basically, whole thing looks like:

192.168.1.X(ClientXP) <-> 192.168.1.1/Some.Public.Address(Router, sometimes
fw) <-> Internet <->Some.Public.Address/192.168.0.1(Openswan on fw) <->
Office LAN

Clients are trying to connect using PSK. Firewall logs show, that nothing is
dropped but ipsec logs contain following:

:: Starting Pluto (Openswan Version 2.3.0 X.509-1.5.4 PLUTO_USES_KEYRR)
:: Setting port floating to on
:: port floating activate 1/1
:: including NAT-Traversal patch (Version 0.6c)

That tells me, t-nat and x.509 patches are ok.

:: Using Linux 2.6 IPsec interface code

It seems to use kernel ipsec stack

:: Added new connection mwxusers with policy PSK+ENCRYPT+TUNNEL+PFS
::
{192.168.0.0/24}===%any:17/%any...194.106.125.145---194.106.125.147:17/%any=
==192.168.0.0/24

My connection definition is loaded, I guess. Now the connecting client
(skipped many byte dumps):

:: "mwxusers"[1] 194.106.125.146:64978 #1: transition from state
STATE_MAIN_R0 to state STATE_MAIN_
R1
:: started looking for secret for 194.106.125.147->194.106.125.146 of kind
PPK_PSK
:: replace him to 0.0.0.0
:: actually looking for secret for 194.106.125.147->0.0.0.0 of kind PPK_PSK
:: 1: compared PSK 0.0.0.0 to 194.106.125.147 / 194.106.125.146 -> 2
:: 2: compared PSK 194.106.125.147 to 194.106.125.147 / 194.106.125.146 -> 6
:: best_match 0>6 best=0x81005e8 (line=10)
:: concluding with best_match=6 best=0x81005e8 (lineno=10)
:: "mwxusers"[1] 194.106.125.146:64978 #2: transition from state
STATE_MAIN_R0 to state STATE_MAIN_
R1
:: "mwxusers"[1] 194.106.125.146:64978 #1: NAT-Traversal: Result using
draft-ietf-ipsec-nat-t-ike-0
2/03: peer is NATed
:: "mwxusers"[1] 194.106.125.146:64978 #1: Main mode peer ID is ID_FQDN:
'@it.hq.mwx.ee'
:: refine_connection: starting with mwxusers
:: refine_connection: picking new best mwxusers (wild=15,
peer_pathlen=0/our=0)
:: offered CA: '%none'
:: switched from "mwxusers" to "mwxusers"
:: instantiated "mwxusers" for 194.106.125.146
:: hashing 196 bytes of SA
:: authentication succeeded
:: thinking about whether to send my certificate:
:: sendcert: CERT_ALWAYSSEND and I did not get a certificate request
::  so do not send cert.
:: "mwxusers"[2] 194.106.125.146:64978 #1: I did not send a certificate
because I do not have one.
:: complete state transition with STF_OK
:: "mwxusers"[2] 194.106.125.146:64978 #1: transition from state
STATE_MAIN_R2 to state STATE_MAIN_
R3
:: NAT-T: new mapping 194.106.125.146:64978/65042)
:: NAT-T: updating local port to 4500
:: NAT-T: using interface eth0:4500
:: "mwxusers"[2] 194.106.125.146:65042 #1: sent MR3, ISAKMP SA established
:: "mwxusers"[2] 194.106.125.146:65042 #1: retransmitting in response to
duplicate packet; already
STATE_MAIN_R3
:: sending 68 bytes for retransmit in response to duplicate through eth0 to
194.106.125.146:65042

And now the part I think is causing the problems:
:: our client is 194.106.125.147
:: our client protocol/port is 17/1701
:: find_client_connection starting with mwxusers
:: looking for 194.106.125.147/32:17/1701 -> 194.106.125.146/32:17/1701
:: concrete checking against sr#0 192.168.0.0/24 -> 192.168.0.0/24
:: match_id a=@it.hq.mwx.ee b=@it.hq.mwx.ee
:: match_id called with a=@it.hq.mwx.ee b=@it.hq.mwx.ee
:: trusted_ca called with a=(empty) b=(empty)
:: fc_try trying mwxusers:194.106.125.147/32:17/0 -> 194.106.125.146/32:17/0
vs mwxusers:192.16
8.0.0/24:17/0 -> 192.168.0.0/24:17/0
:: match_id a=@it.hq.mwx.ee b=194.106.125.146
:: match_id called with a=@it.hq.mwx.ee b=194.106.125.146
:: fc_try concluding with none [0]
:: fc_try mwxusers gives none
:: checking hostpair 192.168.0.0/24 -> 192.168.0.0/24 is found
:: match_id a=@it.hq.mwx.ee b=(none)
:: trusted_ca called with a=(empty) b=(empty)
:: fc_try trying mwxusers:194.106.125.147/32:17/0 -> 194.106.125.146/32:17/0
vs mwxusers:192.16
:: 8.0.0/24:17/0 -> 192.168.0.0/24:17/0
:: fc_try concluding with none [0]
:: match_id a=@it.hq.mwx.ee b=(none)
:: trusted_ca called with a=(empty) b=(empty)
:: fc_try_oppo trying mwxusers:194.106.125.147/32 -> 194.106.125.146/32 vs
mwxusers:192.168.0.0
/24 -> 192.168.0.0/24
:: fc_try_oppo concluding with none [0]
:: concluding with d = none
:: "mwxusers"[2] 194.106.125.146:65042 #1: cannot respond to IPsec SA
request because no connection
is known for
194.106.125.147:4500:17/%any...194.106.125.146:65042[@it.hq.mwx.ee]:17/%any
:: complete state transition with (null)
:: "mwxusers"[2] 194.106.125.146:65042 #1: sending encrypted notification
INVALID_ID_INFORMATION to
 194.106.125.146:65042


I googled anything I could imagine, last error message is quite common, the
answer to it varies and none of the suggested worked. Any ideas, what is
wrong here?

My last nonworking ipsec.conf was:

config setup
        interfaces="ipsec0=eth0"
        nat_traversal=yes
        virtual_private=%v4:10.0.0.0/8,%v4:172.16.0.0/12,%v4:192.168.0.0/16
        klipsdebug=all
        plutodebug=all

conn %default
        compress=yes
        disablearrivalcheck=no
        authby=secret

# VPN Users
conn    mwxusers
        left=194.106.125.147
        leftsubnet=192.168.0.0/255.255.255.0
        leftnexthop=194.106.125.145
        leftprotoport=17/%any
        right=%any
        rightid=%any
        rightsubnetwithin=192.168.0.0/24
        rightprotoport=17/%any
        pfs=yes
        keyingtries=0
        auto=add
        compress=no
        authby=secret