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

[hiren joshi]

Hello,

While working on the issue I observe that: in programs/pluto/demux.c
'complete_state_transition' calls 'nat_traversal_change_port_lookup' only if
the state transition requested to send a reply packet.
As in aggressive mode, there will be no reply packet in transition from
STATE_AGGR_R1 to STATE_AGGR_R2, port floating will not happen for p1st
(phase-1 SA).

The following patch calls 'nat_traversal_change_port_lookup' unconditional
to sending reply packet.

--- demux.c.orig        Wed Aug 27 17:51:48 2008
+++ demux.c     Wed Aug 27 20:57:02 2008
@@ -2463,6 +2463,12 @@ complete_state_transition(struct msg_dig
            /* free previous transmit packet */
            freeanychunk(st->st_tpacket);

+#ifdef NAT_TRAVERSAL
+           if (nat_traversal_enabled) {
+                   nat_traversal_change_port_lookup(md, md->st);
+           }
+#endif
+
            /* if requested, send the new reply packet */
            if (smc->flags & SMF_REPLY)
            {
@@ -2480,12 +2486,6 @@ complete_state_transition(struct msg_dig
                clonetochunk(st->st_tpacket, md->reply.start
                    , pbs_offset(&md->reply), "reply packet");

-#ifdef NAT_TRAVERSAL
-               if (nat_traversal_enabled) {
-                   nat_traversal_change_port_lookup(md, md->st);
-               }
-#endif
-
                /* actually send the packet
                 * Note: this is a great place to implement "impairments"
                 * for testing purposes.  Suppress or duplicate the

Although the patch is not thourouly tested, now phase-1 SA sends
DPD_R_U_THERE_ACK using source port 4500, (as the NATbox has conntrack entry
for client:4500 -> server:4500) peer receives the packet, and connection
remains established.

Please share your views on this.

Thanks for your time.

Regards,
-hiren


On Tue, Jul 22, 2008 at 11:29 AM, hiren joshi <joshihirenn at gmail.com> wrote:

> Filed a bug report: http://bugs.xelerance.com/view.php?id=972
>
> Thanks for all your answers on this.
>
> -hiren
>
>
> On Tue, Jul 22, 2008 at 9:10 AM, Paul Wouters <paul at xelerance.com> wrote:
>
>> On Fri, 18 Jul 2008, hiren joshi wrote:
>>
>>  Is it the same for 2.4.12 also?
>>> I tested this on openswan-2.4.12.
>>>
>>
>> No, DPD on openswan 2.4.12 or 2.4.13 should work fine.
>>
>> Paul
>>
>>
>>  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/dev/attachments/20080827/44a4ce93/attachment.html