Releases >= 24.7.1 have stopped outgoing VoIP - an MTU issue

[fbantgat7]

Hi,

Two SIP phones have been working fine using NAT Port Forward for more than a year now, but some of the changes implemented from opnsense-24.7.1 onward have broken part of the VoIP connection.

Both phones contact the provider's SIP gateway and register/re-register.  Incoming calls can be received and answered.  The problem is experienced with placing outgoing calls.  They fail to connect and soon time out returning a network failure on the phone display.

Looking at packet captures on WAN and LAN the phones send out repeated INVITE packets when trying to set up an outbound call, but they do not receive a response from the SIP gateway.

Re-installing opnsense 24.7 restores the full VoIP functionality.

My network topology:

Phone 1
=======
IP address: 192.168.20.21
Configured SIP port: 5062
Configured RTP ports: 49252 - 49262

Phone 2
=======
IP address: 192.168.20.22
Configured SIP port: 5064
Configured RTP ports: 49272 - 49282

OPNSense
========
WAN IP address: 123.45.6.789

I have set up the ISP's SIP gateway IP ranges as aliases under SIP_IPv4 & RTP_IPv4.

These are my Port Forward rules:

Code: [Select]

                    Source              Destination                NAT
Interface Proto Address Ports   Address    Ports IP       Ports      Description
    LAN TCP *         *   LAN address 22, 80, 443 *        *        Anti-Lockout Rule
    WAN UDP SIP_IPv4   5060 (SIP) 123.45.6.789   *         192.168.20.21 5062        SIP IPv4 redirect
    WAN UDP SIP_IPv4   5060 (SIP) 123.45.6.789   *         192.168.20.22 5064        SIP IPv4 redirect
    WAN UDP RTP_IPv4 * 123.45.6.789 49252 - 49262 192.168.20.21 49252 - 49262 RTP IPv4 Redirect
    WAN UDP RTP_IPv4 * 123.45.6.789 49272 - 49282 192.168.20.22 49272 - 49282 RTP IPv4 Redirect
Looking at the console output I can see the SIP port forward rule for 192.168.20.22 is missing - not sure why:

Code: [Select]

~ # pfctl -s nat
[snip ...]
rdr on pppoe0 inet proto udp from <SIP_IPv4> port = sip to 123.45.6.789 -> 192.168.20.21 port 5062
rdr on pppoe0 inet proto udp from <RTP_IPv4> to 123.45.6.789 port 49252:49262 -> 192.168.20.21 port 49252:49262
rdr on pppoe0 inet proto udp from <RTP_IPv4> to 123.45.6.789 port 49272:49282 -> 192.168.20.22 port 49272:49282
I'm a bit at a loss here as to what is amiss.  Do I need to change the Port Forward settings to be able to restore full VoIP functionality with the latest opnsense 24.7.3_1 kernel changes?

[meyergru]

How could you forward the WAN port 5060 to both IP phones at once? I would guess first one wins.

I think that you must not have port translation. For the RTP ports, this is mandatory, since the SIP signalisation done by the phones tells the registrar on which ports the RTP connection must be done. If the firewall interferes with that via port translation, it would not work.

So, just like with the RTP ports, you would have to use ports 5062 and 5064 on the WAN interface as well.

Also, I would not limit the rule to some known IPs of the SIP registrar, as they could change in the future. If you want to secure the ports, use the ASN of the registrar.

[fbantgat7]

Thank you meyergru,

I think that you must not have port translation. For the RTP ports, this is mandatory, since the SIP signalisation done by the phones tells the registrar on which ports the RTP connection must be done. If the firewall interferes with that via port translation, it would not work.

OK.

So, just like with the RTP ports, you would have to use ports 5062 and 5064 on the WAN interface as well.

I have now set up port forwarding from WAN:5062 to one phone and from WAN:5064 to the other phone.  It certainly looks better:

Code: [Select]

rdr on pppoe0 inet proto udp from <SIP_IPv4> port = sip to 123.45.6.789 port = 5062 -> 192.168.20.21 port 5062
rdr on pppoe0 inet proto udp from <SIP_IPv4> port = sip to 123.45.6.789 port = 5064 -> 192.168.20.22 port 5064
rdr on pppoe0 inet proto udp from <RTP_IPv4> to 123.45.6.789 port 49252:49262 -> 192.168.20.21 port 49252:49262
rdr on pppoe0 inet proto udp from <RTP_IPv4> to 123.45.6.789 port 49272:49282 -> 192.168.20.22 port 49272:49282I also rebooted the phones so they re-register with the ISP.  It hasn't worked.  I still cannot place outgoing calls. 

Also, I would not limit the rule to some known IPs of the SIP registrar, as they could change in the future. If you want to secure the ports, use the ASN of the registrar.

Good point, thanks.

I'm not sure how else to troubleshoot this problem.  Is there something else I could try on the opnsense configuration, or should I just sit this out and stay on 24.7 for now?  If my opnsense configuration is OK, then it must be something related to the recent kernel changes. 

[meyergru]

You did use "static port" for the connectiions?

[SideOfRanch]

I've had a similar issue with Verizon and outgoing calls over "wifi calling." I have yet to find any setting I can change to make it work, but this has persisted for a very long time and isn't new in 24.7 for me. Responding to see what the resolution is here to see if it works for my issue as well!

[fbantgat7]

You did use "static port" for the connectiions?

Sorry, I am not familiar with many opnsense configuration options - are you referring to the Outbound NAT option to enable a "static port"?  I have not changed the Outbound NAT from 'auto'.  I only have one IPv4 public address at this moment.

Also, the SIP registrar responds to the correct ports for each phone, each phone registers successfully and incoming calls can be answered.  It is the outgoing calls which fail.

[fbantgat7]

I've had a similar issue with Verizon and outgoing calls over "wifi calling." I have yet to find any setting I can change to make it work, but this has persisted for a very long time and isn't new in 24.7 for me.

Just to make it clear, the 24.7 and previous releases work OK in my use case, it's versions after 24.7 which partially broke VoIP here.  Are you able to receive calls with "wifi calling", or does it not work at all?

[meyergru]

You did use "static port" for the connectiions?

Sorry, I am not familiar with many opnsense configuration options - are you referring to the Outbound NAT option to enable a "static port"?  I have not changed the Outbound NAT from 'auto'.  I only have one IPv4 public address at this moment.

Also, the SIP registrar responds to the correct ports for each phone, each phone registers successfully and incoming calls can be answered.  It is the outgoing calls which fail.

Of course, it cannot work like that.

Set the outbound NAT mode to ‘Hybrid outbound NAT rule generation’, then add a new rule like so...

Interface: WAN
TCP/IP Version: IPv4
Source address: IP of VOIP Device
Source port: udp/ *
Destination address: any
Destination port: any
Translation/target: Interface address
Static Port: yes

NAT will translate ports to use a random port, your VoIP provider will try to respond on this random port and fail. The static outbound port, ensures that the outbound port number is not changed. SIP expects the source and destination ports to be the same.

[fbantgat7]

Thanks meyergru,

I added two Outbound rules one for each phone.  I now have:

Code: [Select]

nat on pppoe0 inet proto udp from 192.168.20.21 to <SIP_IPv4> -> (pppoe0:0) static-port
nat on pppoe0 inet proto udp from 192.168.20.22 to <SIP_IPv4> -> (pppoe0:0) static-port
[snip ...]
rdr on pppoe0 inet proto udp from <SIP_IPv4> port = sip to 123.45.6.789 port = 5062 -> 192.168.20.21 port 5062
rdr on pppoe0 inet proto udp from <SIP_IPv4> port = sip to 123.45.6.789 port = 5064 -> 192.168.20.22 port 5064
rdr on pppoe0 inet proto udp from <RTP_IPv4> to 123.45.6.789 port 49252:49262 -> 192.168.20.21 port 49252:49262
rdr on pppoe0 inet proto udp from <RTP_IPv4> to 123.45.6.789 port 49272:49282 -> 192.168.20.22 port 49272:49282
On 24.7 VoIP continues to work as expected.  I now upgraded to 24.7.3_1 and again I am not able to place an outbound call.

I wonder if I should just move these phones to IPv6 only, to do away with NAT problems.  TBH I have been avoiding doing it because IPv6 on opnsense has been a bit hit & miss over the years.

Is there anything else I should try configuring on 24.7.3_1 to solve this problem?

[meyergru]

I use SIP and have no problems with 24.7.x.

But wait a minute - what is this:

Code: [Select]

                    Source              Destination                NAT
Interface Proto Address Ports   Address    Ports IP       Ports      Description
    WAN UDP SIP_IPv4   5060 (SIP) 123.45.6.789   *         192.168.20.21 5062        SIP IPv4 redirect
    WAN UDP SIP_IPv4   5060 (SIP) 123.45.6.789   *         192.168.20.22 5064        SIP IPv4 redirect

I think these inbound NAT rules should read:

Code: [Select]

                    Source              Destination                NAT
Interface Proto Address Ports   Address    Ports IP       Ports      Description
    WAN UDP SIP_IPv4   * 123.45.6.789   5062 (SIP)         192.168.20.21 5062        SIP IPv4 redirect
    WAN UDP SIP_IPv4   * 123.45.6.789   5064 (SIP)         192.168.20.22 5064        SIP IPv4 redirect

You NAT destination ports and you do not know the source port (could be random). Also, 123.45.6.789 should be "this firewall" or "WAN address".

[fbantgat7]

Thank you for your patience meyergru,

It is encouraging to hear your VoIP works with the latest opnsense changes, there must be hope for mine too.   

Following your initial suggestion I had removed port translation for SIP, like this:

Code: [Select]

                    Source              Destination                NAT
Interface Proto Address Ports   Address    Ports IP       Ports      Description
    WAN UDP SIP_IPv4   5060 (SIP) 123.45.6.789   5062         192.168.20.21 5062        SIP IPv4 redirect
    WAN UDP SIP_IPv4   5060 (SIP) 123.45.6.789   5064         192.168.20.22 5064        SIP IPv4 redirect
Just now, I additionally removed the 5060 SIP port for the ISP's source address:

Code: [Select]

                    Source              Destination                NAT
Interface Proto Address Ports   Address    Ports IP       Ports      Description
    WAN UDP SIP_IPv4   * 123.45.6.789   5062         192.168.20.21 5062        SIP IPv4 redirect
    WAN UDP SIP_IPv4   * 123.45.6.789   5064         192.168.20.22 5064        SIP IPv4 redirect
123.45.6.789 is meant to show the obfuscated public address of my WAN interface.  SIP ports 5062 and 5064 are hardcoded respectively in the two VoIP phones, so these are the ports they use in their SIP communication with the ISP registrar.

Despite the above changes I am not able to place calls, although I continue to be able to register and receive calls.

[meyergru]

Thanks meyergru,

I added two Outbound rules one for each phone.  I now have:

Code: [Select]

nat on pppoe0 inet proto udp from 192.168.20.21 to <SIP_IPv4> -> (pppoe0:0) static-port
nat on pppoe0 inet proto udp from 192.168.20.22 to <SIP_IPv4> -> (pppoe0:0) static-port


I saw this now only:

Why those overly specific rules? You just have to have outbound NAT for your VoIP phones with static ports. That is, those NAT rules must beplace before any other outbound NAT rules (hence why "Hybrid Outbound NAT generation", but I showed you rules that do not have any specific ports or destination IPs in them. Mind you: The outbound NAT is needed for RTP as well and that does NOT go to SIP_IPv4.

[BoodahsFever]

If you have access to captures you also might want to check if your INVITES don't exceed 1500 bytes. Fix when it does by disabling CODECS that are not used and diversion headers and stuff like that. Also check the INVITES for IP addresses other than what the phone itself has. Disable NAT Traversal stuff and STUN on the phones might help since they habitually change private IP addresses to public ones. You want your INVITES to contain the real IP addresses of the phones since the SBC of the operator will fix that. If the contents are confusing to the SBC of the operator, it might reply to wrong IP Addresses or ports. Resulting in you not getting replies to INVITES. That's why the majority of operators advice to disable SIP-Helpers Like SIP-ALG and others. OPNSense doesn't have SIP-Helpers by default so you should be good there.

If configured right the SIP Proxy (SIP-ALG Plugin os-siproxd) could also help you by the way. But I never tried anything with it. So I would use it as last resort.

Normally, it shouldn't be necessary to create manual NAT rules for SIP Phones. They should register with SIP, which also creates a dynamic NAT translation and Firewall Pinhole (if not restricted). In an INVITE, there would also be signalling information about what ports and IP's to be used for RTP (the actual Audio) and those should also be the real IP addresses. The best suggestion I have is to leave that process to be handled automatically.

I as a VoIP engineer find OPNSense and PFsense a most excellent Edge Firewalls straight out the box. 

[meyergru]

Normally, it shouldn't be necessary to create manual NAT rules for SIP Phones. They should register with SIP, which also creates a dynamic NAT translation and Firewall Pinhole (if not restricted). In an INVITE, there would also be signalling information about what ports and IP's to be used for RTP (the actual Audio) and those should also be the real IP addresses. The best suggestion I have is to leave that process to be handled automatically.

I as a VoIP engineer find OPNSense and PFsense a most excellent Edge Firewalls straight out the box.

That is incorrect: The SIP call itself passes usual NAT rules, sure. But for example, contained in it, the RTP ports that should be used are advertised. If the firewall decides to translate one port to another (as is the default with NAT), it cannot be reflected in the SIP packet (unless you make use of a SIP proxy).

Almost any guide on how to enable a SIP phone behind OpnSense willl tell you to use "static port" on outgoing NAT and at least for me, this was neccessary.

[chemlud]

Have here several Gigasets, no special gym needed to make them work. Just some FW rules to allow for the IPs of the provider and done here...