VOIP Packet loss over Sonicwall VPN

I am having some issues with some phones and was hoping someone could hopefully point me in the right direction. I am not a phone guy by any means, so excuse any mistakes or anything that is unclear. Our past set up was as follows

Site A - Sonicwall NSA 250 M with Avaya IP Office 8.1
Site B - Sonicwall TZ 205 with 20x Avaya 9608 phones

The sites are connected via a Site to Site VPN.

A week or so ago, we swapped out Firewalls. We moved Site A's to Site B, and put a Sonicwall NSA 2600 at Site B. We did a simple export/import of configs. Even though they were different Firewall models, Sonicwall documentation said it was supported, and we haven't had any issues. Except one.

Our phones seem to experience call dropping and quality issues. We get 10x dropped calls a day, and inside IP Office I can see Quality of Service Alarms going off like crazy.

I have set up QoS and BWM on both sides of the Firewalls, I don't believe bandwidth is the issue.  It's ONLY my remote phones at Site B, which are all H.323 phones. But if someone from Site A calls Site B, there is a chance it will drop as well. Site A can call Site A all day, or externally, no issues. I played around with H323 transformations on the Sonicwall, and that actually seemed to fix the issue, but after enabling it my phones would deregister themselves after a few hours, and would not re-register.

I have set up wireshark on both ends, nothing out of the ordinary, no increase of traffic when issues comes up.

Our codec was set to 8kb previously, I changed it to a 64kb codex, and no change. I would think I would see 1/8th packet loss atleast, but I still get anywhere from 30-80%.

I've attached a picture of my QoS alarms. My phone system is .40.

I have gone over both Sonicwalls, switches, anything related over and over and I can't find out what the issue is. The rest of the network is fine. I can send data over that VPN just fine 24/7, no latency or packet loss.

Any help would be appreciated.
phones.PNG
inTheKnowSeaAsked:
Who is Participating?

[Product update] Infrastructure Analysis Tool is now available with Business Accounts.Learn More

x
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.

Blue Street TechLast KnightCommented:
Hi inTheKnowSea,

Although the config transfer is supported its a better practice to configure the security appliances from scratch.

Do you have the original VPN config annotated? I believe the settings transfer doesn't support S2S VPNs.
inTheKnowSeaAuthor Commented:
Yea I have actually loaded up the original Firewall and cross checked all settings, all are mirrored that I can tell.

The S2S definitely transferred, if that didn't work we would be dead in the water.
Blue Street TechLast KnightCommented:
OK, I want suggesting that the VPN config was not operable but rather that maybe the settings differed from the original.

Run a packet capture from the SonicWALL at the problem site during a call. That should pinpoint why the packet loss is occuring?

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
Choose an Exciting Career in Cybersecurity

Help prevent cyber-threats and provide solutions to safeguard our global digital economy. Earn your MS in Cybersecurity. WGU’s MSCSIA degree program was designed in collaboration with national intelligence organizations and IT industry leaders.

inTheKnowSeaAuthor Commented:
Ah ok I hear you. Settings are identical as far as I can tell.

I've done the packet trace, nothing out of the ordinary.

I'll run another one and post the results here when an issue pops up, maybe you can see something I am missing.
Blue Street TechLast KnightCommented:
Packet Capture within the SonicWALL will show every packet and its result so if you are having packet loss it will show you the reason why.
inTheKnowSeaAuthor Commented:
So I don't know how I missed it before, I may of just gotten confused after the hours of looking at packets.

But what I saw today was UDP Traffic being blocked from the phones from the Site A's Sonicwall, reason being UDP flood protection.

I have disabled UDP Flood Protection, and will see if that resolves the issues. If I don't see any problems by COB today I will be quite happy.

I will let you know how it goes, thank you.
arnoldCommented:
You have to make sure to setup qos to prioritize VoIP traffic, you should also exempt/exclude VoIP traffic from ALG/dpi

The qos within the VPN to reserve VOIP class traffic ......
arnoldCommented:
See if the following helps even if it is not your provider.

http://www.voiply.biz/voip/43-how-to-use-sonicwall-with-voip.html

Check your VoIP provider site for similar suggestions, recommendations.
inTheKnowSeaAuthor Commented:
QoS was my first thought, and got that handled so it wasn't that,

The issue ended up being UDP Flood Protection. Don't know how I missed it, but the packet monitor on the Sonicwall lead me to the issue.
inTheKnowSeaAuthor Commented:
Looking at the packet monitor, only packets being dropped were because of UDP Flood Proection. Disabling it resolved all phone issues.
Blue Street TechLast KnightCommented:
Glad I could help...thanks for the points!
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
Avaya

From novice to tech pro — start learning today.