[Vpn-help] Tunnel to juniper SSG - Shrew thinks it is up but Juniper does not

Daniel Qian daniel.qian at supracanada.com
Thu Jul 2 08:41:11 CDT 2009


Thanks for reply Matthew. Please see my message inline


----- Original Message ----- 
From: "Matthew Grooms" <mgrooms at shrew.net>
To: "Daniel Qian" <daniel.qian at supracanada.com>
Cc: <vpn-help at lists.shrew.net>
Sent: Tuesday, June 30, 2009 11:19 PM
Subject: Re: [Vpn-help] Tunnel to juniper SSG - Shrew thinks it is up but
Juniper does not


> Daniel Qian wrote:
>>
>> When I tried to ping an IP behind the remote firewall I got this:
>>
>> 2001-07-29 11:31:12    info    IKE x.x.x.x Phase 2 msg ID e3e5cc76:
>> Negotiations have failed.
>> 2001-07-29 11:31:12    info    IKE x.x.x.x Phase 2 msg ID e3e5cc76:
>> Negotiations have failed for user vpn at customer.com.
>
> This is the part of the output that is important ...
>
>> 2001-07-29 11:31:12    info    Rejected an IKE packet on ethernet0/0 from
>> x.x.x.x:28372 to y.y.y.y:4500 with cookies 59cfb0db677d4558 and
>> 04829041c531b49e because There were no acceptable Phase 2 proposals..
>>
>
> Your establishing phase1 and getting caught up on phase2 negotiations.
> Most likely, the netscreen doesn't like the proposal being sent by the
> client. Assuming you followed the howto, if you look at the following
> document section ...
>
> http://www.shrew.net/support/wiki/HowtoJuniperSsg#CreateanAutoKeyIKEGateway
>
> ... you will see how to configure the gateways phase2 parameters for
> vpnclient connections. When the client sends a phase2 proposal, they
> have to match whats configured on the gateway.
>
> For example, if you chose ...
>
> nopfs-esp-3des-md5
> nopfs-esp-3des-md5
> nopfs-esp-aes128-sha
> nopfs-esp-aes128-sha
>
> ... for "Phase 2 proposal" under the advanced parameters section, the
> client has to send one of those combinations exactly. If it doesn't
> match any of them, the gateway will report the error message shown in
> your log output "There were no acceptable Phase 2 proposals". If the
> client has all of its parameters set to 'auto', then it will send a slew
> of likely phase2 proposal combinations in an attempt to match whatever
> is configured on the gateway.
>

The proposals were previously set to auto. Now I reset them specifically to
match the ones on the Juniper side but still I am seeing the same error
message which I believe is a precursor of the subsequent P2 errors -
Rejected an IKE packet on ethernet0/0 from x.x.x.x:1353 to
y.y.y.y:4500 with cookies 12e12bac1c4beb1b and b9e10c9b2bc51f77 because
A Phase 2 packet arrived while XAuth was still pending.


> The other possibility is that the connection from the client isn't
> getting matched to the proper "AutoKey IKE Gateway" definition. In the
> example shown in the document, it will use the vpnclient_tunnel as the
> phase2 parameters for any connection that matched vpnclient_gateway
> "AutoKey Advanced / Gateway" for its phase1 parameters. How does your
> connection match "vpn at customer.com" back to your "AutoKey IKE Gateway"?
>

vpn at customer.com is basically an IKE user as member of "VPN User Group". The
whole setup is as below

set user "vpn at customer.com" uid 3
set user "vpn at customer.com" ike-id u-fqdn "vpn at customer.com" share-limit 25
set user "vpn at customer.com" type ike
set user "vpn at customer.com" "enable"
set user-group "VPN User Group" user "vpn at customer.com"

set ike gateway "VPN Client" dialup "VPN User Group" Aggr outgoing-interface
"ethernet0/0" preshare "a6qvVX3sdfgQNWHWEfs7rdCha+GeCVng4EzLsw==" proposal
"pre-g2-aes128-sha"
set ike gateway "VPN Client" nat-traversal udp-checksum
set ike gateway "VPN Client" nat-traversal keepalive-frequency 5
set ike gateway "VPN Client" xauth
unset ike gateway "VPN Client" xauth do-edipi-auth

set vpn "VPN Clients" gateway "VPN Client" no-replay tunnel idletime 0
proposal "g2-esp-aes128-sha"


When Shrew says tunnel is enabled, I do not see this on the Juniper side 
from its 'VPN monitor' window. But if I connect with netscreen-remote client 
from Juniper I can see the active entry for the established tunnel. So I 
believe the problem is still that Juniper does not have a tunnel for the 
incoming Ipsec traffic sent by Shrew client

-----------------------------------------------------------------------------------------------------

I can give you a test account on the Juniper if that will help to debug.


Best Regards,
Daniel







More information about the vpn-help mailing list