{"id":146,"date":"2019-11-30T22:18:11","date_gmt":"2019-11-30T22:18:11","guid":{"rendered":"https:\/\/thelordofthepings.newedgenetworking.com\/wp\/?p=146"},"modified":"2019-11-30T22:18:11","modified_gmt":"2019-11-30T22:18:11","slug":"nats-interaction-with-dns-answers","status":"publish","type":"post","link":"https:\/\/andrewjwhittle.com\/wp-lotpnet\/2019\/11\/30\/nats-interaction-with-dns-answers\/","title":{"rendered":"NAT&#8217;s interaction with DNS answers"},"content":{"rendered":"<p><span style=\"font-weight: 400;\">Recently I was troubleshooting some odd DNS results between 2 customers that have a B2B connection. The DNS record in question existed in the wild on the internet and resolved to 113.129.255.98 (all IP\u2019s have been randomized using https:\/\/onlinerandomtools.com\/generate-random-ip for anonymity). Customer A resolved to 192.168.20.5 on their end of the link and Customer B resolved to 172.16.20.57 on the other end, where the server lived, which was the correct one. DNS admins were brought in on both sides. Customer A confirmed that they had Conditional Forwarders configured to query Customer B\u2019s Name Servers for this Zone.<\/span><\/p>\n<p>&nbsp;<\/p>\n<p><span style=\"font-weight: 400;\">To the Packets! Captures were taken nearest each Name Server and nearest each end of the B2B connection. The change was happening on Customer A\u2019s side of the link behind a outer doing NAT. We had brought up NAT a couple of times but thought \u201cnah, that\u2019s not what NAT does\u201d. Guess what happened when we said \u201cok, let\u2019s remove the NAT\u201d. By the title of this you can probably guess what happened&#8230;Problem solved. We were flabbergasted.<\/span><\/p>\n<p>&nbsp;<\/p>\n<p><span style=\"font-weight: 400;\">I was familiar with DNS spoofing\/poisoning\/hijacking but had never thought that NAT could be leveraged in this way. Research brought me to DNS Doctoring which is the non malicious way to manipulate DNS for good rather than for evil. But this was different. Eventually I stumbled across RFC 2694 \u201cDNS extensions to Network Address Translators (DNS_ALG)\u201d <\/span><a href=\"https:\/\/tools.ietf.org\/html\/rfc2694\"><span style=\"font-weight: 400;\">https:\/\/tools.ietf.org\/html\/rfc2694<\/span><\/a><span style=\"font-weight: 400;\"> and Application Level Gateways.<\/span><\/p>\n<p>&nbsp;<\/p>\n<p><span style=\"font-weight: 400;\">These are a couple of the pages that I found on the subject.<\/span><\/p>\n<p><a href=\"https:\/\/blog.webernetz.net\/cisco-router-disable-dns-rewrite-alg-for-static-nats\/\"><span style=\"font-weight: 400;\">https:\/\/blog.webernetz.net\/cisco-router-disable-dns-rewrite-alg-for-static-nats\/<\/span><\/a><\/p>\n<p><a href=\"https:\/\/urldefense.proofpoint.com\/v2\/url?u=https-3A__www.cisco.com_c_en_us_td_docs_security_asa_asa95_configuration_firewall_asa-2D95-2Dfirewall-2Dconfig_nat-2Dreference.pdf&amp;d=DwMFaQ&amp;c=pApUd0AUA6FmKRo01iR_VA&amp;r=yszqe8QmTDcZkIzDRGPCuhk_3j_cGh3Jz-GFBCXBbXw&amp;m=KZoXLxO3ghni8khS-cxs2L-UHqBpadXjb3nQRDYu-ww&amp;s=lP6CpJImbV3WbHCWmFmUccZg_Aaeg10w21MM6mx5zgY&amp;e=\"><span style=\"font-weight: 400;\">https:\/\/www.cisco.com\/c\/en\/us\/td\/docs\/security\/asa\/asa95\/configuration\/firewall\/asa-95-firewall-config\/nat-reference.pdf<\/span><\/a><span style=\"font-weight: 400;\">\u00a0<\/span><\/p>\n<p>&nbsp;<\/p>\n<p><span style=\"font-weight: 400;\">It took longer than it should have to find the answer because I was using search terms that weren\u2019t used much. I\u2019ve included my verbiage so the next person will find this faster.<\/span><\/p>\n<p>&nbsp;<\/p>\n<p><span style=\"font-weight: 400;\">On a Cisco IOS device Application Level Gateway for NAT is enabled by default. Which means in a one to one NAT (not overloaded\/PAT) the DNS answer within received packets is rewritten to the NAT IP.<\/span><\/p>\n<p>&nbsp;<\/p>\n<p><span style=\"font-weight: 400;\">So with this config:<\/span><\/p>\n<p><span style=\"font-weight: 400;\">ip nat outside source static &lt;outside global&gt; &lt;outside local&gt;<\/span><\/p>\n<p><span style=\"font-weight: 400;\">ip nat inside source static 172.16.20.57 192.168.20.5<\/span><\/p>\n<p>&nbsp;<\/p>\n<p><span style=\"font-weight: 400;\">When you do an nslookup from the receiving side of the NAT (in this case Customer A) you\u2019ll resolve to the outside local instead of the outside global IP you\u2019ll get the outside local one.<\/span><\/p>\n<p>&nbsp;<\/p>\n<p><span style=\"font-weight: 400;\">You can disable ALG with:<\/span><\/p>\n<p><span style=\"font-weight: 400;\">(no) ip nat service alg udp dns<\/span><\/p>\n<p><span style=\"font-weight: 400;\">(no) ip nat service alg tcp dns<\/span><\/p>\n<p>&nbsp;<\/p>\n<p><span style=\"font-weight: 400;\">Or change the NAT so that it doesn\u2019t alter the payload of the packets that contain DNS answers, or the payload of any packets, who knows what other \u201cfeatures\u201d lie in wait:<\/span><\/p>\n<p><span style=\"font-weight: 400;\">ip nat inside source static <\/span><span style=\"font-weight: 400;\">&lt;outside global&gt; &lt;outside local&gt;<\/span><span style=\"font-weight: 400;\"> no-payload<\/span><\/p>\n<p><span style=\"font-weight: 400;\">ip nat inside source static 172.16.20.57 192.168.20.5 no-payload<\/span><\/p>\n<p>&nbsp;<\/p>\n<p><span style=\"font-weight: 400;\">One more reason to hate NAT, which would also have been an acceptable post name.<\/span><\/p>\n","protected":false},"excerpt":{"rendered":"<p>Recently I was troubleshooting some odd DNS results between 2 customers that have a B2B connection. The DNS record in question existed in the wild on the internet and resolved to 113.129.255.98 (all IP\u2019s have been randomized using https:\/\/onlinerandomtools.com\/generate-random-ip for anonymity). Customer A resolved to 192.168.20.5 on their end of the link and Customer B [&hellip;]<\/p>\n","protected":false},"author":1,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"_jetpack_memberships_contains_paid_content":false,"footnotes":""},"categories":[35,57,33,60,42],"tags":[59,12,7,19,56,58],"class_list":["post-146","post","type-post","status-publish","format-standard","hentry","category-cisco","category-dns","category-firewall","category-nat","category-troubleshooting","tag-b2b","tag-cisco","tag-dns","tag-ios","tag-ipv4","tag-nat"],"jetpack_featured_media_url":"","jetpack_sharing_enabled":true,"_links":{"self":[{"href":"https:\/\/andrewjwhittle.com\/wp-lotpnet\/wp-json\/wp\/v2\/posts\/146","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/andrewjwhittle.com\/wp-lotpnet\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/andrewjwhittle.com\/wp-lotpnet\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/andrewjwhittle.com\/wp-lotpnet\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/andrewjwhittle.com\/wp-lotpnet\/wp-json\/wp\/v2\/comments?post=146"}],"version-history":[{"count":3,"href":"https:\/\/andrewjwhittle.com\/wp-lotpnet\/wp-json\/wp\/v2\/posts\/146\/revisions"}],"predecessor-version":[{"id":149,"href":"https:\/\/andrewjwhittle.com\/wp-lotpnet\/wp-json\/wp\/v2\/posts\/146\/revisions\/149"}],"wp:attachment":[{"href":"https:\/\/andrewjwhittle.com\/wp-lotpnet\/wp-json\/wp\/v2\/media?parent=146"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/andrewjwhittle.com\/wp-lotpnet\/wp-json\/wp\/v2\/categories?post=146"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/andrewjwhittle.com\/wp-lotpnet\/wp-json\/wp\/v2\/tags?post=146"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}