For about 30 minutes throughout the day, when I try to ping any of the IP address's on the remote end, I get "destination net unreachable" with the gateway address of the main site.

When this is occuring, we still have a good VOIP connection, the calls sound good.

On another note, we are also losing speech path after about 1-2 minutes into the call.

VPN. Not the miracle cure for VoIP it's thought to be. Been dealing with this quite a bit lately.

Do you have filtering/stateful-inspection turned on for the VPN? What is the packets per second rating with the applied filters (if any)? How many concurrent calls are we talking? Is the problem just the far-end VPN SIP phones or is it systematic I.E. everything on the VPN crashes or goes unreachable? Is there some kind of SIP application helper (breaker)? What kind of bandwidth and connection is this VPN travelling over the last mile at each location? Is there a decipherable pattern to the outages either in terms of time of incident, length of incident, repition of incident after initial occurrence, etc. Did we remember to pour beer into the Mr. Fusion along with a banana peel to power the flux capacitor?

Lots of information is needed to start getting to some potential problem areas. That being said, here is some general advice from my own experience with VPN's and SIP.

SIP will broadcast 100 packets per second per call. They are all small 192-byte packets too, the kinds that routers have issues with in high doses for some reason, moreso if it's UDP instead of TCP. More about this later.

SIP Application helpers usually break SIP. I have almost never seen a successful SIP option in a router. This usually causes crossed calls, calls to bomb and/or time out, one-way audio, and phantom calls. You are almost always better disabling this. The SIP application helpers should always be the method of last resort after everything else has been tried.

Higher levels of encryption are not your friend. While all router manufacturers like to fill their marketing with their aggregate bandwidth numbers at whatever encryption levels this never applies to SIP/RTP. As I said earlier, SIP with ULaw RTP is sending fifty (50) 192-byte packets per second for every audio leg of a single call. That results in a total of 100 packets per second per call. This is even further compounded if your SIP is all based on UDP as the router now has to do a checksum on the packet, then de/encapsulate it to/from TCP for VPN transmission. All those marketing bandwidth numbers are based on a 1500-byte packet (Standard Ethernet MTU). If your router vendor doesn't tell you how many packets per second it can do at different encryption levels then just divide the aggregate bandwidth number by 1500-bytes and that's a good ballpark number. The real problem here is the processing power of the device. If it cant run fast enough to keep up with the packets then it will do one of two things: Drop packet, or queue/congest them till they either expire (TTL) or the application assumes no connectivity. The end result is usually the same and you end up with destinations unreachable.

The physical connection to the CPE can cause issues. If whatever is terminating on the client end cant handle the packets per second or a single packet of 192-bytes then you end up with even more mysterious problems. Most newer technology will further encapsulate a packet and send it as multiples if it is too large to fit within a single frame on the wire.

That's all I could think of off the top of my head though. Unless there is a technical issue with it I would try configuring a phone to work across the regular internet and seeing if the problem goes away. If it does then it's definately VPN-related. If it persists then it's router or data-connection related.

WOW!

What a mouthful, kumba!

We have a vendor meet scheduled with the IT support rep. & Watchguard tech support. So I will be more forhcoming with details.

I do not have the cisco switch model numbers handy right now, however, there are two of them involved...

When I move my patch cable from one to the other, I get NO speech path...

This is a work in progress & we have no love from the customers IT support company...I just wanted to throw this out for now......

Thanx for your most informitive reply with my "limited" info...

No problem. Hopefully you have some good ammo to fire back off at them.