Subject: NAT Issues for L2TP

From: "Naushad K" <[email-masked]>
Date: Tue, 30 Oct 2001 19:47:19 +0530

Hi
    I am sending this mail again since figure in my earlier mail was somehow
    misaligned.
   Sorry  for the inconvenience.

    I have a scenario like this:

   LAC1    ----|
                       |--------  < NAT > -- (INTERNET)  -- <LNS >
   LAC2   -----|

      Two LACs  behind a NAT contacting same LNS. Connection is plain L2TP
and not L2TP over IpSec.  Here NAT  translates the request from the LACs to
NAT IP address and a new port  number. So LNS receives two tunnel requests
from same machine but different ports. This scenario works fine if both LAC1
and
LAC2 are having different Tunnel IDs. Suppose, if both LAC1 and LAC2 choose
same Tunnel IDs. Then will LNS accept the first request and will consider
the
second request as a duplicate one ? (pls correct if I am wrong).

So in this case,

 1. Does the LNS  should consider the source port number also to find
whether a tunnel is
     duplicate one?

 2. If not then Nat server can look into L2tp data an edit it(i,e Tunnel Id)
and make
     sure that  there is no duplicate tunnels to same LNS. But it is
difficult, since Assigned
     Tunnel Id can be send as hidden.

One more case,

   Suppose a L2TP implementation chooses to respond to a SCCRQ from a port
different
from 1701 (say 5000). Then can the implementation has to send ZLB Ack(for
SCCRQ) from
1701 and the SCCRP from 5000? Or ZLB Ack should also be sent from 5000 port?

Thanks
Naushad

---

From: Ignacio Goyret <[email-masked]>
Date: Tue, 30 Oct 2001 09:08:33 -0800

At 07:47 PM 10/30/01 +0530, Naushad K wrote:
>and LAC2 are having different Tunnel IDs. Suppose, if both LAC1 and LAC2
>choose same Tunnel IDs. Then will LNS accept the first request and will
>consider the second request as a duplicate one ? (pls correct if I am wrong).

If the LNS doesn't accept the second tunnel, it has a bug. Tunnel IDs are
unique only by remote IP address/port number.

> 1. Does the LNS  should consider the source port number also to find

Yes.

>     Tunnel Id can be send as hidden.

It could do this, but it is unnecessary.

>different from 1701 (say 5000). Then can the implementation has to send
>ZLB Ack(for SCCRQ) from 1701 and the SCCRP from 5000? Or ZLB Ack should
>also be sent from 5000 port?

If the ZLB Ack is sent from 1701, you will be locked to 1701 on most
implementations I've seen that follow RFC2661, section 8.1 strictly,
since that ZLB Ack would constitute your reply.

BTW, there is no need for the ZLB Ack after an SCCRQ: you will soon send
either an SCCRP or an StopCCN. They can carry the Ns just as well.