NetScreen
[Top] [All Lists]

[nn] L2TP over IPSec, NAT Traversal, Native XP Client, ScreenOS 5.2 or 5

To: <nn@qorbit.net>
Subject: [nn] L2TP over IPSec, NAT Traversal, Native XP Client, ScreenOS 5.2 or 5.3
From: "Martin Schulman" <mschulma@isoc.org>
Date: Sun, 21 Jan 2007 09:49:42 -0500
Delivered-to: sp-com-lists@consult.net
Delivered-to: ns-list2@consult.net
Delivered-to: nn@qorbit.net
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
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>