PIX VPN QM_IDLE

At this point shouldn't the PIX 501 network be able to ping any routers or telnet to them on the PIX 515 network side?

That depends. The PIX's know how to talk to each other, but does the router behind the PIX515 know how to route back to the subnet behind the 501?
Also, you must test from an actual workstation behind the 501 to an actual workstation/server behind the 515. You can't do it from the PIX console.

Take a look at phase 2 with "sho cry ip sa" and look for encap/decap counters and error counters

Here's a copy of my PIX 515 sho cry ip sa output.  Is this a good or bad result?  And I can't find the encap/decap counters and error counters either.

PIX01# sh cry ip sa


interface: outside
    Crypto map tag: VPNMAP, local addr. 65.125.12.14

   local  ident (addr/mask/prot/port): (SUBNET_1/255.255.255.0/0/0)
   remote ident (addr/mask/prot/port): (SUBNET_2/255.255.255.0/0/0)
   current_peer: 66.93.55.119:500
     PERMIT, flags={origin_is_acl,}
    #pkts encaps: 0, #pkts encrypt: 0, #pkts digest 0
    #pkts decaps: 209, #pkts decrypt: 209, #pkts verify 209
    #pkts compressed: 0, #pkts decompressed: 0
    #pkts not compressed: 0, #pkts compr. failed: 0, #pkts decompress failed: 0
    #send errors 0, #recv errors 0

     local crypto endpt.: 65.125.12.14, remote crypto endpt.: 66.93.55.119
     path mtu 1500, ipsec overhead 56, media mtu 1500
     current outbound spi: f539d588

     inbound esp sas:
      spi: 0x2b68a50f(728278287)
        transform: esp-des esp-md5-hmac ,
        in use settings ={Tunnel, }
        slot: 0, conn id: 3, crypto map: VPNMAP
        sa timing: remaining key lifetime (k/sec): (4608000/12872)
        IV size: 8 bytes
        replay detection support: Y


     inbound ah sas:


     inbound pcp sas:


     outbound esp sas:
      spi: 0xf539d588(4114208136)
        transform: esp-des esp-md5-hmac ,
        in use settings ={Tunnel, }
        slot: 0, conn id: 4, crypto map: VPNMAP
        sa timing: remaining key lifetime (k/sec): (4608000/12836)
        IV size: 8 bytes
        replay detection support: Y


     outbound ah sas:


     outbound pcp sas:


PIX01#

65.125.12.14 is the PIX 515 which I got the below output from.  And 66.93.55.119 is the PIX 501 output.  Did did I do this correctly?


PIX01(config)# sh cry isak sa
Total     : 1
Embryonic : 0
        dst               src        state     pending     created
   65.125.12.14     66.93.55.119    QM_IDLE         0           3
PIX01(config)#

>#pkts encaps: 0, #pkts encrypt: 0, #pkts digest 0
>#pkts decaps: 209, #pkts decrypt: 209, #pkts verify 209

Decaps with no encaps. Looks like a routing issue or an acl issue on your 501. Is the 501 inside IP the local default gateway?
Did you apply a nat_0 acl to the nat process?
Take a look at "show access-list" and see if the hit counters are increasing on your vpn traffic defining acls and/or your nat_0 acl..

Yes, on both sides I issue a "nat (inside) 0 access-list ACL_VPN1"

When I do a sh nat here is my output:

PIX01# sh nat
nat (inside) 0 access-list ACL_VPN1
nat (inside) 1 0.0.0.0 0.0.0.0 0 0
PIX01#

I thought from my PIX 515 (192.168.85.0) it would say the below but it's not??

nat (inside) 0 access-list ACL_VPN1
nat (inside) 1 192.168.85.0 255.255.255.0 0 0

Yes, the hit counters are increasing.  Now it's at 192.

>I thought from my PIX 515 (192.168.85.0) it would say the below but it's not??
>nat (inside) 0 access-list ACL_VPN1

Did you define the ACL_VPN1 ? Did you define a separate one for the VPN tunnel match traffic? Even though they are identical today, it is easier to grow, and besides I don't like assigning the same acl to two different processes (nat and cyrpto)
Given on 501 local lan = 192.168.1.x
Given on 515 local lan = 192.168.85.0

501:
access-list nat_zero permit ip 192.168.1.0 255.255.255.0 192.168.85.0 255.255.255.0
access-list ACL_VPN1 permit ip 192.168.1.0 255.255.255.0 192.168.85.0 255.255.255.0
nat (inside) 0 access-list nat_zero

The ACL_VPN1 is still applied as a match statement in the crypto map

515: mirror image
access-list nat_zero permit ip 192.168.85.0 255.255.255.0 192.168.1.0 255.255.255.0
access-list ACL_VPN1 permit ip 192.168.85.0 255.255.255.0 192.168.1.0 255.255.255.0
nat (inside) 0 access-list nat_zero

Correct.  Let me do it like this


Workstation
|
PIX 501
|
DSL Modem
|
Internet
|
GW Router
|
PIX 515
|
Catalyst switch
|
Workstation

My mistake.  Let me redo this:


Workstation
|
PIX 501
|
DSL Modem
|
Internet
|
GW Router
|
Cisco FastHub 400     <-------
|
PIX 515
|
Catalyst switch
|
Workstation

Is there any routing on the Catalyst switch going on ?
If routing's all OK, then perhaps NAT is causing the problem...?
If the VPN config was screwed, then phase 1 and phase 2 wouldn't even come up, so this usually means your config is OK.

>If routing's all OK, then perhaps NAT is causing the problem...?
My thoughts exactly, which led me to validate the access-lists and to separate the crypto match and the nat 0 acls..