[Vpn-help] PIX 501 and Shrew 2.0.2 client

[Marc Goldburg]

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. 

The Shrew-side ISAKMP trace repeats the following messages.

    ii : sending peer DPDV1-R-U-THERE notification
    ii : - 192.168.0.102:500 -> 67.152.82.163:500
    ii : - isakmp spi = b45d7600cd6dbd33:052b4d22135a671b
    ii : - data size 4
     >> : hash payload
     >> : notification payload
    == : new informational hash ( 16 bytes )
    == : new phase2 iv ( 16 bytes )
     >= : encrypt iv ( 16 bytes )
    => : encrypt packet ( 80 bytes )
    == : stored iv ( 16 bytes )
    -> : send IKE packet 192.168.0.102:500 -> 67.152.82.163:500 ( 120
    bytes )
    ii : DPD ARE-YOU-THERE sequence 0df01a13 requested
    <- : recv IKE packet 67.152.82.163:500 -> 192.168.0.102:500 ( 92 bytes )
    DB : phase1 found
    DB : phase1 ref increment ( ref count = 3, phase1 count = 1 )
    == : new phase2 iv ( 16 bytes )
    =< : decrypt iv ( 16 bytes )
    <= : decrypt packet ( 92 bytes )
    == : stored iv ( 16 bytes )
    << : hash payload
    << : notification payload
    == : informational hash_i ( computed ) ( 16 bytes )
    == : informational hash_c ( received ) ( 16 bytes )
    ii : informational hash verified
    ii : received peer DPDV1-R-U-THERE-ACK notification
    ii : - 67.152.82.163:500 -> 192.168.0.102:500
    ii : - isakmp spi = 052b4d22135a671b:b45d7600cd6dbd33
    ii : - data size 4
    ii : DPD ARE-YOU-THERE-ACK sequence 0df01a13 accepted
    DB : phase1 ref decrement ( ref count = 2, phase1 count = 1 )

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).

    crypto_isakmp_process_block:src:67.152.82.178, dest:67.152.82.163
    spt:500 dpt:500
    ISAKMP (0): processing NOTIFY payload 36136 protocol 1
            spi 0, message ID = 349158505
    ISAMKP (0): received DPD_R_U_THERE from peer 67.152.82.178
    ISAKMP (0): sending NOTIFY message 36137 protocol1
    return status is IKMP_NO_ERR_NO_TRANS

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.

    ! this access list is used to specify the outbound traffic that will be
    ! encrypted
    access-list 101 permit ip 172.16.0.0 255.255.0.0 172.18.0.0
    255.255.255.0
    access-list 101 permit ip 172.17.0.0 255.255.0.0 172.18.0.0
    255.255.255.0
    ! prevent ACL checking  for IPSEC traffic
    sysopt connection permit-ipsec
    ! Phase 2 is AES256+MD5+Group 2
    crypto ipsec transform-set trset2 esp-aes-256 esp-md5-hmac
    crypto dynamic-map ipsec_map 1 match address 101
    crypto dynamic-map ipsec_map 1 set pfs group2
    crypto dynamic-map ipsec_map 1 set transform-set trset2
    crypto map outside_map 65535 ipsec-isakmp dynamic ipsec_map
    crypto map outside_map interface outside
    ! Phase 1 uses pre-shared keys, AES256+MD5
    isakmp enable outside
    isakmp key ******** address 1.1.1.1 netmask 0.0.0.0
    isakmp identity address
    isakmp client configuration address-pool local clientpool outside
    isakmp log 25
    isakmp policy 1 authentication pre-share
    isakmp policy 1 encryption aes-256
    isakmp policy 1 hash md5
    isakmp policy 1 group 2
    isakmp policy 1 lifetime 28800

Any insight on what's happening with Phase II would be gratefully accepted.

Thanks!




-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.shrew.net/pipermail/vpn-help/attachments/20071031/6f55681a/attachment-0001.html>