VOIP Over VPN (30Second call drops)

grunger106 · ‎12-17-2011

Hi

I have a 887 setup as a EasyVPN server, and a 861 as an EasyVPN remote - network extension mode with split tunnelling.

This works fine - I can ping and connect to machines across the tunnel.

However if I setup a VOIP handset to connect across the tunnel it registers and calls work, but drop after 30secs....

I know this is normally a firewall or nat problem, are easyvpns firewalled or natted?

Or am I doing something else wrong?

Thanks

adam.sibille · ‎12-17-2011

To be honest, if you can connect to machines across the tunnel, I don't see it being a NAT issue. If it was a NAT issue, the traffic would be more of an all or nothing type scenerio.

Firewall could be blocking something, but that doesn't make sense in my mind either since you are making the initial connection with the call. So based off that logic, it would seem that no firewall rules would be blocking VOIP. Have you checked the syslog on the EasyVPN to see if there's some sort of deny going on?

The only thing that makes sense in my mind is the possiblity of the tunnel timing out or your link gets saturated with traffic and the voice call gets dropped. What you're explaining makes me think that it is a saturation issue with traffic going across the tunnel between the sites. Have you tried setting up QoS to dedicate bandwidth for your VoIP traffic? I had a simmilar issue once with a remote site (not exact the same setup as what you have, but it was VoIP across ipsec tunnel) and it ended up being lack of bandwidth dedicated to voice across the tunnel.

grunger106 · ‎12-18-2011

I haven't done any QOS, but as its exactly 31seconds everytime I think its the normal SIP - NAT/Firewall timeout issue, I just can't see where

I haven't done anything firewall wise to do with the VPN, just setup the server and client ends...

Do I need to allow traffic specifically, or does it allow all by default?

But as I can do everything else - RDP to machines at the remote end etc, it must be something to do with SIP....

grunger106 · ‎12-18-2011

I haven't done any QOS, but as its exactly 31seconds everytime I think its the normal SIP - NAT timeout issue, I just can't see where

(To quote the issue - 'The first trick is to keep open the hole in the NAT from the SIP client to the server. This is normally done by making all SIP clients use a two byte packet which is sent more often than 30 seconds. Some routers remove apparently unused NAT mappings after 30 seconds')

I haven't done anything NAT/firewall wise to do with the VPN, just setup the server and client ends...

I kind of assumed that over a VPN there would be no NAT? - If there is can it be disabled?

Do I need to allow traffic specifically, or does it allow all by default?

But as I can do everything else - RDP to machines at the remote end etc, it must be something to do with SIP....

adam.sibille · ‎12-19-2011

Do you have a config that you can post for review?

Since it is exactly 31 seconds everytime I think we can rule out a saturation issue and start looking at translations being closed causing the calls to drop as you stated.

You could create a NAT exemption rule and see if that works, but if your traffic is going across both ways, it seems that may already be created.

grunger106 · ‎12-20-2011

Yes - I'll have to dig the router out of its box - but will post a config.

What is confusing me is - my understanding of EasyVPN in NEM mode that there was no NAT/PAT, that was only in Client mode?

grunger106 · ‎12-20-2011

Yes - I'll have to dig the router out of its box - but will post a config.

What is confusing me is - my understanding of EasyVPN in NEM mode that there was no NAT/PAT, that was only in Client mode?

grunger106 · ‎12-21-2011

Solved it -

The PBX (An Epygi Quadro) has a NAT-T setting of its own, added the remote subnets to the exclusion table set the remote extension to RTP-PROXY mode and bingo.

Basically it was trying to do NAT-T for LAN traffic and the ACK wasn't being returned.

grunger106 · ‎12-21-2011

Solved it -

The PBX (An Epygi Quadro) has a NAT-T setting of its own, added the remote subnets to the exclusion table set the remote extension to RTP-PROXY mode and bingo.

Basically it was trying to do NAT-T for LAN traffic and the ACK wasn't being returned.

So nothing wrong with the routers at all

adam.sibille · ‎12-21-2011

Good job. I'm glad the exclusion rules solved it.