Site to Site VPN - not passing audio traffic properly
-
So the title kind of sucks, but here it goes.
I have 2 sites. Office (Edge router) and COLO (Edge router). I have my PBX down at the COLO. I previously connected my phones at the Office to the PBX down at the COLO via public IP. (Meaning the phones connected to the public IP of the PBX) No NAT down at the COLO. Everything was working perfect.
I now setup a site to site VPN between the 2 sites. Now, whenever I have a phone call, I have 1 way audio.
The office network is a 10.0.0.x/24 network, and the only thing I can think of right now that would be causing this, is the static rule that I setup down at the COLO firewall that says anything destined for 10.0.0.x/24, route out interface VTI0. But why is the audio trying to be sent to the 10.0.0.x/24 network in the first place? Shouldn't Asterisk be sending the audio back to the public IP address:port at my office? I wouldn't think that it should be trying to send it through the VPN tunnel.
I have to do some packet captures at multiple points here to really pin point what is going on, but has anyone else ever experienced this?
**Side note: If I change my phone IP to 10.0.5.1/24 (different local subnet), the audio traffic works perfectly.
-
@fuznutz04 what happens when you disable the routing? Does it work? If it does then you can pinpoint it to your routing making it all go through the other end of the VPN WAN.
-
Open
sngrep
on the PBX and look at the packets. You will likely are the traffic heading for the 10.Enable NAT everywhere.
-
@dbeato said in Site to Site VPN - not passing audio traffic properly:
@fuznutz04 what happens when you disable the routing? Does it work? If it does then you can pinpoint it to your routing making it all go through the other end of the VPN WAN.
Yep disabling the VPN (disabling the VTI interface on my office router ) immediately makes it work. So technically, I didn't disable the route, but I downed the VPN tunnel.
On the Edge router, is it possible to route just the SIP and RTP traffic out of the public interface and NOT have that specific traffic go through the tunnel?
-
This one was interesting to get to the bottom of. @JaredBusch With the VPN tunnel enabled, the phone system was trying to send RTP to the phone on the internal IP. There is a setting in FreePBX on the extension level called "RTP Symmetric". Normally, this is set to yes. I changed it to no and the audio started flowing normally. However, I didn't like this solution. So, as a test, (and what I should have done from the beginning) I blocked all outbound traffic FROM my phone system, to any local network. (10.x, 172.16, 192.168, etc) This immediately solved the issue. I did not yet do a packet capture AFTER the fact to confirm, but I am assuming that blocking the PBX's ability to get to an internal private IP, forces the system to renegotiate and send the RTP to the correct public IP.
Definitely an odd issue.
-
@fuznutz04 said in Site to Site VPN - not passing audio traffic properly:
This one was interesting to get to the bottom of. @JaredBusch With the VPN tunnel enabled, the phone system was trying to send RTP to the phone on the internal IP. There is a setting in FreePBX on the extension level called "RTP Symmetric". Normally, this is set to yes. I changed it to no and the audio started flowing normally. However, I didn't like this solution. So, as a test, (and what I should have done from the beginning) I blocked all outbound traffic FROM my phone system, to any local network. (10.x, 172.16, 192.168, etc) This immediately solved the issue. I did not yet do a packet capture AFTER the fact to confirm, but I am assuming that blocking the PBX's ability to get to an internal private IP, forces the system to renegotiate and send the RTP to the correct public IP.
Definitely an odd issue.
nice you found a solution - I'm curious why it happens in the first place? Are some of the original phone's packet data still containing the original IP? And if so, why?
Are you using encrypted RTP?