NetScreen
[Top] [All Lists]

Re: [nn] L2TP over IPSec, NAT Traversal, Native XP Client, ScreenOS 5.2

To: "'Martin Schulman'" <mschulma@isoc.org>, <nn@qorbit.net>
Subject: Re: [nn] L2TP over IPSec, NAT Traversal, Native XP Client, ScreenOS 5.2 or 5.3
From: "Ernest Lau" <eclau-2006@elau.net>
Date: Tue, 23 Jan 2007 20:57:29 -0800
Delivered-to: sp-com-lists@consult.net
Delivered-to: ns-list2@consult.net
Delivered-to: nn@qorbit.net
In-reply-to: <00d601c73d6b$630a8fa0$6a0211ac@Acer8104>
List-archive: <http://www.qorbit.net/nn>
List-help: <mailto:nn-request@qorbit.net?subject=help>
List-id: "Netscreen mailing list for netscreen admins." <nn.qorbit.net>
List-post: <mailto:nn@qorbit.net>
List-subscribe: <http://qorbit.net/mailman/listinfo/nn>, <mailto:nn-request@qorbit.net?subject=subscribe>
List-unsubscribe: <http://qorbit.net/mailman/listinfo/nn>, <mailto:nn-request@qorbit.net?subject=unsubscribe>
Sender: nn-bounces@qorbit.net
Thread-index: Acc9bWzV+xzufE2eQT6hxuoutjGs2QCBqupw

Hi,

 

            Are you trying police based or Route based?

 

Ernest

 


From: Martin Schulman [mailto:mschulma@isoc.org]
Sent: Sunday, January 21, 2007 6:50 AM
To: nn@qorbit.net
Subject: [nn] L2TP over IPSec, NAT Traversal, Native XP Client,ScreenOS 5.2 or 5.3

 

Hello -

 

    Been trying to use L2TP over IPsec with Nat-T between the native Windows XP SP 2 client and a 5.2 ScreenOS 5GT.  Phase 1 negotiation succeeds, but the following snippet of output from "debug ike all" (that repeats several times) shows where Phase 2 fails:

 

## 08:17:13 : IKE<68.100.65.203  > Recv*: [HASH] [SA] [NONCE] [ID] [ID] [NAT_OA]
## 08:17:13 : IKE<68.100.65.203  >   extract payload (352):
## 08:17:13 : IKE<68.100.65.203  >   QM in state OAK_QM_SA_ACCEPT.
## 08:17:13 : IKE<68.100.65.203  > ERROR: Cannot handle this id type, 2!
## 08:17:13 : IKE<0.0.0.0        > Initiator ID Payload processing failed!!
## 08:17:13 : IKE<68.100.65.203  > Error: No phase 2 proxy id from peer, message_id<d67aedb0>.
## 08:17:13 : IKE<68.100.65.203  >   oakley_process_quick_mode():exit

 

    It is not an issue with certificates - when NAT Traversal is disabled the SA comes up for a minute according to both the IP Security Monitor in the Windows MMC and "get sa stat" on the Netscreen.  In fact, the latter showed a few hundred bytes arriving on the SA in 5 or 10 second intervals for a while - presumably the L2TP frames that the Netscreen cannot respond to because it doesn't have the correct route entry for the response.  For comparison, the debug lines corresponding to the above show that the NAT information isn't expected:

 

## 08:18:49 : IKE<68.100.65.203  > Recv*: [HASH] [SA] [NONCE] [ID] [ID]
## 08:18:49 : IKE<68.100.65.203  >   extract payload (1272):
## 08:18:49 : IKE<68.100.65.203  >   QM in state OAK_QM_SA_ACCEPT.
## 08:18:49 : IKE<68.100.65.203  >   receive init proxy id type ID_IPV4_ADDR with mask 0: force mask to all 1.
## 08:18:49 : IKE<68.100.65.203  >   receive resp prxoy id type ID_IPV4_ADDR with mask 0: force mask to all 1.
## 08:18:49 : IKE<68.100.65.203  >   Start by finding matching member SA (verify -1/-1)

 

It continues on and brings up the SA.

 

    Is there some way I can get this to work on the box with 5.2?  Will upgrading to a version of 5.3 solve it?  Using the VPN client is not an option, and the solution must work for users with and without NAT.  Apologies if this has been addressed, but my searches only found definitive answers for ScreenOS 5.1 and earlier, but left open a little hope afterwards.

 

                                                                                    Marty

 

_______________________________________________
nn mailing list
nn@qorbit.net
http://qorbit.net/mailman/listinfo/nn
<Prev in Thread] Current Thread [Next in Thread>