First - ask the to access the internet just to see their normal Internet access speed. Then ask them to ping some internal host. Then based on these results you can think about everything else.
Your question is too general - what is your VPN client ? How are they connected, etc. Be a bit more specific.
I'm having the same problem. My clients are using a 3002 HC connecting to my 3002 concentrator over ipsec. Each site has 768 dsl through Verizon. I can connect just fine using my software client from home using 128 dsl. Trying to access their client via the network connection is pretty slow. Anyone have a clue what to check for?
I can say that I have such an issue in my network. We have vpn Ipsec with a 1800 series router 512\1mbps and clients 837 with dsl 384\128. Although all the sites browsing internet very fast, the traffic inside the tunnels is very very slow... I have timeouts in almost every service of the network. If you ping the remote sites you get a very good reply but everything else (http,ftp, etc ) needs years to pass through and finaly timeouts..
Everything was working fine since we close the 1800 for a day because of a hardware upgrade in something else. After we powered the router again we have this strange behaviour...
The problem might be related to fragmentation and mtu. Without going into details, try setting the command ip tcp adjust-mss on the internal lan interfaces on both sides of the tunnel to e.g. 1330.
It might help
Checking the MTU fixed my problem.
I have multiple 3002's connecting back to a 3030 and only a few of them began complaining about timeout problems - specifically downloading email with large attachements from Exchange as well as large downloads from internal web servers.
I tested connectivity to each site with the ping utility. I set the packet size to 1500 and set the Do Not Fragment bit. The response was "Packet needs to be fragmented but DF set.". I began reducing the packet size until the ping completed. I changed the 3030's Public interface to this packet size (ended up being 1300), and chose the Fragmentation Policy "Fragment prior to IPSec encapsulation with Path MTU Discovery (ICMP)" and the problems disappeared.