banner motd ******************************************************Unauthorised access is strictly prohibited and will beprosecuted to the full extent of the law.******************************************************

First, change this to a proper next-hop address: ip route 172.16.0.0 255.255.0.0 GigabitEthernet0/1. This is just a pet peeve of mine and is responsible for many problems unless it's on a p2p type link.

Second, I never advocate using the "wizards" (without doing a lot of cleanup/manual customization immediately after running it) because the config becomes very cluttered with a lot of features you likely aren't using.

Third, the access-lists referenced by the crypto map on the outside interface seem odd but I don't know enough about your network to really make a determination.

Forth, off-hand your NAT and ZBF rules look okay. Typically at this point I would just skip to a packet capture on either side if available but you can start with "show policy-map type inspect zone-pair..." and see if the inspection engine is catching your traffic. If you are running something like a constant ping and you don't see it in the output you know the traffic is being denied or redirected before it is hitting the inspection engine. Keep in mind what the order of operations is for traffic with complicated interface configs:

If you follow the ZBF config though all those nested classes you'll eventually find that ICMP sourced from inside (using NBAR to determine the traffic type) has an inspect action applied to it. There isn't a drop action or anything referencing a source IP so that doesn't seem to be the problem. If you have some maintenance time you could always pull the zone-member commands off the interfaces to be sure.

Anyway, I think the problem is elsewhere. What does the rest of your topology look like? If you have a L3 switch adjacent to the router you could always set up a SPAN session and see what traffic is actually being sent between the devices or do an actual packet capture on the router (since you have a recent IOS).

I have attached an very basic network diagram with the routing and interface config.

I think routing is working OK as I can ping the different network ranges from internally.

It's looking like it may be a natting issue on the router. I really hate the way the CCP wizard has over complicated the config. When I added a VPN using a wizard it has changed the natting to use a route map. Something I know nothing about.

I spent some time today playing around with the config trying to undo the wizards config. I removed everything to do with NAT and recreated a standard access list allowing 10.20.0.0 0.0.255.255 and 172.16.0.0 0.0.255.255. I added "log" onto the end of each entry.

I then made sure inside and outside interfaces where set. Lastly I created the NAT rule to source from the new standard access list and overload.

I did some test pings and pings work from the 10.20 range but again not from the 172.16 range.

I did a "show ip access-list NAT-LIST" and I could see the log number increasing for the 10.20.0.0 range but nothing had been logged for the 172.16.0.0 range.

I even tested the above nat config whilst the router interfaces where not part of a firewall zone.

Looking at the running config is only useful to a point. You need to delve deeper with show commands, and if you're still having issues, some debugs. You could always lab this up as well so you're not messing with "prod" equipment or have TAC help you with the debugs if you aren't comfortable. Remember that if you want to do something like debug ip packet (with an ACL hopefully) you'll need to disable cef on the related interfaces to see transit traffic. Bear in mind you can blow up the router if there is even a small amount of traffic on it and don't debug to the console... send it to syslog or the buffer.