What effects does double-NAT have on VoIP? What happens to the traffic in this type of situation and what conditions can occur as a result of it?
Router – Double-NAT’s Effects on SIP and RTP
nat;routersipvoip
Related Solutions
Answering my own question to help future googlers. I spent about 3 hours on the phone with TAC; we finally got to the root cause of the issue.
The solution is to add a special NAT entry, which matches the IP address in the DNS A-Record when it arrives on the INSIDE interface.
object network DNS_NAT_masd1
description xlate A-Record DMZ src 1.195.18.182 to INSIDE src 10.195.18.182
host 1.195.18.182
nat (DMZ,INSIDE) static 10.195.18.182
When I asked for a pointer to documentation that describes why DNS translation works this way, the TAC lead said that he didn't know of any that described this behavior. The TAC lead also mentioned that with more code, the ASA would know to automatically translate the DNS A-Record without explicitly adding object network DNS_NAT_masd1; however, that is not how the dns keyword for ASA NAT works today. For reasons that still are not completely clear yet, the ASA requires the DNS A-Record IP to match the <proxy_addr> in the NAT statement, using syntax similar to this...
object network obj-EXAMPLE
description NAT object explicitly for translating DNS A-Records
host <proxy_addr>
nat (<REAL_INTF>,<PROXY_INTF>) static <real_addr> dns
The difficulty is that this configuration is exactly backwards for what you need to do if you're going to nat regular "data plane" IP traffic through the firewall.
This is the whole configuration that works...
object network DMZ_NAT_masd1
host 10.195.18.182
description xlate masd1 NAT DMZ src 10.195.18.182 to INSIDE src 192.168.11.101
object network INSIDE_NAT_masd1
host 10.195.18.182
description xlate masd1 NAT INSIDE src 10.195.18.182 to DMZ src 1.195.18.182
!!! DNS_NAT_masd1 is new
object network DNS_NAT_masd1
host 1.195.18.182
description xlate A-Record DMZ src 1.195.18.182 to INSIDE src 10.195.18.182
!
object network DMZ_NAT_masd1
nat (DMZ,INSIDE) static 192.168.11.101
object network INSIDE_NAT_masd1
nat (INSIDE,DMZ) static 1.195.18.182
!!! DNS_NAT_masd1 is new
object network DNS_NAT_masd1
nat (DMZ,INSIDE) static 10.195.18.182 dns
There are basically two options this could be handled by NAT.
First, the NAT implementation can use an Application Level Gateway for RTP. In this case it will create a new entry in the NAPT mappings. In that mapping the client-facing port should be the one signaled, the server-facing port can be random. After the new mapping has been created, the ALG overwrites the port and ip in the RTP message with the server-facing data of that new mapping. This is transparent for clients, but NAT implementations need to keep up with the protocols.
Secondly, if supported by the NAT gateway, a client could use a protocol to learn it's server-facing ip and to allocate a port before signaling RTP. Most common protocols to do this are PCP and UPnP. This needs work/added complexity on the client side but is more generic as only the client needs to update it's protocol implementation and can use this for other protocols as well.
Best Answer
As @Ricky Beam indicated, you should have no issues other than delay with fully-functional, SIP-aware NAT devices. This is known as ALG (Application Layer Gateway) on some lower-end network devices and SIP Fixup or SIP Inspection on different Cisco firewall platforms depending on software version.
Generally, the recommendation on not using ALG comes from poor implementation of either ALG itself or the client not putting its address into the SIP packets for it to be found and updated with the NAT'd address. On higher-end network devices, this generally works though you may run into a bug as I did in a recent question with an older Cisco PIX version.
Any type of ALG/SIP Inspection requires symetrically routing especially if implemented in a stateful firewall so the NAT'd addresses can get reversed on their way back to the client sitting inside the NAT device.