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

Wolfgang Nothdurft wolfgang at linogate.de
Tue Feb 8 04:50:34 EST 2011


Am 28.01.2011 11:30, schrieb 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.

Hi,

i have reported this issue at https://gsoc.xelerance.com/issues/1204 and
added a new overworked patch.

Wolfgang


More information about the Dev mailing list