Asterisk behind pfSense/OMR Outbound VOIP One Way Audio

[Network-Traditions]

Expected Behavior

Orginating an outbound VOIP call through an Asterisk server behind pfSense configured as no-NAT router to OMR to VPS to SIP Trunk to a phone and having two way audio.

Current Behavior

Orginating such a call results in a successful connection with no audio on the receiving phone while the originating phone can hear both sides of the conversation (AKA One Way Audio).

SIP signaling seems to be working perfectly with a v2ray port forward to the internal Asterisk server with the appropriate static route. Experienced the same results when using a vpn port forward with and without SNAT rule for the Asterisk server / OMR interface.

RTP/UDP port range audio seems to be working perfectly for inbound calls with a vpn port forward to the internal Asterisk server, again with the appropriate static route. Outbound calls in this configuration successfully make the connection, however, the called party has no audio while the calling party hears both sides of the conversation. Configured with or without a RTP/UDP SNAT rule for the Asterisk server / OMR interface the results remain the same. Inbound calls work perfectly with or without. Uninstalling kmod-nf-nathelper-extra had no effect as does checking or unchecking SIP ALG.

Packet captures on the OMR LAN interface (eth0) document two way audio UDP traffic in the appropriate port range, however, packet captures of the OMR tun0 interface show only the inbound (internet to asterisk server) audio packets. The outbound packets seen on eth0 are not making it to tun0.

Realized the Asterisk portrange was being randomized by NAT in one direction so my conclusion about missing packets was incorrect.

Specifications

Asterisk - pfSense - OMR - VPS - SIP Service - PSTN

OpenMPTCProuter: v0.59.1-5.4 r0+16594-ce92de8c8c OpenMPTCProuter VPS version: Debian 11 5.4.207-mptcp VPS 0.1028 Architecture: x86-64 OpenMPTCProuter VPS provider: IONOS.com 2 vCore 2GB RAM "Type M VPS" OpenMPTCProuter platform: x86_64 (HUNSN FNR-RS34G https://www.hunsn.com/item/network-security-firewall/pfsense-mini-pc)

ISPs: T-Mobile 5G Business Internet with static publicly reachable IP StarLink version 2 configured as Ethernet bridge

[ccmks]

Which method are you using for UDP, the VPN or V2RAY?

[Network-Traditions]

VPN .

---

From: ccmks @.***> Sent: Wednesday, September 28, 2022 6:46 PM To: Ysurac/openmptcprouter Cc: Network Traditions LLC; Author Subject: Re: [Ysurac/openmptcprouter] Outbound VOIP RTP/UDP Packets Disappearing (One Way Audio) (Issue #2583)

Which method are you using for UDP, the VPN or V2RAY?

-- Reply to this email directly or view it on GitHub: https://github.com/Ysurac/openmptcprouter/issues/2583#issuecomment-1261642606 You are receiving this because you authored the thread.

Message ID: @.***>

[ccmks]

Does it work if you have pfsense straight to internet without OMR?

[Network-Traditions]

Yes, before deploying OMR, our system was operating with pfSense configured with NAT connected by cable modem to the internet.  Asterisk RTP/UDP port range required a NAT forwarding rule for inbound audio but outbound was allowed by default unless specifically blocked.

This new configuration adds OMR as the NAT firewall and pfSense as a non-NAT static router.  The inbound packets are making it all the way to the Asterisk server and on to the VOIP handset, functioning as expected.

Sent from Nine

---

From: ccmks @.***> Sent: Wednesday, September 28, 2022 6:55 PM To: Ysurac/openmptcprouter Cc: Network Traditions LLC; Author Subject: Re: [Ysurac/openmptcprouter] Outbound VOIP RTP/UDP Packets Disappearing (One Way Audio) (Issue #2583)

Does it work if you have pfsense straight to internet without OMR?

-- Reply to this email directly or view it on GitHub: https://github.com/Ysurac/openmptcprouter/issues/2583#issuecomment-1261646428 You are receiving this because you authored the thread.

Message ID: @.***>

[ccmks]

What is the asterisk flavour are you using?

Per my experience, I am using FreePBX. Whenever, I am trying to use OMR behind FreePBX, I have to change the IP Public point to VPS, in FreePBX asterisk sip settings. Have you changed your asterisk to use VPS IP Public?

[Network-Traditions]

Yes the IP is set to VPS.  Asterisk is working correctly.   Inbound calls are fully functional for all SIP trunks.  Outbound is fully functional for our Google Voice service with an Obihai adapter which handles all the external traffic via pfSense/OMR.  Outbound is fully functional for our Flowroute trunk except for the no audio on the external phone.  Flowroute uses "direct audio" RTP/UDP which does make things more challenging for inbound calls as a NAT port range from any IP must be implemented for audio.  Outbound not so much since pfsense and OMR allow outbound without restriction by default. 

---

From: ccmks @.***> Sent: Wednesday, September 28, 2022 7:57 PM To: Ysurac/openmptcprouter Cc: Network Traditions LLC; Author Subject: Re: [Ysurac/openmptcprouter] Outbound VOIP RTP/UDP Packets Disappearing (One Way Audio) (Issue #2583)

What is the asterisk flavour are you using?

Per my experience, I am using FreePBX. Whenever, I am trying to use OMR behind FreePBX, I have to change the IP Public point to VPS, in FreePBX asterisk sip settings. Have you changed your asterisk to use VPS IP Public?

-- Reply to this email directly or view it on GitHub: https://github.com/Ysurac/openmptcprouter/issues/2583#issuecomment-1261682094 You are receiving this because you authored the thread.

Message ID: @.***>

[Kalimeiro]

SIP signaling seems to be working perfectly with a v2ray port forward to the internal Asterisk server with the appropriate static route.

Which method are you using for UDP, the VPN or V2RAY?

VPN .

if you use V2RAY and think RTP/UDP travel to the VPN, it's wrong because we have an issue with 0.59.1 and it's impossible to disable V2RAY UDP, you need to use the latest snapshot or apply manually the patch to be able to disable V2RAY UDP or connect to ssh and disable manually V2RAY UDP with uci command, then restart the router to correctly apply iptables rules.

[Network-Traditions]

@Kalimeiro if I'm understanding you correctly, your saying even though I've configured a port forward for the Asterisk UDP port range with the "vpn" source zone to the Asterisk local IP address in the "lan" destination zone with the "Advanced Settings - Use V2Ray" unchecked, its still using the V2Ray UDP proxy rather than a VPN protocol.

Again I note that the incoming calls are working perfectly. Outgoing calls only the called party has no audio, however, when the called party speaks, that audio is heard at the originating callers phone. Regardless, given my understanding of your comments and other feedback that I've received that states V2Ray does not support port ranges, I will consider your recommendations.

Should I test my setup with "Shadow Socks" as my default proxy to eliminate V2Ray as the issue?

Thanks for your time and quick reply!!!

[ccmks]

Per my understanding, V2RAY currently doesn't work well for Audio or similar packet. Try to use Shadowsock instead

[Ysurac]

When "Use V2Ray" is unchecked in firewall settings, VPN is used for redirection in all case. But yes, try first with default configuration before using customization, default configuration is more tested. You may have an issue with SIP ALG, check if it's enabled or not in System->OpenMPTCProuter, "Advanced settings" tab.

[Network-Traditions]

@Ysurac thanks for the feedback. I did switch the OpenMPTCProuter wizard "Default Proxy" to Shadowsocks. For the SIP TCP/UDP protocol a port forward to our FreePBX server IP with a Source IP address matching only our SIP Trunk provider IP's was setup with "Use V2Ray" unchecked. A matching SNAT rule was created according to the "Redirect port via VPN". Additionally, a similar set of rules was created for the RTP UDP port range from any source as my provider utilizes "Direct Media", which means the RTP traffic is sent directly from the source and not their SIP servers. Finally, it's critically important to setup Asterisk (FreePBX in my case) to receive inbound connections from the OMR LAN interface IP rather than the SIP Trunk server's IP. This configuration successfully completes inbound and outbound calls!

So this left me wondering how changing the "Default Proxy" to Shadowsocks would impact other port forwarding rules that have "Use V2Ray" checked in the "Firewall-Port Forwards-Advanced Settings". Turns out, these rules are still working. For our Zimbra Groupware server which provides SMTP email services, I've found using the V2Ray reverse proxy works the best as the Zimbra server and pfSense have access to evaluate the IP address origins of incoming email which are used to validate and prevent SPAM and other malicious connections. When I used the VPN method as described above for the FreePBX server, Zimbra and pfSense only saw the OMR LAN interface as the origin of all incoming email. Additionally, email queues were also struggling with the configuration and had issues sending outgoing emails.

Subsequently, this is ideal for us to continue "Use V2Ray" in many cases while keeping the "Default Proxy" set to Shadowsocks. Because of the aforementioned observed behavior, it seems that selecting "Use V2Ray" overrides the default for that specific rule and the traffic it controls. Is this the case and how do you feel about using OpenMPTCProuter in this hybrid Shadowsocks/V2Ray manner?

[Network-Traditions]

To date we have been unsuccessful in resolving our issues with #2595, which ultimately requires a full reset of VPS and OMR daily. Subseqeuently, we have developed a work-around while using V2Ray as the OMR default proxy that is functioning quite well. For the RTP UDP port range, we defined individual port forwards for the needed range utilizing V2Ray forwarding. This resolved the one-way audio problem discussed here while allowing the use of V2Ray, which has greater performance and reliability than shadowsocks with our configuration.

[github-actions[bot]]

This issue is stale because it has been open 90 days with no activity. Remove stale label or comment or this will be closed in 5 days