[Openswan dev] [Openswan Users] XL2TP/iPhone don't work because of wrong route/ip for UDP/1701 answer packets
wolfgang at linogate.de
Fri Jan 28 05:30:38 EST 2011
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: 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
> (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.
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.
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
More information about the Dev