What could cause the whole LAN not to respond a Ping?

We have only one server (Win 2008 R2)  in our site A's LAN with its own domain/forest. This server is a DC and DNS. Site B has its own domain/forest as well.
Between A and B is a site-to-site VPN by a Sonic Wall (in A) and a Cisco ASA (in B). During the most of off-hours when no users access the network resources, I found from B I can NOT ping any A's computer or device using their internal IP. At the same time I can NOT ping the Sonic Wall's internal IP address either while however I can ping its public IP address. (Of course during the work hours when users connect I can ping everything at A from B.)
At this moment, to my surprise I still can use Logmein to access one of the computers inside A. And then from there when I ping any B's host name (not IP, see note below), it will get response normally, and the most amazing thing is, as soon as the ping gets the first response, the above issue gets resolved immediately until hours later (still during off-hours) the issue will occur again. Is it something to do with the server, the Sonic Wall, or some kind of sleep mode, or what? I just totally have no clue. The server doesn't put hard drive to sleep.

Why does this issue happen? Can you shed some light?

Note: If I instead ping any host in B using IP address when Logmein to A as mentioned above, it will get responses normally but it will NOT do any good to resolve the above issue. So strange, right?
CastlewoodAsked:
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.

Craig BeckCommented:
The IPSec tunnel is timing out at the Sonicwall.  You should set it to persistent, nailed-up, or whatever else the Sonicwall calls it.
0
QlemoBatchelor, Developer and EE Topic AdvisorCommented:
The issue should be resolved indeed with an always-up VPN; Dead Peer Detection (DPD) usually prevents the tunnel going idle completely.
However, there is an issue with the Cisco config on Site B. It seems to offer different proposals then it allows if the SonicWall initiates tunnel negotiation. Compare the encryption etc. settings on both sides; ASA might offer a lot of proposals, and the correct one is more to the end of the list probably, far beyond what the SonicWall and the RFC standards allow.
0
Ricky MartireIT Design ArchitectCommented:
Check that both ends of the VPN have exactly the same details.  This sounds very much like the SA life time is not set to the same on both sides.
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
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
Windows Networking

From novice to tech pro — start learning today.

Question has a verified solution.

Are you are experiencing a similar issue? Get a personalized answer when you ask a related question.

Have a better answer? Share it in a comment.