VPNing is correct. The three lines listed should help. Been too long since I did this.
holyfrik -- this should help your problem as well.
Couple of clarifications: The 'MPG1' in the example refers to the netbios name of the server, and the references to 'MPG' would be a domain or workgroup name. You need the entries for each workgroup.
The spacing is critical in the sections with the \ IS critical. There must be exactly 15 characters between the " and the \, padding the extra characters with spaces. If we replace the spaces in the above example with #, it would look like "MPG############\0x1b". Also, make sure you use the correct slash, and the character directly after the slash is the number zero, not the letter O. These entries should come first in your lmhosts.
Now for your bandwidth issues. For what it is worth, the latency problem could be causing your browsing problem as well. Netbios doesn't play well sometimes.
Couple of things to keep in mind with DSL or any other 'high speed' connection. Your ISP (generally) sets two speed caps. One for downstream data (coming to you) and another for upstream data (going away from you). The upstream is generally a fraction of the downstream. This works well for web browsing, as most of the data is downstream. When you start networking, it can cause some problems because if you 'flood' your upstream bandwidth, your downstream will appear to cap at nearly the same time. This is related to how tcp works, and is not a real connection problem. When you download a large amount of data from a host on another DSL connection, you can easily flood it's upstream bandwidth and cause some problems.
I haven't been able to determine from your other posts, are you seeing slow pings under normal load, or just when you are transfering large files?
To pin this down a bit better, I would try a different twist on the ping.
Try 'ping -n 30 -l 128 xxx.xxx.xxx.xxx > testfile.txt'
The -n 30 does 30 pings instead of the standard 4, the -l 256 sends a 128 byte ping instead of 32 byte. The > testfile.txt sends the output to a file - you won't see the results on the screen. Use any name you like for testfile.txt, but you will want to do this several times, using a different filename each time, something that will allow you to remember which ping you were doing. You can open the files with notepad, wordpad, etc to view the results.
You will want run the entire set of pings both under a full load and under normal load. Run it a few times for each situation, changing the -l number to 256, 768, and 1024.
You also need to ping several different places. I would ping at least two hosts on each of your remote networks, and at least one on the local network. Also, ping the address of each of the remote routers -- this should give results for each location bypassing the VPN. Finally ping somewhere else on the internet, yahoo.com is fine. I would also run the tests from one of your other locations, if possible.
As you do the tests, if you see consistent timeouts as you increase the packet size in a particular situation (ie, the 768 packets get through, but the 1024 do not), somewhere along the line the packet size is being limited. Your own MTU values can do this, but there are several places the carrier (your ISP/telco) can change the MTU as well. Often not a lot you can do about it, other than change your MTU accordingly.
You should expect to see slightly higer values pinging through your VPN vs directly to the router, but not significantly higher. If you notice a big difference, something is going wild in one (or more) of your routers.
If you are downloading from one remote, and the results pinging that remote are much higher than when pinging the other remote, that's a good indication that you are flooding your upstream on the remote side. Not a lot you can do about that one, except set up something to throttle back your own bandwidth use or buy more bandwidth. If you get the MTU just right, might help some, but won't solve it completely.
Several other possiblities, but that should give you a start.
One other thing, try a 'tracert xxx.xxx.xxx.xxx > testfile.txt' for each of the situations above. Again, the 'testfile.txt' is any file you choose, and replace the xxx.xxx.xxx.xxx with each of the hosts that you are pinging. This will show you how the traffic is being routed. When you tracert to your remote networks, you should see each of your routers and the remote host with nothing in between. The high values should show up for the remote router. If not, the problem is somewhere on your side. When you tracert to the remote routers, you should see the full path your actual data is taking. If you see consistent high values for one of the hosts along the way, that is where your problem is.
Another of those really long posts, but it is a lot harder to explain what to do than it is to just do it. If you don't understand, post back and we will clarify.
