[Openswan Users] Problem with NAT-T roadwarrior on Openswan 2.6.15dr2

[Paul Wouters]

On Wed, 8 Oct 2008, Julien DELEAN wrote:

I will be looking into this issue and do some testing with it.

Paul

> Date: Wed, 8 Oct 2008 12:38:52 +0200
> From: Julien DELEAN <julien.delean at peer2me.com>
> Cc: users at openswan.org
> To: Daniel R. Koehler <dan at warp-7.com>
> Subject: Re: [Openswan Users] Problem with NAT-T roadwarrior on Openswan
>     2.6.15dr2
> 
> 2008/10/7 Daniel R. Koehler <dan at warp-7.com>
> 
>
>  I wrote severals message about Vista rekeying problem. Some answers
> but
> without solution.
> So, I decided to study pluto source code in order to write a patch to
> workaround this issue.
> We are using Openswan 2.4.8 and 2.4.12 in production environment.
> 
> But I think that is better to study 2.6.x source code...
> 
> So I decided to try to upgrade my Openswan Test Box. And I've got a
> problem
> with NAT-T roadwarriors. IPSec connection seems to be ok but L2TP
> doesn't
> work (L2TP servers can't answer to New Session) and I found a difference
> in
> IPSec Policy for an Win2k roadwarrior...
> 
> With 2.4.8, I've got :
> # ip xfrm policy
> src 82.241.242.240/32 dst 88.191.42.90/32 proto udp sport 1701
>         dir in priority 2080
>         tmpl src 0.0.0.0 dst 0.0.0.0
>                
> proto esp reqid 16401 mode transport
> src 88.191.42.90/32 dst 82.241.242.240/32 proto udp dport 1701
>         dir out priority 2080
>         tmpl src 0.0.0.0 dst 0.0.0.0
>                
> proto esp reqid 16401 mode transport
> 
> With 2.6.15dr2 (same ipsec.conf, same roadwarrior : only a "make
> programs
> install"), I've got :
> # ip xfrm policy
> src 192.168.0.11/32 dst 88.191.42.90/32 proto udp
>         dir in priority 2080
>         tmpl src 0.0.0.0 dst 0.0.0.0
>                
> proto esp reqid 16405 mode transport
> src 88.191.42.90/32 dst 192.168.0.11/32 proto udp
>         dir out priority 2080
>         tmpl src 0.0.0.0 dst 0.0.0.0
>                
> proto esp reqid 16405 mode transport
> 
> 
> It seems that Policy is based on Virtual IP and not Public IP and sport
> and
> dport are not set anymore.
> It could explain why my L2TP servers can't respond to new clients...
> 
> I don't know what to do... Any idea ?
> 
> 
>
>       Did you ever find a solution to this problem?  I have noticed
>       the exact same thing.  I use any of the 2.4.X versions of
>       Openswan, and my conn's work fine for my roadwarrior
>       connections.  Then, I uninstall the 2.4.X version, and
>       compile and install a 2.5.X or a 2.6.X version, and l2tp no
>       longer works.  After the IPSec connection is established,
>       lt2pd just times out waiting for responses on port 1701.  It
>       finally gives up and the IPSec connection is deleted. 
>       Windows XP clients get an "Error 678 - The server did not
>       respond" or something like that.  Surely someone else has
>       noticed this as well, and has a solution to it?
> 
> 
> The only solution that I've found was to keep my 2.4.X Openswan. :(
> But maybe is your problem different... Do you notice the same thing about
> IPSec Policy (check with "ip xfrm policy" cmd) ? Is Policies based on
> Virtual IP (without sport or dport) ?
> I didn't try last release (2.6.18).
> 
> Regards
> 
> Julien DELEAN
> 
>