We are having trouble with SIP inspect on our ASA when using NAT.
The call flow is
IP Phone -> CUCM -> CUBE -> ASA -> ITSP
In the majority of cases, this is working correctly, but in some cases (maybe 1 call in 50, but frequency varies), the call is failing with a "Your call cannot be completed as dialled". I have ran CCSIP debugs on the CUBE and can see the provider is sending a "404 Route Not found". I raised a case with them, and they have told me, that in the case of a good call, the TO and REQUEST header are the correct address for the ITSP, but in a failed call, the REQUEST address is showing the address of the external interface of the firewall (instead of our NATed endpoint address).
In the case of a good call:
192.168.46.18 is our internal CUBE address and 184.108.40.206 is the ITSP signalling address. The NAT works correctly and our source address reaches the ITSP as X.X.99.51.
In the case of a failed call:
The firewall seems to build a new dynamic translation (our normal PAT for internet traffic) and does not re-write the REQUEST header correctly, and instead, sends it with an address of our external interface X.X.99.50, instead of the ITSP address.
From the ITSP point of view, they see the invite as:
From this, I can see that the SIP invite is being sent with the correct TO, FROM & VIA address, but for some reason, the Request-Line is being sent incorrectly, and the ITSP is sending me back a 404 message.
I can't explain why this is happening and why it is only happening intermittently. The firewall is running the latest version 9.3.1.
Table of ContentsIntroductionVersion HistoryPossible Future
UpdatesDocuments PurposeNAT Operation in ASA 8.3+ SectionsRule Types
Network Object NATTwice NAT / Manual NATRule Types used per SectionNAT
Types used with Twice NAT / Manual NAT and Network Obje...
Table of Contents Introduction:This document describes details on how
NAT-T works. Background: ESP encrypts all critical information,
encapsulating the entire inner TCP/UDP datagram within an ESP header.
ESP is an IP protocol in the same sense that TCP an...