[Openswan Users] Road Warrior behind NAT - Aggressive Mode: wrong NAT-T decision

[hiren joshi]

With the following patch, I was able to correct the NAT-T detection. However
the problem still persists.

--- programs/pluto/nat_traversal.c.orig Wed Nov 7 08:08:21 2007
+++ programs/pluto/nat_traversal.c Sat Jul 19 15:47:12 2008
@@ -267,7 +267,7 @@
        _natd_hash(st->st_oakley.hasher, hash_me
        , st->st_icookie, st->st_rcookie
        , &(md->iface->ip_addr)
-       , ntohs(md->iface->port));
+       , st->st_state == STATE_AGGR_R1 ? ntohs(IKE_UDP_PORT) :
ntohs(md->iface->port));

/**
* The others with sender IP & port

Digging the problem I found:

ipsec client 172.16.1.2 --- 172.16.1.1 NATbox 172.16.2.1 ---
172.16.2.2openswan-server

Client packets are being S-NATed by the NATbox (one to one IP mapping:
172.16.1.2 -> 172.16.2.1).

As the client initiates the connection, openswan detects: both are NATed.

NATbox generates connection tracking / conntrack entries:
1. client ip and port (172.16.1.2:500) <-> server ip and port (
172.16.2.2:500)
2. client ip and port (172.16.1.2:4500) <-> server ip and port (
172.16.2.2:4500)

openswan sends DPD_R_U_THERE packets using 500 as the source port and 4500
as the destination port.

As the NATbox is not having any conntrack entry for 172.16.1.2:4500 <->
172.16.2.2:500, it thinks the packet is for itself and rejects the packet.
Connection breaks after DPD timeout interval.

In main mode, it sends packets using 4500 as source and destination ports.

Thanks for your time.

-hiren

On Fri, Jul 18, 2008 at 8:24 PM, hiren joshi <joshihirenn at gmail.com> wrote:

> Is it the same for 2.4.12 also?
> I tested this on openswan-2.4.12.
>
>
> On Fri, Jul 18, 2008 at 3:12 AM, Paul Wouters <paul at xelerance.com> wrote:
>
>> On Thu, 17 Jul 2008, hiren joshi wrote:
>>
>>  openswan detects NAT-Traversal as "both are NATed" instead of "peer is
>>> NATed".
>>>
>>> Later on I receive,
>>> DPD: Serious: could not find newest phase 1 state
>>> DPD: Warning: received old or duplicate R_U_THERE
>>>
>>> After some time client breaks the connection due of not getting
>>> DPD_R_U_THERE_ACK
>>>
>>
>> DPD is broken on the 2.6.x series. We're looking into it.
>>
>> Paul
>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.openswan.org/pipermail/users/attachments/20080721/82dbeb4c/attachment.html