L2TP over IPSec, NAT Traversal, Native XP Client, ScreenOS 5.2 or 5.3

[Martin Schulman]

Some parts of this message have been removed. Learn more about Nabble's security policy.

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@...
http://qorbit.net/mailman/listinfo/nn

[Ernest Lau]

Some parts of this message have been removed. Learn more about Nabble's security policy.

Hi,

 

            Are you trying police based or Route based?

 

Ernest

 

---

From: Martin Schulman [mailto:mschulma@...]
Sent: Sunday, January 21, 2007 6:50 AM
To: nn@...
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@...
http://qorbit.net/mailman/listinfo/nn

[Martin Schulman]

Some parts of this message have been removed. Learn more about Nabble's security policy.

Hi Ernest -

 

    Policy based routing, per knowledge base article http://kb.juniper.net/KB4094.  Would a route-based VPN work?

 

                                                                Marty

 

----- Original Message -----

From: eclau-2006@...

To: mschulma@... ; nn@...

Sent: Tuesday, January 23, 2007 11:57 PM

Subject: RE: [nn] L2TP over IPSec, NAT Traversal, Native XP Client,ScreenOS 5.2 or 5.3

Hi,

 

            Are you trying police based or Route based?

 

Ernest

 

---

From: Martin Schulman [mailto:mschulma@...]
Sent: Sunday, January 21, 2007 6:50 AM
To: nn@...
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@...
http://qorbit.net/mailman/listinfo/nn

[Joe Loiacono]

Having trouble finding a CLI command (on NS50) that would show when the config was last updated. Anybody know how to get that?

Thanks!

Joe
_______________________________________________
nn mailing list
nn@...
http://qorbit.net/mailman/listinfo/nn

[Pavel Lunin]

get event

Having trouble finding a CLI command (on NS50) that would show when the config was last updated. Anybody know how to get that?

_______________________________________________
nn mailing list
nn@...
http://qorbit.net/mailman/listinfo/nn

[Troy Coulombe]

Some parts of this message have been removed. Learn more about Nabble's security policy.

Well, on an ISG 1K, it’s:::

SEAWA-COR-FW1-pri(M)-> get conf timestamp

317760647

 

 

 

--
TroyC
c: 425.299.8305
d: 206.792.2356

---

From: nn-bounces@... [mailto:nn-bounces@...] On Behalf Of Joe Loiacono
Sent: Friday, January 26, 2007 9:12 AM
To: nn@...
Subject: [nn] How to determine last update time for config

 

Having trouble finding a CLI command (on NS50) that would show when the config was last updated. Anybody know how to get that?

Thanks!

Joe

 

The information contained in this message may be privileged and/or confidential. If you are not the intended recipient, or responsible for delivering this message to the intended recipient, any review, forwarding, dissemination, distribution or copying of this communication or any attachment(s) is strictly prohibited. If you have received this message in error, please so notify the sender immediately, and delete it and all attachments from your computer and network.

 

_______________________________________________
nn mailing list
nn@...
http://qorbit.net/mailman/listinfo/nn

[Joe Loiacono]

"Troy Coulombe" <TCoulombe@...> wrote on 01/26/2007 02:01:11 PM:

> Well, on an ISG 1K, it’s:::
> SEAWA-COR-FW1-pri(M)-> get conf timestamp
> 317760647

Thanks. I found that, and I have a similar number. But how do you interpret the 317760647? If it's seconds, it's 3678 days worth :-)

_______________________________________________
nn mailing list
nn@...
http://qorbit.net/mailman/listinfo/nn