W8K Terminal Server can not Ping machine on VPN Lan

Trying to find this one for a while.  32Bit W8K Terminal server latest SP.
We have two domains  A: 192.168.1.x and B:192.168.20.x across a VPN, high latency up to 300mc. Using DNS for both sides and also Wins for netbios.  Records all loaded up .
Problem: when trying to access a server from domain A to B from a terminal server it is very slow and sometimes fails, but only from the terminal server.
When I do a ping on the TS the IP is resolved to the correct IP but then times out.
Then I do a tracert and the system will resolve in around 700-1000ms.
Do a ping agiain and now the system name resolves from the TS OK.
All other servers Win3K and Win8K do not have this issue and always resolve the ping right away.  
fullermetricAsked:
Who is Participating?
I wear a lot of hats...

"The solutions and answers provided on Experts Exchange have been extremely helpful to me over the last few years. I wear a lot of hats - Developer, Database Administrator, Help Desk, etc., so I know a lot of things but not a lot about one thing. Experts Exchange gives me answers from people who do know a lot about one thing, in a easy to use platform." -Todd S.

shadowmantxCommented:
What is your bandwidth speed?  use www.speedtest.net for down and uploads.
0
fullermetricAuthor Commented:
That's not the problem.  The sytems resolve fine from the other servers.  The RDP connections across the VPN run great, file transfers are up to 300kbps.
0
DonovanRojasCommented:
By the example you mention it seems that both systems do not know the route to each other until the tracert, I would suggest adding some routing to the client so it can define the right path to that specific host.
If you have more than one gateway within A or B networks this can create a lot of issues with what you want to do.

route print <----- will give you the default routing the host has

route add 192.168.20.0 mask 255.255.255.0 gateway YourIPGatewayOfTheVPNInterface metric 2    <--- will add a defined route for that network to your specific gateway, try this and if this ficxes it then upon reboot run it again adding -p to the coomad (route -p ADD ....) to make it persistent across boots, if it doesn't fix your issue then  you can delete the route with
route delete 192.168.20.0

if you don't want/like to modify routing on a specific machine then you would have to do this routing on the netwrok hardware (router)

0
fullermetricAuthor Commented:
Thought of that already, but we are just pointing at the same default gateway.
Tried is with the same result.
A ping will fail but if I do a   Run \\servername then the system resolves fine.
I seem to remember a similar behavior from my Terminal Servers on the LAN also.  Maybe some kind of GPF setting.  Everything is working fine now other than the Ping.

OK. found the iissue, kind of stupid of me not to think of this.
The ping test does not wait long enough for the initial connection to be established,
Did a ping -w 10000 Servername and it resolved and worked.
0

Experts Exchange Solution brought to you by

Your issues matter to us.

Facing a tech roadblock? Get the help and guidance you need from experienced professionals who care. Ask your question anytime, anywhere, with no hassle.

Start your 7-day free trial
fullermetricAuthor Commented:
Figured it out.
In a high latency situaiton the ping command needs to wait longer for the initial connection to be established though the VPN than normal.
0
It's more than this solution.Get answers and train to solve all your tech problems - anytime, anywhere.Try it for free Edge Out The Competitionfor your dream job with proven skills and certifications.Get started today Stand Outas the employee with proven skills.Start learning today for free Move Your Career Forwardwith certification training in the latest technologies.Start your trial today
DNS

From novice to tech pro — start learning today.