<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
</head>
<body bgcolor="#ffffff" text="#000000">
<font face="Arial">I'm attempting to use the Shrew 2.0.2 Windows client
on WinXP with a PIX 501 running rev 6.3(5). Phase I completes
successfully, but Phase II startup appears to go into a loop with no
errors reported by either side but nothing exchanged other than dead
peer detection packets. <br>
<br>
The Shrew-side ISAKMP trace repeats the following messages.<br>
</font>
<blockquote><font face="Arial">ii : sending peer DPDV1-R-U-THERE
notification<br>
</font><font face="Arial">ii : - 192.168.0.102:500 ->
67.152.82.163:500<br>
</font><font face="Arial">ii : - isakmp spi =
b45d7600cd6dbd33:052b4d22135a671b<br>
</font><font face="Arial">ii : - data size 4<br>
</font><font face="Arial">>> : hash payload<br>
</font><font face="Arial">>> : notification payload<br>
</font><font face="Arial">== : new informational hash ( 16 bytes )<br>
</font><font face="Arial">== : new phase2 iv ( 16 bytes )<br>
</font><font face="Arial">>= : encrypt iv ( 16 bytes )<br>
</font><font face="Arial">=> : encrypt packet ( 80 bytes )<br>
</font><font face="Arial">== : stored iv ( 16 bytes )<br>
</font><font face="Arial">-> : send IKE packet 192.168.0.102:500
-> 67.152.82.163:500 ( 120 bytes )<br>
</font><font face="Arial">ii : DPD ARE-YOU-THERE sequence 0df01a13
requested<br>
</font><font face="Arial"><- : recv IKE packet 67.152.82.163:500
-> 192.168.0.102:500 ( 92 bytes )<br>
</font><font face="Arial">DB : phase1 found<br>
</font><font face="Arial">DB : phase1 ref increment ( ref count = 3,
phase1 count = 1 )<br>
</font><font face="Arial">== : new phase2 iv ( 16 bytes )<br>
</font><font face="Arial">=< : decrypt iv ( 16 bytes )<br>
</font><font face="Arial"><= : decrypt packet ( 92 bytes )<br>
</font><font face="Arial">== : stored iv ( 16 bytes )<br>
</font><font face="Arial"><< : hash payload<br>
</font><font face="Arial"><< : notification payload<br>
</font><font face="Arial">== : informational hash_i ( computed ) ( 16
bytes )<br>
</font><font face="Arial">== : informational hash_c ( received ) ( 16
bytes )<br>
</font><font face="Arial">ii : informational hash verified<br>
</font><font face="Arial">ii : received peer DPDV1-R-U-THERE-ACK
notification<br>
</font><font face="Arial">ii : - 67.152.82.163:500 ->
192.168.0.102:500<br>
</font><font face="Arial">ii : - isakmp spi =
052b4d22135a671b:b45d7600cd6dbd33<br>
</font><font face="Arial">ii : - data size 4<br>
</font><font face="Arial">ii : DPD ARE-YOU-THERE-ACK sequence
0df01a13 accepted<br>
</font><font face="Arial">DB : phase1 ref decrement ( ref count = 2,
phase1 count = 1 )<br>
</font></blockquote>
<font face="Arial">and the PIX-side trace repeats these messages (note
that IPSEC and ISAKMP debug output are turned on on the PIX, but not
IPSEC messages appear here even though the Shrew-side trace mentions
Phase II IV's).<br>
<br>
</font>
<blockquote><font face="Arial">crypto_isakmp_process_block:src:67.152.82.178,
dest:67.152.82.163 spt:500 dpt:500
<br>
ISAKMP (0): processing NOTIFY payload 36136 protocol 1
<br>
spi 0, message ID = 349158505
<br>
ISAMKP (0): received DPD_R_U_THERE from peer 67.152.82.178
<br>
ISAKMP (0): sending NOTIFY message 36137 protocol1
<br>
return status is IKMP_NO_ERR_NO_TRANS
<br>
</font></blockquote>
<font face="Arial">The relevant parts of the PIX configuration appear
below. The Shrew config is hardwired to match the parameters there;
only the IP address is pulled back from the PIX. The inside nets are
172.17 and 172.16. The clients are assigned addresses from 172.18.0
with a Class C subnet mask.<br>
</font>
<blockquote><font face="Arial">! this access list is used to specify
the outbound traffic that will be<br>
! encrypted<br>
access-list 101 permit ip 172.16.0.0 255.255.0.0 172.18.0.0
255.255.255.0
<br>
access-list 101 permit ip 172.17.0.0 255.255.0.0 172.18.0.0
255.255.255.0
<br>
! prevent ACL checking for IPSEC traffic<br>
sysopt connection permit-ipsec
<br>
! Phase 2 is AES256+MD5+Group 2<br>
crypto ipsec transform-set trset2 esp-aes-256 esp-md5-hmac
<br>
crypto dynamic-map ipsec_map 1 match address 101
<br>
crypto dynamic-map ipsec_map 1 set pfs group2
<br>
crypto dynamic-map ipsec_map 1 set transform-set trset2
<br>
crypto map outside_map 65535 ipsec-isakmp dynamic ipsec_map
<br>
crypto map outside_map interface outside
<br>
! Phase 1 uses pre-shared keys, AES256+MD5<br>
isakmp enable outside
<br>
isakmp key ******** address 1.1.1.1 netmask 0.0.0.0
<br>
isakmp identity address
<br>
isakmp client configuration address-pool local clientpool outside
<br>
isakmp log 25
<br>
isakmp policy 1 authentication pre-share
<br>
isakmp policy 1 encryption aes-256
<br>
isakmp policy 1 hash md5
<br>
isakmp policy 1 group 2
<br>
isakmp policy 1 lifetime 28800
<br>
</font></blockquote>
<font face="Arial">Any insight on what's happening with Phase II would
be gratefully accepted.<br>
<br>
Thanks!<br>
<br>
</font><font face="Arial"><br>
</font>
<blockquote><font face="Arial"><br>
</font></blockquote>
<font face="Arial"><br>
</font>
</body>
</html>