cjuel
asked on
Pix-Pix VPN comes up, but one not returning data
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?
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?
ASKER
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?
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?
>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..
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..
Hello? Any news?
ASKER
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
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
Thanks for the update!
ASKER
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?
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?
ASKER
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
remote ident (addr/mask/prot/port): (10.109.172.0/255.255.255.
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.
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
remote ident (addr/mask/prot/port): (10.109.172.0/255.255.255.
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.
>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..
>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..
ASKER
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
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
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>
nat (inside) 0 access-list <ACL>
the other applied to the crypto map
crypto map mymp 20 match address <ACL>
ASKER
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.
remote ident (addr/mask/prot/port): (192.168.255.0/255.255.255
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
remote ident (addr/mask/prot/port): (10.109.172.0/255.255.255.
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)
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.
remote ident (addr/mask/prot/port): (192.168.255.0/255.255.255
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
remote ident (addr/mask/prot/port): (10.109.172.0/255.255.255.
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)
ASKER
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)
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)
ASKER
Bumping up them points - I will be able to work this today and need an opinion on the last two posts.
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
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
ASKER
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
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
ASKER CERTIFIED SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
ASKER
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.
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...