SIP NATing fills up fwx_alloc even when there's no actual NAT used for SIP R80.10

[Kaspars_Zibarts]

Hopefully someone has played more with advanced SIP objects than I have 🙂

We noticed that one day fwx_alloc filled up and caused intermittent connectivity to outside world. And it took a while to connect it to SIP as we don't use SIP over external interface.

In nutshell - we have external partner PBX that's routed over one of internal interfaces but using public IP of theirs, say 1.2.3.4. We present ourselves with 10.x.x.x. And all was working - there were explicit "un-NAT" rules in place so traffic went from 10/8 to 1.2.3.4 without any NATs.

But when I looked at the connections table, I saw entries from our clients in 10/8 talking to 1.2.3.4 and default NAT IP that was set in very last NAT rule (basically anything internal going to internet would get this IP, say 5.6.7.8) applied to this connection. Very weird as 5.6.7.8 was not used anywhere else at all. And actual tcpdumps confirmed that it was not used for this connection.

And fwx_alloc had nearly 20000 entries with 5.6.7.8, very short entries with no other addresses, i.e

<00000011, 05060708, 0000c4e2, 00000000; 24/60>

But connections table would have connections like this one

<00000001, 0a2a309e, 00007d03, 01020304, 00000000, 00000011> -> <00000000, 01020304, 00000000, 05060708, 0000c5e1, 00000011> (00000100)

At the end I removed advanced SIP objects from the rule (sip and sip-tcp) and replaced it with plain port service object and all started working as should.

So looks like SIP was trying to do some "early NAT" as public IP was involved. Even though we had explicit rules not to NAT this PBX.

Just wondering if anyone knows exactly how the early NAT works in SIP case and how to stop it from being applied without removing sip and sip-tcp service objects Tried to read sk65072 but got none the wiser

[Wolfgang]

Kaspars,

we had the same problem last year and I had to think twice to understand how it works.

Everything is described in your mentioned sk65072 .

The "early NAT" does only occurs if you use some of the predefined SIP services elsewhere in your rulebase.

You don't have to remove these services from the objects database only from the rulebase.

In my case we found last year some rules with these SIP services negotiated and this too starts the "early NAT" process.

We removed the SIP services and replaced them with newly created like you did and the "early NAT" didn't occur.

best regards

Wolfgang

[HeikoAnkenbrand]

Hello Kaspars,

SIP services start the "early NAT" chain modul.

If you disable the SIP services, the RTP sessions will not be recognized from SIP traffic and will be not added to the statetable. So you should add the voip UDP port ranges for RTP to the rules of the firewall.

[HeikoAnkenbrand]

Tip!

I always configure it as described in this article:

VoIP-Issue-and-SMB-Appliance-600-1000-1200-1400

This also works for other (not SMB) firewalls.

[Kaspars_Zibarts]

So i guess that's my only choice old school port 5060 + high ports. Ugly but at least working.

[HeikoAnkenbrand]

Yes:-)

[Kaspars_Zibarts]

I still wanted to know how the early NAT works and how does it chooses NAT IP as in our case we do not have NAT configured and it's not applied to actual connection but it appears in t connection and NAT tables.. looks like a SR