One-Way Audio via VPN on VOIP
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.
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.
ASKER
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.
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.
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 192.168.1.58/24, 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.
>>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.
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.
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.
ASKER
@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.
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.
ASKER CERTIFIED SOLUTION
membership
Create a free account to see this answer
Signing up is free and takes 30 seconds. No credit card required.
ASKER
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?
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?
Please also try the PING/TRACERT excercise when connected directly to the cable modem.
ASKER
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.
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.
SOLUTION
membership
Create a free account to see this answer
Signing up is free and takes 30 seconds. No credit card required.
ASKER
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.
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.
ASKER
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!
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/protocol
That's my 2 cents.