Shoretel phones, OpenVPN & One way audio.
-
So im beginning to bald with this issue. I'll do my best to layout what i have and how its all set up.
Arizona (AZ) Side-
-
Internal Network: 192.168.1.0/24
-
pfSense with OpenVPN: 192.168.1.31
-
OpenVPN Tunnel Network: 10.0.1.0/24
-
OpenVPN IP: 10.0.1.1
Arkansas (AR) Side-
-
Internal Network: 192.168.10.0/24
-
pfSense Router: 192.168.10.1
-
OpenVPN IP: 10.0.1.2
-
DHCP & DNS enabled
-
DHCP: Option 156/String is enabled and working
OpenVPN tunnel is working great. I have the two servers (AZ & AR) up and running without any issues. Network traffic is working back and forth, servers on the AR side are communicating as if they are sitting next to each other. My problems is with the Shoretel phones.
I've setup a phone on the AR side and they boot up, grab an IP address, download their config files and link up to your AZ shoretel server. I am able to ping everything from the phone to the network and vise versa. The issue is, when i make a call the AR side, im getting one-way-audio. The AZ side can hear everything fine, but when trying to talk back to the AR side we get nothing but silence.
In my rules, ive enabled the two networks to communicate (protocol: *, src: 192.168.1.0/24, dest: 192.168.10.0/24) on both sides. As soon as i sever that rule, the shoretel phones go down since they constantly ping back to the server to check for access.
I'm seriously at a loss here and ANY help would be HUGE on this since now im running up against my install date very soon.
Thank you and PLEASE let me know if ive left anything out, or you'd like me to try something on my end to see if it works. Im seriously ALL EARS!
-
-
My first guess would be a SIP issue on the Phone server (Asterisk? FreePBX? Elastix? other?) not knowing about the existence of the network on the other side of the tunnel.
Other than that make sure your rules allow all OpenVPN traffic.
Can you reach the WebGUI for each of the phones at the other end of the tunnel?
-
Sounds like your connectivity is fine. Next most likely is probably something in your PBX config related to NAT, where it's not seeing that remote subnet as a local network it should route to and trying to do something with its NAT functionality instead.
-
OP bought support and I ended up working through this issue with him. Turned out the problem was a Windows server involved in routing was blocking the traffic.
-
@cmb:
OP bought support and I ended up working through this issue with him. Turned out the problem was a Windows server involved in routing was blocking the traffic.
CMB you rock brother! Thank you for the help and yes it was a damned Windows server that was blocking the RTP traffic from ports 10k-20k. Once i created a rule on the windows server it opened it all up and everything is rocking.
Thanks again!