Inbound SIP Traffic Suddenly Blocked

[kevinm207]

I deployed FreePBX on-premise for a customer a few months ago.  Everything had been working fine until a few days ago.  Because the SIP trunk provider uses "Outbound" for Authentication, and "Send" for Registration, I never had to create any inbound NAT rules for the SIP traffic to pass without issue.  I just figured since the session was already established outbound, that inbound traffic would flow, and that had been my experience until a few days go.

Now, when I look at the firewall logs in OPNSense, I'm seeing the "Default Deny / State Validation Rule" for inbound traffic from the SIP trunk provider's IP on SIP port 5060.

I tried a lot of things to resolve the issue...
1) I upgraded OPNSense: I was previously on the 22.7.x release, so, I upgraded all the way to 23.7.9 to see if it would fix the issue.  It did not.
2) After doing some research, under Firewall > Settings > Advanced, I changed Firewall Optimization to "Conservative."  That also did not fix the issue.
3) After continuing my research, I ran across people talking about disabling "source port rewriting."  Since the PBX is not hosted in the cloud with a bunch of phones behind the OPNSense firewall, but rather FreePBX is hosted on-premise, I decided there would be no harm in disabling it.  I couldn't find the exacting wording, but on my primary Outbound NAT rule, I found "Static-Port," and I checked it to enable it.  That also did not fix the issue.
4) Continuing my research, some people said they had issues after their public WAN IP changed.  The business has a GPON fiber connection using PPPoE for authentication.  The public IP had changed recently.  Some referenced a deprecated setting; "Dynamic State Reset."  I could not find that setting, but I did run the command "pfctl -s state -vv | grep <ip of the FreePBX server> | grep :5060" from the shell and the public IP that came back was correct.  So, that was also not helpful.

So, finally I created an inbound NAT rule to send all UDP port 5060 traffic from the public IP of the trunk provider to the internal IP of the FreePBX server.  That resolved the issue.  But, I'm not satisfied with that, because it should work without an inbound NAT rule because the SIP trunk is Authenticated outbound with Send registration, so there should already be an outbound session to match the inbound traffic.  I use several Ubiquiti EdgeRouter 4's for other businesses, and I do not have to create any inbound NAT rules for their FreePBX to work great using the same SIP trunk provider.

Any help would be greatly appreciated to better understand what broke or changed to suddenly cause this issue.

Thanks,

Kevin

[trumee]

Thank you for posting this. I can confirm this behavior.

I migrated from pfsense to opnsense recently. And in pfsense i did not have to create this rule. After migration i went through similar experience, and ultimately settled on a NAT rule as you have described.

[sja1440]

I do not use FreePBX but I do use a consumer grade Gigaset box from which I manage several VoIP providers. I guess the principles are the same. I hope that this post is helpful.

From your description it sounds to me that the OPNsense firewall's udp session may have expired when the incoming call is received.

By default the OPNsense firewall (pf) has udp session timeouts set to a few 100s of seconds. To keep the firewall session alive, your FreePBX would need to send at least one message to your provider within the relevant pf udp timeout.

Your SIP provider will specify during registration the expiry time applicable to that session. Before expiry the FreePBX will need to send a new REGISTER request to the provider.  So if your provider's session expiry time is a lot greater than your firewall udp session expiry times then the firewall udp session will no longer exist until the next REGISTER is sent. During that dead period incoming calls will fail.

There are several ways of avoiding this dead period.

One is to create a port forward NAT rule as you did.

The other, would be to configure within FreePBX the periodic transmission of either SIP KeepAlives or NAT refresh messages. The frequency of transmission of these is probably a parameter within FreePBX - it certainly is in my Gigaset box.

Personally, I prefer to keep a port open for my VoIP providers.  I do not use the SIP KeepAlive or NAT refresh mechanisms because a couple of years ago, one of my providers decided to harden his systems by automatically blacklisting any ip addresses that sent too many messages within a certain period of time (in his case no more than 1 message per 30 seconds). This caused my registrations to fail until the blacklist was reset (around an hour or so). It took me some time to work out what was happening. I can well do without this sort of fine tuning, thank you very much.

[kevinm207]

@trumee and @sja1440 thank you so much for your replies and help.  For reference, I've attached a screenshot of the SIP trunk settings in FreePBX.  I'm pretty sure these are the defaults, and they have not been changed.

I may fiddle around with them some as time permits, but at least I have the customer back up and working for now with the NAT rule.