Improve company productivity with a Business Account.Sign Up


One-Way Audio via VPN on VOIP

Posted on 2010-11-10
Medium Priority
Last Modified: 2012-05-10
Hello Experts,

I have an issue with a new Dual-WAN device we just put in, an XRoads EdgePro 100.  With the EdgePro, we use a form of OpenVPN for the VPN client.

We're experiencing an issue where remote users will get one-way audio, and the only way to resolve it is to remove all connections to their router, start XLite and force it to not find a network, then reconnect the network connections, dial VPN, then have XLIte connect to their VOIP server (Ensercle).

Once they do all that, we now get audio.  After running a wireshark capture while the one-way audio issue is happening, it appears that on the users' machines, XLIte is sending the outbound packets to their network adapter (gets lost), and the inbound packets are coming through the VPN virtual adapter (can hear audio).

I've worked with the router and done all I can to force VOIP traffic out one WAN connection, and the engineers at XRoads tell me there is no NAT taking place on the VPN connection, that it's a straight connection.

All other services like RDP, and email all work fine over these VPN connections.  The one-way audio is the one sticky point we can't seem to resolve.

As the XLite is free software, there is not much to configuring it.  Is there some way to force XLite to send and receive traffic from a specific adapter?  Or, is there something on the XRoads router that I'm missing?

Any guidance or assistance that can be provided would be much appreciated.  This is an issue that we are running out of time on, so I'm going to offer max points on this.  

Thanks Experts, I really look forward to hearing back on this.

Question by:HelpfulAdvisor
  • 6
  • 3
  • 3
LVL 33

Expert Comment

ID: 34108791
I recently had an issue just like this with a cisco voip installation where we had 1 way audio over a VPN.  

It turned out that there where access-lists that were blocking the audio traffic in one direction.   Once we found the offending ACL and added permissions for the traffic, it was cleared up instantly.  

I would suggest following the traffic across all hops and check each device for allowed traffic/IPs/ports/protocols and see if any of the devices are policing the traffic.  

That's my 2 cents.

Author Comment

ID: 34108897
Hi MikeKane,

Thank you for your reply.  I've asked the XRoads engineers about any sort of NAT issues or access lists, and they say with VPN, it is a straight-connection into the network unhindered.

Could the issue be with the users' routers?  Even with a VPN tunnel from the users' laptops/desktops through their router into the corporate network, could the NAT on the users' end be at issue?

A wireshark capture showed that the audio traffic is trying to go out the primary network adapter, while the inbound audio is coming through the virtual VPN adapter.  So, could there be something going on with the users' routers not forwarding the packets?  

Or perhaps a route that I can or should hard code onto the users' machine to force traffic through that virtual interface?

Any ideas would be welcome on this.  
LVL 33

Expert Comment

ID: 34108920
If the VPN is terminated at the client (i.e. a client VPN, cisco anyconnect, greenbow, etc...) then the traffic that is captured at the client is defined at the VPN endpoint.   That way only the traffic that should be captured into the VPN is sent across the vpn.   So, you should look at the VPN definition and make sure that the client is capturing the destination IP into the tunnel.   So if the client is sending audio to, then the vpn client should show that subnet being captured.   Many times, the client will be sending traffic to a NAT'd address which can complicate matters, but remember that the source ip and destination Ip are from the users POV.

>>A wireshark capture showed that the audio traffic is trying to go out the primary network adapter,

That tells me that the destination for the audio traffic is not defined properly in the client's VPN setup.
Improve Your Query Performance Tuning

In this FREE six-day email course, you'll learn from Janis Griffin, Database Performance Evangelist. She'll teach 12 steps that you can use to optimize your queries as much as possible and see measurable results in your work. Get started today!


Expert Comment

ID: 34126353
Was the VPN client softphone working previously, before the dual WAN? are you using Dual WANs? is the VPN client setup on the Xroads set to use both WAN links? Are you assigning Internal, routable IP addresses to your VPN client endpoints?  Which direction is the audio working?

It seems to be one of these two possible issues:
1) the VPN client may be using both WANs to complete the traffic connection, inbound down one WAN back to the VPN client via the other.  This setup does not work with VoIP.  Try disabling one WAN, have everything routed/connected to only the primary WAN and see if two way audio can be achieved.
2) the Xlite software or the VoIP PBX is not reporting the correct IP address of the phone client, i.e. even though connected by VPN, the Xlite is reporting either the global IP address of the router or the remote user's Internal IP address as the phone client endpoint.  You need to make sure the VPN end client assigned IP address is reported as the VoIP endpoint to the VoIP server.


Author Comment

ID: 34142273
@MikeKane, thanks for the additional insight.  Sorry I've taken so long to reply.  I have been doing nothing but trying to see why this won't work.  I've run my own wireshark captures, but can't seem to figure out what the missing link is.  In some CounterPath message boards, I'm reading about RTP being a necessity, and I don't see any RTP packets coming from the client side PC.

However, here's something interesting.  If I use the OpenVPN client to connect to the office, I get a symptom where the distant end can hear me, but I cannot hear the distant end.  If I connect using PPTP, I can hear the distant end, but the distant end can't hear me.

I'm not sure how to shape the VPN clients to allow what needs to happen.  I keep getting told by the manufacturer of this dual-WAN device that all ports are open in a VPN connection.  Another interesting tidbit: One-way audio only happens when I'm behind my own firewall.  If I bypass the firewall and connect directly to the cable modem, I can make a two-way audio call via VPN just fine.

I thought a VPN tunnel bypassed NAT rules as I get a dedicated IP that is routable within the network.  Wouldn't that be the case?

@Cordeos: Thank you so much for the questions.  Here's what I know.  They tell me the softphones worked with a Cisco ASA appliance in place, and using the Cisco Anyconnect client.  

The new VPN client only connects on one link at a time, and fails over to the other link if the link goes down.  Yes, the addresses are internally routable... meaning the subnet for the VPN clients are recognized by the gateway/router and any address assigned a VPN user is routable from within the network.

The audio works where the distant end can hear me, but I cannot hear the distant end.  I'm sorry, but I don't quite follow your second point.  If you wouldn't mind clarifying a bit, i would appreciate it.  I should tell you that I'm not able to make any changes to the PBX, as it is under contract with the provider, and they have been very little to no help at all, and barely want to support their own system as it is.

Also, I have two ways to connect via VPN on the same router.  One is an OpenVPN client, and the other is a PPTP connection.  If I connect via OpenVPN, the distant end can hear me, but I cannot hear the distant end.  That connection gives the VPN users a secondary routable subnet.

If I connect via PPTP, the issue is reversed.  I can hear the distant end, but the distant end cannot hear me.  For that connection, I am on the same subnet as the rest of the LAN users.

If I bypass my own router/firewall at home, and plug directly to the cable modem, audio works perfectly.  And this I have tested with myself and one other user. and the is this the same for both of us.

Any other insight or suggestions are most welcome.  Thank you both, and I hope to hear from you soon.

Accepted Solution

cordeos earned 1000 total points
ID: 34142321
In your VoIP PBX system, are you able to see the "registration" of the softphone to the system, and does it show what IP address it believes the softphone is at?    In general, most VoIP softphones will only work reliably with an assigned, routable IP address for the VPN client endpoint.  PPTP will not work.

You need fully routable there/back traffic for this to work, so can you try the following:
connect to the office with the VPN client
PING and TRACERT from the client PC to the VoIP server (or any machine on the same LAN)
PING and TRACERT from the VoIP server (or any machine on the office VoIP LAN) to the VPN Client's assigned routable IP address

Do both the above work?  Do you get the same (inverted) TRACERT pattern?

Author Comment

ID: 34142400
Hi cordeos: Ok, you may be on to something here.  I did a ping, and from my client PC, I can reach the PBX server.  However, I cannot reach my client PC from the server, I can only ping as far as the gateway IP for the subnet of the VPN.

However, if I can make a good call from connecting directly to the cable modem from my client, PC, how come I have good audio?  I am still using VPN to connect that way and yet the VOIP system doesn't seem to have a problem with audio when I connect that way.

What would you say is next?


Expert Comment

ID: 34142499
Please also try the PING/TRACERT excercise when connected directly to the cable modem.

Author Comment

ID: 34145018
cordeos: I was able to get a good ping and tracert from the VOIP server back to my client.  I had to disable Windows firewall and my PC could now accept ping requests.

Each way, the route is only two hops.  Yet, when I place a test call, I cannot hear the distant end, but the distant end can hear me.
LVL 33

Assisted Solution

MikeKane earned 1000 total points
ID: 34146823
>>I thought a VPN tunnel bypassed NAT rules as I get a dedicated IP that is routable within the network.  Wouldn't that be the case?  

This is true for the most part.     You would get an ip assigned to you from the local IP pool defined at the endpoint.   And since I see above that the pings are working to and from but you still have the audio issue.  

With VOIP systems, once the phones negotiate the call, its all phone to phone communication.     And in my experience, everytime I've had one way audio issues, it turned out to be a layer 3 issue related to ip routes or ACLs blocking or misdirecting packets.    

Would it be possible to wireshark both ends of the call and match up the 2 ends to see if the other end ever 'sees' incoming packets?  

If there are dropped packets somewhere, then I would turn on some elevated logging on the vpn appliance and any in between hops to look for drops or other clues.

Author Comment

ID: 34178095
Hi Guys,

Sorry for my delay in replying.  It seems I've found a fix.  As I'd been saying all along, it wasn't the VPN or the routing.  However, the tips for pinging the VOIP server from a VPN connection and trying it the reverse opened up an idea for me.

Although we'd been handed the settings for the softphone from the VOIP service provider, everything they've told me up to that point had been pretty much worthless, so I figured their settings would be of equal non-value.

I changed settings on the softphone to tell the softphone where the VOIP server is by IP address and implemented a bug fix that was documented on the VOIP provider's own website (which the service techs failed to mention even existed, and I ended up finding it on my own).

After that, it worked like a charm.  As I knew the packets weren't making their way back to the VOIP server, I knew that if I could find a way to force that path, we would be good.  Because you both helped me with the diagnosis of making sure my data paths and routes were correct, which led me to the solution, I'd like to split the points if that's ok.

Thank you both for your patience and for helping me go down the path that led to a solution of a month-long issue.

Author Closing Comment

ID: 34178104
Thanks to the expert diagnosis methods from these two experts, I was able to solve a month-long issue in just a couple of days.  Thank you!

Featured Post

KuppingerCole Reviews AlgoSec in Executive Report

Leading analyst firm, KuppingerCole reviews AlgoSec's Security Policy Management Solution, and the security challenges faced by companies today in their Executive View report.

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.

Join & Write a Comment

This article offers some helpful and general tips for safe browsing and online shopping. It offers simple and manageable procedures that help to ensure the safety of one's personal information and the security of any devices.
In this article, WatchGuard's Director of Security Strategy and Research Teri Radichel, takes a look at insider threats, the risk they can pose to your organization, and the best ways to defend against them.
Windows 10 is mostly good. However the one thing that annoys me is how many clicks you have to do to dial a VPN connection. You have to go to settings from the start menu, (2 clicks), Network and Internet (1 click), Click VPN (another click) then fi…
When cloud platforms entered the scene, users and companies jumped on board to take advantage of the many benefits, like the ability to work and connect with company information from various locations. What many didn't foresee was the increased risk…

606 members asked questions and received personalized solutions in the past 7 days.

Join the community of 500,000 technology professionals and ask your questions.

Join & Ask a Question