VoIP Issue - Firewall rules

[GreyBeard]

I have been using OPNsense for about 6 months but have hit a problem, I cannot for the life of me configure the Firewall ports to allow VoIP traffic. 

I need to allow a range of ports open to allow 3 handsets on my local LAN to communicate with a hosted PBX on the Internet.

The handsets can register with the PBX (myPBX.voipCompany.com) fine as outgoing clients (I assume via the default out rule?) but I do not receive calls because I assume the default deny rule is blocking the incoming port?

I can also call out, but cannot hear the other person, again due to the default deny I'm guessing.  The provider says it’s a firewall issue and will not help further.

Before the details, I have some preliminary questions I cannot find the answer too.

Firewall -> Settings -> Advanced “Network Address Translation”

Do I need to enable “Reflection for port forwards” and “Automatic outbound NAT for Reflection”?

Other posts suggest enabling these, but without reason.

Also some things I have tried that seem to have not helped

• I have tried Firewall -> Settings -> Advanced -> Firewall Optimization = Conservative. No discernible effect.
• I have added and enabled the plugin “Siproxd” to no effect

Some details

Fixed IP: 213.47.33.171
PBX: myPBX.voipCompany.com
Ports: UDP 5060-5070 & 10000-20000 (RTP media)

Please can somebody explain what the magic combination is on the Floating Rules section?

Here is what I tried, creating two rules, one for each of the port ranges:
Interface: WAN
Direction: any
Protocol: UDP
Source: any (but really this should be restricted to myPBX.voipCompany.com)
Destination: LAN net (I assume “LAN net” is the entire local 192.168.0.0/24 range?)
Port Range (other) 5060-5070 & 10000-20000
Log: enabled
Category: VoIP

I have tried, for hours, various combinations but the ports remain closed to the world.

Live view logging does not seem to show anything helpful, should it?

How can I see blocked incoming connections from “myPBX.voipCompany.com”

Please help or I’m going to have admit defeat and buy something from ubiquiti 

[tryhard]

Hi,
it sound like your phones don't get any connection from Internet side.

If you have a STUN Server configured you should be fine if do the following:
(STUN needs to be allowed from LAN to WAN (Internet) 3478 TCP/UDP)

If you can configure every handset with its own set of ports (like 5061 and 10000-10025 for one handset)
Create an Alias with with the handsets IPs (they have to be static or reserved IPs from DHCP)
Enable Hypbrid Outbound NAT
Add a Rule (WAN interface, source is above alias,  Static-port: checked)

This should do the trick

You could also make port forwards but only if you have youre on set of ports for every handset configured.
(Filter rule association: pass; NAT Reflcetion Enabled)

[GreyBeard]

I like the idea of setting each handset to it's own port requirements then fixing those.  Long winded but clear when there is an issue with a single handset.

As it happens this turned out to be an issue with the routing at the providers side! When they updated their record things started working.
(although I have left  “Reflection for port forwards” and “Automatic outbound NAT for Reflection” ticked for now because it's simply working 

[earlsven]

Hi,
it sound like your phones don't get any connection from Internet side.

If you have a STUN Server configured you should be fine if do the following:
(STUN needs to be allowed from LAN to WAN (Internet) 3478 TCP/UDP)

If you can configure every handset with its own set of ports (like 5061 and 10000-10025 for one handset)
Create an Alias with with the handsets IPs (they have to be static or reserved IPs from DHCP)
Enable Hypbrid Outbound NAT
Add a Rule (WAN interface, source is above alias,  Static-port: checked)

This should do the trick

You could also make port forwards but only if you have youre on set of ports for every handset configured.
(Filter rule association: pass; NAT Reflcetion Enabled)

Thanks for this, solved my VoIP issues with my SPA112. STUN server didn't work for me, but the NAT Rule fixed it!