Screen OS

Hello,

 

i am pretty newbie at Juniper. I already searched the other threads but did not found) or an unsolvable issue.

In this case, i would like to build a Dial-up VPN client-to-side using ANY PROTOCOL [IPsec/L2TP] cause my purpose is only want to see how the client-side is connected to server side.

 

i searched on KB Juniper[s], i found but still...confused to how the config is working.

 

So i config based on those KB's and here's the attachment i've got, also the error log

 

if there was a mistake or any kind of what i missing , please let me know.

 

Thanks for your attention

This indicates that there is a mismatch between the Shrew VPN configuration and the firewall configuration.  I would recommend opening a case with JTAC to help troubleshoot the issue, as it generally requires troubleshooting that might contain information that you wouldn't want to have publically available.

dear rseibert,

 

Is this the correct KB that i looking for? http://kb.juniper.net/InfoCenter/index?page=content&id=KB9221&actp=search&viewlocale=en_US&searchid=1234893024655

 

 

i assume that's the correct one, so i will post the progress very soon. Thanks for your advise

 

 

 

You should verify the gateway settings on both Shrew and the the firewall.  See the details in kb9238.  Yours is an aggressive mode vpn.

 

http://kb.juniper.net/InfoCenter/index?page=content&id=KB9238

 

• Message:  IKE <ip_addr> Phase 1: Rejected an initial Phase 1 packet from an unrecognized peer gateway. 
  

  Meaning:  The responder did not recognize the incoming request as originating from a valid gateway peer. 
  Action:      On the responder, confirm the following IKE gateway configuration settings are correct:
  

  • The Static IP Address specified for the Remote Gateway is correct.
  • The Peer ID specified for the Remote Gateway is correct.
  • The outgoing interface is correct.  (Unfortunately, you cannot change the IKE Gateway's outgoing interface.  Create a new IKE Gateway that points to the correct outgoing interface and then change the AutoKey IKE so that it matches the new gateway.)

Dear spuluka, rseibet

 

i follow your instruction as your mentioned above, and now i pass the phase1 successfully [Big thanks]

but now i got new issue in phase 2, the error log said 

 

"Rejected an IKE packet on ethernet0/0 from [IP NETSCREEN] to [IP PUBLIC] with cookies d1297946e596726f and c628cffc7eb26ae8 because A Phase 2 packet arrived while XAuth was still pending."

 

i tried to analyze there was a mismatch IKE or encryption between vpn client-server. but i still dunno where should i start to troubleshoot.

 

here's the attachment of my lovely error log and message error on vpn-client

Check to make sure you have xauth enabled on both the client and firewall.

dear rseibert

How do i know to check xauth enabled or not from both side? By netscreen monitor or re-check my config? Sorry for the silly question.

UPDATE !!!!

 

i still dont get a point what caused "A Phase 2 packet arrived while XAuth was still pending".

 

got several attachment this time, hope you guys could find what i should do

 

Thanks.

Are you trying to use the same xauth user to log in with from multiple clients?  I see from the event log that one user logs in, but then is disconnected because another user with the same xauth logs in.  You can use the same IKE id (fqdn, u-fqdn, ip, etc), but NOT the same xauth username.  This is how the firewall distinguses between the different users.  Also, if you are still having an issue after using a different xauth user, please run a "debug ike detail".  This is the debugs for VPNs.

Dear rseibert,

 

Sorry for late update, yes indeed i attempt to connect with dual user, i do understand of what you had explain to me.

But my main issue is on phase 2, based on the error log.

 

2014-04-28 17:37:47infoIKE 39.251.67.192 Phase 1: Retransmission limit has been reached.

2014-04-28 17:37:07infoIKE 39.251.67.192: XAuth login was passed for gateway Dialup_GW, username uservpn1, retry: 0, Client IP Addr 0.0.0.0, IPPool name: , Session-Timeout: 0s, Idle-Timeout: 0s.

2014-04-28 17:37:07infoIKE 39.251.67.192: XAuth login was refreshed for username uservpn1 at 0.0.0.0/0.0.0.0.

2014-04-28 17:37:00infoRejected an IKE packet on ethernet0/0 from 39.251.67.192:37203 to xxx.xxx.xx.xx:4500 with cookies 38cb1889542a5932 and e4613fca34d940b4 because A Phase 2 packet arrived while XAuth was still pending.

2014-04-28 17:36:59infoIKE 39.251.67.192 phase 1:The symmetric crypto key has been generated successfully.

2014-04-28 17:36:59infoIKE 39.251.67.192 Phase 1: Responder starts AGGRESSIVE mode negotiations.

2014-04-28 17:36:59infoIKE 39.251.67.192 Phase 1: Completed Aggressive mode negotiations with a 28800-second lifetime.

2014-04-28 17:36:59infoIKE 39.251.67.192 Phase 1: Completed for user ipsecvpn.

2014-04-28 17:36:59infoIKE<39.251.67.192> Phase 1: IKE responder has detected NAT in front of the remote device.

2014-04-28 17:36:59infoIKE<39.251.67.192> Phase 1: IKE responder has detected NAT in front of the local device.

2014-04-28 17:36:52infoIKE 39.251.67.192 phase 1:The symmetric crypto key has been generated successfully.

2014-04-28 17:36:52infoIKE 39.251.67.192 Phase 1: Responder starts AGGRESSIVE mode negotiations.

 

 

Xauth occurs between phase 1 and phase 2.  The message that you are receiving indicates that the client is attempting to continue with phase 2 before xauth has completed.  This will sometimes happen if you have two users using the same xauth name trying to connect at the same time.  This can also happen if the packets come in out of order.

Dear rseibert, spuluka

 

Thanks for your help!! Really appreciated !

I found my mistake and there was a mismatch destination address. Oh my God, big thanks!

here's my successfull log.

 

2014-04-30 15:29:45	info	IKE 114.121.152.104 Phase 2 msg ID f8cec688: Completed negotiations with SPI 2f0c1d9d, tunnel ID 2, and lifetime 3600 seconds/0 KB.
2014-04-30 15:29:45	info	IKE 114.121.152.104 phase 2:The symmetric crypto key has been generated successfully.
2014-04-30 15:29:41	info	IKE 114.121.152.104 Phase 2 msg ID f8cec688: Responded to the peer's first message.
2014-04-30 15:28:55	info	System configuration saved by netscreen via web from host 192.168.1.10 to 192.168.1.1:80 by netscreen.
2014-04-30 15:28:55	notif	Policy (10, Untrust->Trust, Any->Kantor_Net,ANY, Permit) was modified by netscreen via web from host 192.168.1.10 to 192.168.1.1:80.
2014-04-30 15:28:55	notif	Policy (10, Untrust->Trust, Any->Kantor_Net,ANY, Permit) was modified by netscreen via web from host 192.168.1.10 to 192.168.1.1:80.
2014-04-30 15:28:55	notif	Policy (10, Untrust->Trust, Any->Kantor_Net,ANY, Permit) was modified by netscreen via web from host 192.168.1.10 to 192.168.1.1:80.
2014-04-30 15:28:55	notif	Policy (10, Untrust->Trust, Any->Kantor_Net,ANY, Permit) was modified by netscreen via web from host 192.168.1.10 to 192.168.1.1:80.
2014-04-30 15:28:55	notif	Policy (10, Untrust->Trust, Any->Kantor_Net,ANY, Permit) was modified by netscreen via web from host 192.168.1.10 to 192.168.1.1:80.
2014-04-30 15:28:37	info	IKE 114.121.152.104: XAuth login was passed for gateway Dialup_GW, username uservpn1, retry: 0, Client IP Addr 0.0.0.0, IPPool name: , Session-Timeout: 0s, Idle-Timeout: 0s.
2014-04-30 15:28:37	info	IKE 114.121.152.104: XAuth login was refreshed for username uservpn1 at 0.0.0.0/0.0.0.0.
2014-04-30 15:28:37	info	IKE 114.121.152.104 Phase 1: Completed Aggressive mode negotiations with a 28800-second lifetime.
2014-04-30 15:28:37	info	IKE 114.121.152.104 Phase 1: Completed for user ipsecvpn.
2014-04-30 15:28:37	info	IKE<114.121.152.104> Phase 1: IKE responder has detected NAT in front of the remote device.
2014-04-30 15:28:37	info	IKE<114.121.152.104> Phase 1: IKE responder has detected NAT in front of the local device.
2014-04-30 15:28:33	info	IKE 114.121.152.214 phase 1:The symmetric crypto key has been generated successfully.
2014-04-30 15:28:33	info	IKE 114.121.152.214 Phase 1: Responder starts AGGRESSIVE mode negotiations.