[VoiceOps] ACME behaviour with Bad NAT Firewalls

[Jon Radel]

On 6/8/11 11:36 PM, Ujjval Karihaloo wrote:
>
> Hi All:
>
>   We have seen many PBX NAT’ed behind a Firewall that does not do the 
> Sip ALG correctly. Most cases putting the Private IP in the Contact 
> header and the ACME responds back to the Private IP.
>
> Example call inbound to the PBX, the PBX sends a 200 OK (as call is 
> answered) with a Private IP in the contact header. ACME sends the ACK 
> back to the Private IP blackholing it.
>
> I have seen SBC’s that do adjust to the Layer 3 IP:port if they notice 
> Private IPs in the SIP signaling. Is there a setting on ACME to do that?
>
>
Read up on
nat-traversal always
in the sip interface section of the config. I will note, however, that 
that looks for the Contact-URI and topmost VIA to match and to be 
different than the source address in layer 3 (IP), rather than looking 
for RFC 1918 addresses.  Of course, given that there are umpteen hundred 
knobs to twist on an Acme, there's probably some way of getting it to do 
this only for RFC 1918 addresses, but I'm not sure there's value in 
doing that and certainly couldn't tell you how to do it.  My 
understanding is that "nat-traversal always" is the "normal" way of 
doing what you appear to need.

As an operational note, we've had more problems with various customer 
firewalls doing pretty bad jobs with SIP, such as the one that worked 
fine until somebody transferred a call at which point the firewall just 
dropped all sorts of vital packets on the floor, than we've ever had 
just letting our Acmes do NAT traversal.  Our standard recommendation is 
to turn all SIP aware proxies, fix-up, etc. off.

--Jon Radel
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://puck.nether.net/pipermail/voiceops/attachments/20110609/96923e16/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 3648 bytes
Desc: S/MIME Cryptographic Signature
URL: <https://puck.nether.net/pipermail/voiceops/attachments/20110609/96923e16/attachment.bin>