[Openswan dev] [Openswan Users] XL2TP/iPhone don't work because of wrong route/ip for UDP/1701 answer packets

[Wolfgang Nothdurft]

Am 18.01.2011 15:52, schrieb Paul Wouters:
> On Tue, 18 Jan 2011, Wolfgang Nothdurft wrote:
> 
>> Now, since one or two weeks, it proposes that it is behind nat (see
>> l2tp_iphone_new.txt), but sends the l2tp 1701/udp packets anyway with
>> the public ip through the ipsec tunnel. Because openswan only insert a
>> route to the proposed local ip through the tunnel the answer packets
>> were routed direct over the default route.
>>
>> The l2tpd gets only the repeatedly incoming request and logs:
>>
>> Jan 18 11:27:44 riab l2tpd[4229]: control_finish: Peer requested tunnel
>> 21 twice, ignoring second one.
> 
> Ohh. I did not realise that was the actual problem in these scenarios...
> 
>> Removing the rightsubnet parameter from the config let the iPhone
>> connect, but than all other clients (Win7, etc) who proposes correctly
>> are left out.
> 
> Can you try with one conn without rightsubnet and one conn with
> rightsubnet=vhost:%priv
> (without the %no). I wonder if that's what is causing this?
> 
> This might be a NAT-OA related bug on our end?
> 
>> Does anyone else see this problem?
> 
> Yes, we see reports of these regularly, but I hadn't realised the problem
> until you described it above.
> 
> Paul
> 

Hi,

to work around the problem I have written the attached patch.

If pluto detects a natted MacOSX client, he uses the remoteaddr as the
remote subnet to ignore the proposed local net.
Now there is a route with the official ip address to the ipsec device
and the l2tp packets were routed correctly.

May be there are additional parameters to query before applying the hack.

I don't know if the real problem is earlier when the natoa was
interpreted or something, but with this hack iPhone and MacOSX clients
can connect again.

Wolfgang
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: openswan-2.6.29-macosx-natoa-bug.patch
Url: http://lists.openswan.org/pipermail/dev/attachments/20110128/d79d1f05/attachment.pl