After a successful IpSec tunnel is established with the ASA 5510 with Cisco VPN client, traffic is not passed through the tunnel

After successful connection of an Ipsec tunnel with the ASA 5510 and Cisco VPN client(I have used versions from 4.8 to 5.02), the tunnel is established. I can ping the inside interface of the ASA, but not hosts on the LAN
The tunnel will connect with transparent tunneling, IPSec over UDP, IPSeco over TCP port 10000, or without transparent tunneling. I have also tried NAT Traversal Command
I seen this with 3000 series concentrators, and it is usually a routing issue where packets traversing the tunnel can't find the default gateways of the remote LAN segments.
The following is the basic LAN topology:

There are static routes that route inside traffic from these networks to the inside interface of the ASA.
I am using an internal address pool of 192.168.3.85-90/24
I have tried all the nat0 access-lists scenarios to exempt the above subnets from translation, with no luck. I have an ASA 5505 on the network with an identical configuration, and it passes traffic fine, with the same nat0 access lists. (the 5505 has a 192.168.3.2 address for it's inside interface)

Could this be a routing problem, where the packets cannot find the gateways of the above LAN's? If I can ping the 192.168.1.1 which is the inside interface of the ASA, why can't the static routes send the packets to the default gateways inside the LAN if the correct nat0 access lists are exempting the above subnets from translation?
Also, I cannot telnet to 192.168.1.1 inside interface, even after adding the access lists;

I can't thank you enough. I overlooked the most simple thing, a different subnet.
I spent hours reading the Cisco ASA book by Jazib Frahim, and this was so simple. Since I just joined today, I need to understand the point system to award.
Please forgive me on this

The solution worked, I just rebooted the ASA. I tried with three different versions of Cisco VPN clients, with and without transparent tunneling. Hosts on all the remote LAN networks are now accessible. I even removed the sysopt connection permit-ipsec for additional security, so the decrypted packedts are inspected against the access lists
The different subnet did the trick.

Glad you got it all working out.
You would not have had to put any route statements in at all since this network is not in any route table, it would simply fall into the default route category on your switch, then it would be "connected" to the asa so it knows what to do with it.

-Cheers, and welcome to EE. I hope you find your journey a pleasant one.

thanks again. There have been so many posts in knowledge bases about this issue, may seem to have gone down the wrong path thinking it is the "nat0 nonat" access lists, which have nothing to do with routing.

This article will cover setting up redundant ISPs for outbound connectivity on an ASA 5510 (although the same should work on the 5520s and up as well). It’s important to note that this covers outbound connectivity only. The ASA does not have built…

Some of you may have heard that SonicWALL has finally released an app for iOS devices giving us long awaited connectivity for our iPhone's, iPod's, and iPad's. This guide is just a quick rundown on how to get up and running quickly using the app.
…

After creating this article (http://www.experts-exchange.com/articles/23699/Setup-Mikrotik-routers-with-OSPF.html), I decided to make a video (no audio) to show you how to configure the routers and run some trace routes and pings between the 7 sites…

After creating this article (http://www.experts-exchange.com/articles/23699/Setup-Mikrotik-routers-with-OSPF.html), I decided to make a video (no audio) to show you how to configure the routers and run some trace routes and pings between the 7 sites…