If you want to receive phone calls from a particular source (such a your ITSP), you can either ensure that you send outbound traffic to their sources (using registration or qualify packets), and that will cause your NAT Router to automatically route responsive traffic (phone calls) back to your system.
At the same time, unwanted “SIP penetrations” that come from IP addresses you haven’t communicated with will be blocked by your NAT Router automatically, as it won’t have any entry in the routing table and won’t know to forward those packets back to your PBX.
Of course, as I said before, you should also configure iptables to block out anything that might make it through your NAT Router.
Even if you program your router to accept all traffic, without a masquerade and forward rule to send traffic back to your PBX, unwanted SIP traffic will simply get passed to your router’s OS, which will have no service on those ports and will do nothing of importance with them. The packets will never reach your PBX if it is behind a NAT Router.
And most consumer routers are programmed to drop everything that comes in externally unless it is subject to a masquerade/forward rule. Typically, the masquerade/forward rule works together with an inbound “allow related” and “allow established” to let the traffic in on the external hardware port.
The important point, which I made before, is that if you put your PBX behind a NAT Router and you don’t forward port 5060, you get a good measure of security. When you combine it with a real firewall that is properly configured on your PBX, you can have a well secured machine. I’ve run 30 machines like this for a decade, and never had a penetration. Ever.
I never said that NAT was a firewall. I said that “a NAT Router includes a firewall.” Thank you for confirming that I was correct.
But, again, even if you strictly have a NAT, without a firewall (or with the firewall turned off), the presence of the NAT will prevent the routing of most unwanted SIP traffic to the PBX that is behind the NAT router because the NAT won’t know where to forward the traffic, and it’ll be dropped.
On a more technical level, most devices use iptables for NAT, and iptables is also a firewall, and so a more correct version of your statement is that “almost 100% of NAT software includes a firewall.”
So I had an office that had phones on NAT. No forwarding rules but when the phone registers or makes an outbound calls then it opens a NAT hole to allow incoming traffic. This allowed for ghost calla to hit them because it was allowing any traffic on over the NAT holes made. I had to put in firewall rules in their router to only allow SIP traffic that sourced from me to be allowed in.
This is why people have inbound issues with no audio or not even receiving incoming calls. Because the NAT hole closed and until the device makes another outbound request to open it again, it stays closed.
As far as keeping the NAT holes open, you can either set a short register time (55 seconds), use a SIP client that supports STUN/ICE/etc., or if you have a PBX, set qualify=yes. Any of these will suffice to keep the NAT and forwarding rule open forever.
In the last 15 years, I encountered one consumer router, which I think was made by Belkin, that would set a forwarding rule (and open the firewall) for traffic from from ANY IP in the world after any device on the network sent traffic out to (or from) port 5060. I assumed that this was some attempt at SIP ALG (which could not be turned off).
That was highly unusual and not how IPTables handles masquerade. Properly handled masquerade will only forward responsive traffic from the destination IP, and not any traffic that happens to arrive on the same port.
Huge numbers of folks here using cloud servers will have zero use for network address translation most will realize they still need a firewall (or two)
But how about you just publish your list of rules, both the ones that NAT and the ones that ROUTE.
