?
Solved

Pix-Pix VPN comes up, but one not returning data

Posted on 2006-04-28
19
Medium Priority
?
296 Views
Last Modified: 2013-11-16
Have a VPN defined between a 520 (rev 6.3) and a 501 (rev 6.2).  The tunnel comes up, sa's are active, and using packet capture I can verify that traffic from the remote site (501) gets across the tunnel and to a test server I am pinging and I see where the server then replies, but the traffic dies there - the 520 does not encaps it and send it back.  Same behavior applies for all traffic types besides ICMP.  Cut from 'show crypto ipsec sa" reflects this as well.  

501 side:
    #pkts encaps: 49, #pkts encrypt: 49, #pkts digest 49
    #pkts decaps: 0, #pkts decrypt: 0, #pkts verify 0

520 side:  (counters hinky from rebooting remote)
    #pkts encaps: 0, #pkts encrypt: 0, #pkts digest 0
    #pkts decaps: 58, #pkts decrypt: 58, #pkts verify 58

I know my access-list for matching traffic is good on the 520 side, as when I ping from the server (located at the 520 side) to the remote, the hit counter for that acl increments.  Somewhere between access-list matching and encapsualting into the tunnel I'm losing it.  Gotta be something simple, anyone seen this before?
0
Comment
Question by:cjuel
  • 10
  • 8
18 Comments
 
LVL 79

Expert Comment

by:lrmoore
ID: 16564376
Looks like a potential routing issue. One-way traffic is usually one of two things:
Routing - what is the default gateway of the server? Is it the PIX or another router?
NAT - do you have the 501's LAN subnet entered in your nat-0 access-list and do you have this acl applied to nat? Mirror image of 501 side...
0
 

Author Comment

by:cjuel
ID: 16564473
I had to drop back to the former config, where the server went to another router, but at the time of the test the route back to the remote subnet was set to go to the pix.  I did the packet trace to verify the server was routing correctly.

On both sides the inside subnet is reflected in the acl used for nat 0:

501:
access-list 140 permit ip 10.109.172.0 255.255.255.0 10.43.1.0 255.255.255.0
nat (inside) 0 access-list 140
nat (inside) 1 0.0.0.0 0.0.0.0 0 0

520 (problem side):
access-list 140 permit ip 10.43.1.0 255.255.255.0 10.109.172.0 255.255.255.0
nat (inside) 0 access-list 140
nat (inside) 1 10.0.0.0 255.0.0.0 0
nat (inside) 1 192.168.0.0 255.255.128.0 0 0
nat (inside) 2 172.31.1.2 255.255.255.255 0 0
nat (inside) 2 10.43.1.0 255.255.255.0 0 0
nat (inside) 2 172.21.210.0 255.255.255.0 0 0
nat (inside) 2 10.16.16.0 255.255.240.0 0 0
nat (inside) 2 10.50.0.0 255.255.0.0 0 0

On the 520 side there's a previous entry natting that subnet as well.  The acl for the tunnel is more granular, so I didn't expect a problem, but can these entries co-exist?
0
 
LVL 79

Expert Comment

by:lrmoore
ID: 16564516
>On the 520 side there's a previous entry natting that subnet as well.  The acl for the tunnel is more granular, so I didn't expect a problem, but can these entries co-exist?

I'm not sure I understand this one. If you are referring to this:
>nat (inside) 2 10.43.1.0 255.255.255.0 0 0
Then yes, they can definately co-exist.

How about the acl that defines the traffic to be matched for the crypto map?
 Do you use a different acl for the crypto map match statement and for the nat0?

ie.
access-list 140 permit ip 10.43.1.0 255.255.255.0 10.109.172.0 255.255.255.0
nat (inside) 0 access-list 140

access-list 150 permit ip 10.43.1.0 255.255.255.0 10.109.172.0 255.255.255.0
crypto map mymap xx set peer x.x.x.x
crypto map mymap xx match address 150

PIX is much happier when you use two different ones even if they are identical. Also makes troubleshooting easier. Using "show access-list" you can see hitcounts on one or the other or both, but not if you use the same acl for two separate processes..
0
Exciting career futures for women in IT

Education has the power to transform lives and open the door to new career opportunities. By earning an IT degree from WGU, you can become a highly skilled IT professional. Get the credentials and certifications you need to become a leader in this rewarding field.  

 
LVL 79

Expert Comment

by:lrmoore
ID: 16585164
Hello? Any news?
0
 

Author Comment

by:cjuel
ID: 16585378
Sorry, got put on another higher priority project for a couple of days.  

I've used both dual and single acls for nat0 and crypto map.  Didn't change the behavior, but I see your point about the acl counts - will redo with separate acls when I revisit this on Friday.

Thanks for the feedback, will post by mid-morning Friday

0
 
LVL 79

Expert Comment

by:lrmoore
ID: 16585484
Thanks for the update!
0
 

Author Comment

by:cjuel
ID: 16593802
Ok, got time to work it (you can get lots done by not sleeping) and I found routes that were apparently causing the problem.  They were less specific (i.e., 10.0.0.0/8 static was matching over my 10.43.1.0/24 acl entry), which seemed odd, but the good news was a bunch of those routes were legacy crap (I swear I inherited it) that needed whacking anyway, so I now have solid site-to-site with my inside subnets talking.

What I now need to figure out is how to make the dmz at the main site accesible to the remote site.  Main site is three-legged, remote is just inside and outsid einterfaces,  Obviously I can't simply add the dmz subnet to the acls for the inside interface, but it's not clear to my sleep-deprived brain how this is accomplished.  

At the remote site do all three subnets stay listed in the same acl and I just have to correctly configure the main site or will I have two maps at each site?
0
 

Author Comment

by:cjuel
ID: 16594801
Ok, it seems like like been through every possible permutation of this, so before I burst a blood vessel let's get you more info to work with.
I have the VPN up, I can get to the internal 10.43.1.0/243 and the 16.16.16.0/24 networks fine - it's accessing the 192.168.255.0/24 DMZ subnet
from the remote site (10.109.172.0/24) that I cannot make work.

he remote site is encapsulating and near as I can tell is not the issue sending fine.  Here's where I stand right now at the host site.  I am sure of
the routing on either side.

GLOBAL / NATS:
global (outside) 1 11.22.33.43-11.22.33.249 netmask 255.255.255.0
global (outside) 1 11.22.33.250 netmask 255.255.255.0
nat (inside) 0 access-list 140
nat (inside) 2 172.31.1.2 255.255.255.255 0 0
nat (inside) 2 10.43.1.0 255.255.255.0 0 0
nat (inside) 2 172.21.210.0 255.255.255.0 0 0
nat (inside) 2 10.16.16.0 255.255.240.0 0 0
nat (inside) 2 10.50.0.0 255.255.0.0 0 0
nat (inside) 1 10.0.0.0 255.0.0.0 0 0
nat (DMZ) 0 access-list 141

MY OUTSIDE ACLS ARE MASSIVE, SO I LEFT THEM OUT.
I HAD TO REMOVE A BUNCH OF CONDUITS AND CREATE THE FOLLOWING ACL FOR THE DMZ:
access-list acl-dmz permit tcp host 192.168.255.0 any eq https
access-list acl-dmz permit tcp 192.168.255.0 255.255.255.0 host 10.43.1.1 eq domain
access-list acl-dmz permit udp 192.168.255.0 255.255.255.0 host 10.43.1.1 eq domain
access-list acl-dmz permit tcp 192.168.255.0 255.255.255.0 host 10.43.1.39 eq 3306
access-list acl-dmz permit tcp 192.168.255.0 255.255.255.0 host 10.43.1.42 eq 3306
access-list acl-dmz permit udp 192.168.255.0 255.255.255.0 host 10.43.1.210 eq domain
access-list acl-dmz permit udp 192.168.255.0 255.255.255.0 host 10.43.1.8 eq domain
access-list acl-dmz permit tcp host 192.168.255.99 host 10.43.1.211 eq smtp
access-list acl-dmz permit tcp host 192.168.255.99 host 10.43.1.210 eq smtp
access-list acl-dmz permit tcp 192.168.255.0 255.255.255.0 host 10.43.1.240 eq 1433
access-list acl-dmz permit tcp 192.168.255.0 255.255.255.0 any eq ssh
access-list acl-dmz permit tcp 192.168.255.0 255.255.255.0 10.109.172.0 255.255.255.0
access-list acl-dmz permit udp 192.168.255.0 255.255.255.0 10.109.172.0 255.255.255.0
access-list acl-dmz permit icmp 192.168.255.0 255.255.255.0 10.109.172.0 255.255.255.0
access-list acl-dmz permit icmp any any

MY INSIDE NAT0 ACL GETS HITS FOR ALL BUT THE PROBLEM SUBNET
access-list 140 permit ip 10.43.1.0 255.255.255.0 10.109.172.0 255.255.255.0        (hitcnt=38590)
access-list 140 permit ip 10.16.16.0 255.255.255.0 10.109.172.0 255.255.255.0        (hitcnt=82)
access-list 140 permit ip 192.168.255.0 255.255.255.0 10.109.172.0 255.255.255.0 (hitcnt=0)

MY DMZ NAT0 ACL GETS HITS
access-list 141 permit icmp 192.168.255.0 255.255.255.0 10.109.172.0 255.255.255.0 (hitcnt=0)
access-list 141 permit ip 192.168.255.0 255.255.255.0 10.109.172.0 255.255.255.0   (hitcnt=18)

MY MAP MATCH ACL GOT HITS ON 192.168.255.0 AT ONE POINT IN TESTING, BUT NOT SURE WHEN - IT DOESN'T NOW
access-list 150 permit ip 10.43.1.0 255.255.255.0 10.109.172.0 255.255.255.0       (hitcnt=3490)
access-list 150 permit ip 10.16.16.0 255.255.255.0 10.109.172.0 255.255.255.0      (hitcnt=34)
access-list 150 permit ip 192.168.255.0 255.255.255.0 10.109.172.0 255.255.255.0 (hitcnt=8)  <???

THIS WAS LEFTOVER FROM TESTING:
access-list 151 permit ip 192.168.255.0 255.255.255.0 10.109.172.0 255.255.255.0 (hitcnt=0)

APPLIED ACL TO DMZ
access-group acl-dmz in interface DMZ

THESE ARE LEFT OVER FROM OCNDUITS - I INTEND TO GET RID OF THEM, BUT I'M NOT SURE IF THEY ARE INVOLVED WITH MY PROB OR NOT
outbound   1 deny 172.16.0.0 255.240.0.0 0 tcp
outbound   1 deny 10.0.0.0 255.0.0.0 0 tcp

USUAL CRYPTO STUFF
crypto ipsec transform-set strong esp-des esp-sha-hmac
crypto map dallas 20 ipsec-isakmp
crypto map dallas 20 match address 150
crypto map dallas 20 set peer 11.22.33.44
crypto map dallas 20 set transform-set strong
crypto map dallas interface outside
isakmp enable outside                  (HAD "isakmp enable DMZ" AS WELL AT ONE POINT, BUT DID NOT MATTER)
isakmp key ******** address 11.22.33.44 netmask 255.255.255.255
isakmp identity address
isakmp policy 9 authentication pre-share
isakmp policy 9 encryption des
isakmp policy 9 hash md5
isakmp policy 9 group 2
isakmp policy 9 lifetime 86400

===========================================================================================
PACKET CAPTURE SHOWS ICMPS GET FROM REMOTE TO A SERVER ON THE 192.168.255.0 AND I SEE REPLIES FROM THE SERVER BACK
TO THE REMOTE (10.109.172.0) ON THE "DMZ" INTERFACE.  MY DMZ NAT0 MATCHES, AS ITS COUNTER INCREASES, BUT NOTHING ELSE
===========================================================================================

local  ident (addr/mask/prot/port): (192.168.255.0/255.255.255.0/0/0)
   remote ident (addr/mask/prot/port): (10.109.172.0/255.255.255.0/0/0)
   current_peer: 11.22.33.44
     PERMIT, flags={origin_is_acl,}
    #pkts encaps: 0, #pkts encrypt: 0, #pkts digest 0
    #pkts decaps: 174, #pkts decrypt: 174, #pkts verify 174
    #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.: 55.66.77.88, remote crypto endpt.: 11.22.33.44
     path mtu 1500, ipsec overhead 56, media mtu 1500
     current outbound spi: 7954d3f6

     inbound esp sas:
      spi: 0xf76d29e9(4151126505)
        transform: esp-des esp-sha-hmac ,
        in use settings ={Tunnel, }
        slot: 0, conn id: 5, crypto map: dallas
        sa timing: remaining key lifetime (k/sec): (4607984/26573)
        IV size: 8 bytes
        replay detection support: Y

     inbound ah sas:

     inbound pcp sas:

     outbound esp sas:
      spi: 0x7954d3f6(2035602422)
        transform: esp-des esp-sha-hmac ,
        in use settings ={Tunnel, }
        slot: 0, conn id: 6, crypto map: dallas
        sa timing: remaining key lifetime (k/sec): (4608000/26573)
        IV size: 8 bytes
        replay detection support: Y

NOW THERE IS A STATIC NAT MAPPING FOR THE SERVER I AM TESTING WITH - I'M THINKING THIS IS MY ISSUE?
static (DMZ,outside) 11.22.33.11 192.168.255.11 netmask 255.255.255.255 0 0

ANY IDEAS?  IF THE STATIC IS THE ISSUE, HOW DOES ONE PROVIDE INTERNAL VPN ACCESS AS WELL AS EXTERNAL TO THE SAME BOX?

THANKS IN ADVANCE.  HELP ME FIX THIS AND I'LL FIGURE OUT A WAY TO EMAIL BEER.

0
 
LVL 79

Expert Comment

by:lrmoore
ID: 16596635
>What I now need to figure out is how to make the dmz at the main site accesible to the remote site.
>so before I burst a blood vessel let's get you more info to work with.
Relax! We can do this!

//-- allow traffic through the dmz interface
access-list acl-dmz permit ip 192.168.255.0 255.255.255.0 10.109.172.0 255.255.255.0

//-- this is good
access-list 141 permit ip 192.168.255.0 255.255.255.0 10.109.172.0 255.255.255.0   (hitcnt=18)
nat (DMZ) 0 access-list 141

//-- don't need this
access-list 140 permit ip 192.168.255.0 255.255.255.0 10.109.172.0 255.255.255.0 (hitcnt=0)

//-- need to add acl entry for 150, looks like you have that -- with hitcounts. Good!
crypto map dallas 20 match address 150
access-list 150 permit ip 192.168.255.0 255.255.255.0 10.109.172.0 255.255.255.0 (hitcnt=8)

Static nat mappings should not be an issue because you also have the nat0 access-list for more specific traffic.

Get rid of all the legacy outbound and conduit stuff.

On the remote 501 site, it should be just a matter of adding two entries for the dmz subnet
  access-list outbound_nat0 permit ip 10.109.172.0 255.255.255.0 192.168.255.0 255.255.255.0
  access-list crypto_map_match permit ip 10.109.172.0 255.255.255.0 192.168.255.0 255.255.255.0

That should be all it takes now that you've got the routing issues taken care of..


0
 

Author Comment

by:cjuel
ID: 16596766
Will try it here directly, gotta fix other things first.

On the remote 501 site, are these acls applied or referenced somewhere or are they standalone?  
I ask because though I didn't send its config everything looked good on that side.
 
  access-list outbound_nat0 permit ip 10.109.172.0 255.255.255.0 192.168.255.0 255.255.255.0
  access-list crypto_map_match permit ip 10.109.172.0 255.255.255.0 192.168.255.0 255.255.255.0
0
 
LVL 79

Expert Comment

by:lrmoore
ID: 16596883
These are representative of the two acls, one applied to
nat (inside) 0 access-list <ACL>

the other applied to the crypto map
crypto map mymp 20 match address <ACL>
0
 

Author Comment

by:cjuel
ID: 16605924
I think I have everything in line, but I don't seem to match traffic on the crypto map acl.  I started a constaing ping from remote to 192.168.255.0 (DMZ host) at the main site and looked for incrementing counters.  Here's info, starting with remote:

REMOTE:
remotepix# show nat
nat (inside) 0 access-list 140
nat (inside) 1 0.0.0.0 0.0.0.0 0 0

remotepix# show access-list 140
access-list 140; 3 elements
access-list 140 line 1 permit ip 10.109.172.0 255.255.255.0 10.43.1.0 255.255.255.0 (hitcnt=2802)
access-list 140 line 2 permit ip 10.109.172.0 255.255.255.0 10.16.16.0 255.255.255.0 (hitcnt=99)
access-list 140 line 3 permit ip 10.109.172.0 255.255.255.0 192.168.255.0 255.255.255.0 (hitcnt=386) INCREMENTING

sysopt connection permit-ipsec
crypto ipsec transform-set strong esp-des esp-sha-hmac
crypto map dallas 20 ipsec-isakmp
crypto map dallas 20 match address 150
crypto map dallas 20 set peer 11.22.33.44
crypto map dallas 20 set transform-set strong
crypto map dallas interface outside
isakmp enable outside

remotepix# show access-list 150
access-list 150; 3 elements
access-list 150 line 1 permit ip 10.109.172.0 255.255.255.0 10.43.1.0 255.255.255.0 (hitcnt=1247)
access-list 150 line 2 permit ip 10.109.172.0 255.255.255.0 10.16.16.0 255.255.255.0 (hitcnt=75)
access-list 150 line 3 permit ip 10.109.172.0 255.255.255.0 192.168.255.0 255.255.255.0 (hitcnt=409) INCREMENTING

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

============================================================================================
MAIN SITE:

mainpixfw# show nat
nat (inside) 0 access-list 140
nat (inside) 2 172.31.1.2 255.255.255.255 0 0
nat (inside) 2 10.43.1.0 255.255.255.0 0 0
nat (inside) 2 172.21.210.0 255.255.255.0 0 0
nat (inside) 2 10.16.16.0 255.255.240.0 0 0
nat (inside) 1 192.168.0.0 255.255.128.0 0 0
nat (inside) 2 10.50.0.0 255.255.0.0 0 0
nat (inside) 1 10.0.0.0 255.0.0.0 0 0
nat (DMZ) 0 access-list 141

mainpixfw# show access-list 140
access-list 140; 2 elements
access-list 140 permit ip 10.43.1.0 255.255.255.0 10.109.172.0 255.255.255.0 (hitcnt=50427)
access-list 140 permit ip 10.16.16.0 255.255.255.0 10.109.172.0 255.255.255.0 (hitcnt=34)

mainpixfw# show access-list 141
access-list 141; 1 elements
access-list 141 permit ip 192.168.255.0 255.255.255.0 10.109.172.0 255.255.255.0 (hitcnt=92) INCREMENTING

sysopt connection permit-ipsec
sysopt connection permit-pptp
sysopt noproxyarp DMZ
no sysopt route dnat
crypto ipsec transform-set strong esp-des esp-sha-hmac
crypto map dallas 20 ipsec-isakmp
crypto map dallas 20 match address 150
crypto map dallas 20 set peer 55.66.77.88
crypto map dallas 20 set transform-set strong
crypto map dallas interface outside

access-list 150; 3 elements
access-list 150 permit ip 10.43.1.0 255.255.255.0 10.109.172.0 255.255.255.0 (hitcnt=602)
access-list 150 permit ip 10.16.16.0 255.255.255.0 10.109.172.0 255.255.255.0 (hitcnt=14)
access-list 150 permit ip 192.168.255.0 255.255.255.0 10.109.172.0 255.255.255.0 (hitcnt=8) NOT INCREMENTING!

   local  ident (addr/mask/prot/port): (192.168.255.0/255.255.255.0/0/0)
   remote ident (addr/mask/prot/port): (10.109.172.0/255.255.255.0/0/0)
   current_peer: 55.66.77.88
     PERMIT, flags={origin_is_acl,}
>>  #pkts encaps: 0, #pkts encrypt: 0, #pkts digest 0
    #pkts decaps: 81, #pkts decrypt: 81, #pkts verify 81
    #pkts compressed: 0, #pkts decompressed: 0
    #pkts not compressed: 0, #pkts compr. failed: 0, #pkts decompress failed: 0
    #send errors 0, #recv errors 0

No routes in the way, should match map acl- ?
mainpixfw# show route
        outside 0.0.0.0 0.0.0.0 11.22.33.254 OTHER static
        inside 10.16.16.0 255.255.255.0 10.43.1.165 1 OTHER static
        inside 10.43.1.0 255.255.255.0 10.43.1.254 1 CONNECT static
        inside 10.50.9.0 255.255.255.192 10.43.1.253 2 OTHER static
        inside 10.50.10.0 255.255.255.192 10.43.1.253 2 OTHER static
        inside 10.50.10.64 255.255.255.192 10.43.1.253 2 OTHER static
        inside 172.21.210.0 255.255.255.0 10.43.1.251 1 OTHER static
        inside 172.31.1.0 255.255.255.248 10.43.1.252 1 OTHER static
        inside 192.168.0.0 255.255.128.0 10.43.1.253 1 OTHER static
        BP-DMZ 192.168.253.0 255.255.255.240 192.168.253.1 1 CONNECT static
        NFC-DMZ 192.168.255.0 255.255.255.0 192.168.255.1 1 CONNECT static

nfchou-pixfw# show access-list acl-dmz
access-list acl-dmz; 27 elements
access-list acl-dmz permit tcp 192.168.255.0 255.255.255.0 any eq ssh (hitcnt=0)
access-list acl-dmz permit icmp 192.168.255.0 255.255.255.0 10.109.172.0 255.255.255.0 (hitcnt=262)
access-list acl-dmz permit udp host 192.168.255.11 any eq domain (hitcnt=253522)
access-list acl-dmz permit udp host 192.168.255.12 any eq domain (hitcnt=51698)
access-list acl-dmz permit tcp 192.168.255.0 255.255.255.0 any eq https (hitcnt=2213)
access-list acl-dmz permit icmp 192.168.255.0 255.255.255.0 any (hitcnt=6976)       <<<<<< INCREMENTING
access-list acl-dmz permit tcp 192.168.255.0 255.255.255.0 any eq www (hitcnt=141)
access-list acl-dmz permit ip 192.168.255.0 255.255.255.0 10.109.172.0 255.255.255.0 (hitcnt=0)

0
 

Author Comment

by:cjuel
ID: 16606480
FYI, I highlighted the wrong entry in the "acl-dmz" acl - the counter that is incrementing is on this entry:

access-list acl-dmz permit icmp 192.168.255.0 255.255.255.0 10.109.172.0 255.255.255.0 (hitcnt=419)

Definitely seems to be the map acl match - I deleted the entry that should be hitting and re-added it, as well as another entry specific to the host I am pinging - neither get a hit:

mainpixfw# show access-list 150
access-list 150; 4 elements
access-list 150 permit ip 10.43.1.0 255.255.255.0 10.109.172.0 255.255.255.0 (hitcnt=678)
access-list 150 permit ip 10.16.16.0 255.255.255.0 10.109.172.0 255.255.255.0 (hitcnt=16)
access-list 150 permit ip 192.168.255.0 255.255.255.0 10.109.172.0 255.255.255.0 (hitcnt=0)
access-list 150 permit ip host 192.168.255.11 10.109.172.0 255.255.255.0 (hitcnt=0)


0
 

Author Comment

by:cjuel
ID: 16615722
Bumping up them points - I will be able to work this today and need an opinion on the last two posts.
0
 
LVL 79

Expert Comment

by:lrmoore
ID: 16616549
Did you create a new access-list for dmz traffic?

access-list 141 permit ip 192.168.255.0 255.255.255.0 10.109.172.0 255.255.255.0
nat (inside) 0 access-list 140
nat (DMZ) 0 access-list 141
0
 

Author Comment

by:cjuel
ID: 16617075
Yes 141 is applied to dmz nat0 and it is incrementing:

mainpixfw# show nat
nat (inside) 0 access-list 140
nat (inside) 2 172.31.1.2 255.255.255.255 0 0
nat (inside) 2 10.43.1.0 255.255.255.0 0 0
nat (inside) 2 172.21.210.0 255.255.255.0 0 0
nat (inside) 2 10.16.16.0 255.255.240.0 0 0
nat (inside) 1 192.168.0.0 255.255.128.0 0 0
nat (inside) 2 10.50.0.0 255.255.0.0 0 0
nat (inside) 1 10.0.0.0 255.0.0.0 0 0
nat (DMZ) 0 access-list 141

mainpixfw# show access-list 141
access-list 141; 1 elements
access-list 141 permit ip 192.168.255.0 255.255.255.0 10.109.172.0 255.255.255.0 (hitcnt=92) INCREMENTING

What seems to fail is the matches for the DMZ subnet in the acl for the crypto map:

crypto map dallas 20 match address 150

access-list 150; 3 elements
access-list 150 permit ip 10.43.1.0 255.255.255.0 10.109.172.0 255.255.255.0 (hitcnt=602)
access-list 150 permit ip 10.16.16.0 255.255.255.0 10.109.172.0 255.255.255.0 (hitcnt=14)
access-list 150 permit ip 192.168.255.0 255.255.255.0 10.109.172.0 255.255.255.0 (hitcnt=8) NOT INCREMENTING, NOT SURE WHEN THESE 8 HIT
0
 
LVL 79

Accepted Solution

by:
lrmoore earned 1500 total points
ID: 16621012
I think you're going to have to post your complete configs from both ends..
0
 

Author Comment

by:cjuel
ID: 16797951
Going to punt on this for now.  We're replacing the pix at the main site with an ASA (for other reasons, not because of this) and will get a chance to rebuild everything from the ground up.  If issue persists I'll dump it in Cisco's lap.  Thanks for your help.
0

Featured Post

Transaction-level recovery for Oracle database

Veeam Explore for Oracle delivers low RTOs and RPOs with agentless transaction log backup and transaction-level recovery of Oracle databases. You can restore the database to a precise point in time, even to a specific transaction.

Question has a verified solution.

If you are experiencing a similar issue, please ask a related question

WARNING:   If you follow the instructions here, you will wipe out your VTP and VLAN configurations.  Make sure you have backed up your switch!!! I recently had some issues with a few low-end Cisco routers (RV325) and I opened a case with Cisco TA…
In this article, the configuration steps in Zabbix to monitor devices via SNMP will be discussed with some real examples on Cisco Router/Switch, Catalyst Switch, NAS Synology device.
Both in life and business – not all partnerships are created equal. As the demand for cloud services increases, so do the number of self-proclaimed cloud partners. Asking the right questions up front in the partnership, will enable both parties …
Both in life and business – not all partnerships are created equal. Spend 30 short minutes with us to learn:   • Key questions to ask when considering a partnership to accelerate your business into the cloud • Pitfalls and mistakes other partners…
Suggested Courses
Course of the Month13 days, 20 hours left to enroll

807 members asked questions and received personalized solutions in the past 7 days.

Join the community of 500,000 technology professionals and ask your questions.

Join & Ask a Question