[Openswan Users] Openswan 2.6.32 / xl2tpd not working with Windows XP

[Wolfgang Nothdurft]

Am 08.01.2011 01:02, schrieb Jai Dhar:
> Paul,
> 
>> I dont try. Try a system update? :)
>>
> 
> Looks like up I'm up to date.
> 
>>
>> I am not sure what "internal IP" case is. You showed:
>>
>>>> STATE_QUICK_R2: IPsec SA established transport mode {ESP=>0x96a05f3a
>>>> <0x59e7df1b xfrm=3DES_0-HMAC_MD5 NATOA=192.168.1.108
>>>> NATD=192.168.1.1:4500 DPD=none}
>>
>> Since NATD and NATOA is not "none", this means UDP encapsulation is
>> negoatiated
>> and expected.
>>
> 
> The internal case is when I point my XP machine to the VPN servers
> address internally, as opposed to forcing to leave the local network
> by providing the external address (the routers address essentially).
> This is the log excerpt from the internal case:
> 
> Jan  6 07:29:12 viammc pluto[18392]: "L2TP-PSK-NAT"[1] 192.168.1.201
> #2: transition from state STATE_QUICK_R1 to state STATE_QUICK_R2
> Jan  6 07:29:12 viammc pluto[18392]: "L2TP-PSK-NAT"[1] 192.168.1.201
> #2: STATE_QUICK_R2: IPsec SA established transport mode
> {ESP=>0xcfcae264 <0x8776790e xfrm=3DES_0-HMAC_MD5 NATOA=none NATD=none
> DPD=none}
> 
> I guess both NATOA and NATD are none, meaning it is not encapsulating
> in UDP for this case, which makes sense...
> 
>> New connections should replace the older ones, so I am not sure why you see
>> this.
>>
> 
> It was the same thing the other user in the thread I pointed to saw,
> but that's minor compared to this...
> 
> Is there anything you else you can think of that will help me diagnose
> this? I'm not ready to write this off just yet, but not being able to
> XP in will kind of kill the whole Openswan route. Could it be anything
> configuration related? I'll post my config again:
> 
> # basic configuration
> config setup
>         # Do not set debug options to debug configuration issues!
>         # plutodebug / klipsdebug = "all", "none" or a combation from below:
>         # "raw crypt parsing emitting control klips pfkey natt x509 dpd private"
>         # eg:
>         # plutodebug="control parsing"
>         #
>         # enable to get logs per-peer
>         # plutoopts="--perpeerlog"
>         #
>         # Again: only enable plutodebug or klipsdebug when asked by a developer
>         #
>         # NAT-TRAVERSAL support, see README.NAT-Traversal
>         nat_traversal=yes
>         # exclude networks used on server side by adding %v4:!a.b.c.0/24
>         virtual_private=%v4:10.0.0.0/8,%v4:192.168.0.0/16,%v4:172.16.0.0/12
>         # OE is now off by default. Uncomment and change to on, to enable.
>         oe=off
>         # which IPsec stack to use. auto will try netkey, then klips then mast
>         protostack=auto
>         #plutostderrlog=/var/log/ipsec.log
>         plutodebug=none
>         syslog=daemon.err
> 
> 
> # Add connections here
> conn L2TP-PSK-NAT
>     rightsubnet=vhost:%priv,%no
>     also=L2TP-PSK-noNAT
> 
> conn L2TP-PSK-noNAT
>     authby=secret
>     pfs=no
>     auto=add
>     keyingtries=3
>     rekey=no
>     ikelifetime=8h
>     keylife=1h
>     type=transport
>     left=192.168.1.200
>     leftprotoport=17/1701
>     right=%any
>     rightprotoport=17/%any
>     #Windows
>     #rightsubnet=vhost:%priv,%no
> 
> Thanks,
> 
> J
>> Paul
>>
> 
> 
> 

Hi,

have a look at https://gsoc.xelerance.com/issues/601 , may be you have a
problem with bad UDP checksums and therefore the l2tp packets were
dropped from the kernel.

Regards
Wolfgang