<?xml version="1.0" encoding="UTF-8"?>
<rss xmlns:content="http://purl.org/rss/1.0/modules/content/" xmlns:dc="http://purl.org/dc/elements/1.1/" xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#" xmlns:taxo="http://purl.org/rss/1.0/modules/taxonomy/" version="2.0">
  <channel>
    <title>topic Re: NAT Hairpin Problem in Network Security</title>
    <link>https://community.cisco.com/t5/network-security/nat-hairpin-problem/m-p/1458684#M642212</link>
    <description>&lt;HTML&gt;&lt;HEAD&gt;&lt;/HEAD&gt;&lt;BODY&gt;&lt;P&gt;Hi,&lt;/P&gt;&lt;P&gt;&lt;BR /&gt;The sniffing part shows the answered IP is the un-NATed IP.&lt;/P&gt;&lt;P&gt;&lt;/P&gt;&lt;P&gt;source&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp; destination&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp; info&lt;/P&gt;&lt;P&gt;10.156.16.28&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp; 24.x.x.x&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp; SYN&lt;/P&gt;&lt;P&gt;172.22.35.10&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp; 10.156.16.28&amp;nbsp; SYN-ACK &lt;/P&gt;&lt;P&gt;10.156.16.28&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp; 172.22.35.10 RST (broken tcp.&amp;nbsp; the acknowledgement field is nonzero while the ack flag is not set)&lt;/P&gt;&lt;P&gt;&lt;/P&gt;&lt;P&gt;You're talking to the NAT IP 24.x.x.x but you're getting replies from the un-NATed IP 172.22.35.10?&lt;/P&gt;&lt;P&gt;I guess my question is, if you have this command:&lt;/P&gt;&lt;P&gt;&lt;/P&gt;&lt;P&gt;static (inside,inside) 24.x.x.x 172.22.35.10 netmask 255.255.255.255&lt;/P&gt;&lt;P&gt;&lt;/P&gt;&lt;P&gt;Is because you want to see 172.22.35.10 as 24.x.x.x from the inside. So, why is the communication between 10.156.16.28 and 172.22.35.10 (instead of 24.x.x.x)&lt;/P&gt;&lt;P&gt;&lt;/P&gt;&lt;P&gt;Federico.&lt;/P&gt;&lt;/BODY&gt;&lt;/HTML&gt;</description>
    <pubDate>Mon, 07 Jun 2010 22:21:27 GMT</pubDate>
    <dc:creator>Federico Coto Fajardo</dc:creator>
    <dc:date>2010-06-07T22:21:27Z</dc:date>
    <item>
      <title>NAT Hairpin Problem</title>
      <link>https://community.cisco.com/t5/network-security/nat-hairpin-problem/m-p/1458683#M642211</link>
      <description>&lt;P&gt;I've setup NAT hairpin for inside hosts to use the public IP of the inside webserver as follows:&lt;/P&gt;&lt;P&gt;&lt;/P&gt;&lt;P&gt;inside client:10.156.16.28&lt;/P&gt;&lt;P&gt;webserver: 172.22.35.10 NAT's to 24.x.x.x&lt;/P&gt;&lt;P&gt;&lt;BR /&gt;I used these commands:&lt;/P&gt;&lt;P&gt;&lt;/P&gt;&lt;P&gt;same-security-traffic permit intra-interface&lt;BR /&gt;static (inside,inside) 24.x.x.x 172.22.35.10 netmask 255.255.255.255&lt;/P&gt;&lt;P&gt;&lt;BR /&gt;I can ping from 10.156.16.28 to 24.x.x.x and get responses (I did not before I started).&amp;nbsp; However, when I try to browse to the webserver or telnet to port 80 for 24.x.x.x I get nothing.&amp;nbsp; Packet-tracer said the flow should be allowed so I did some captures on the ASA and it looked good.&lt;/P&gt;&lt;P&gt;&lt;BR /&gt;When I sniff the traffic on 10.156.16.28 I see this:&lt;/P&gt;&lt;P&gt;source&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp; destination&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp; info&lt;/P&gt;&lt;P&gt;10.156.16.28&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp; 24.x.x.x&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp; SYN&lt;/P&gt;&lt;P&gt;172.22.35.10&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp; 10.156.16.28&amp;nbsp; SYN-ACK&amp;nbsp; &lt;/P&gt;&lt;P&gt;10.156.16.28&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp; 172.22.35.10 RST (broken tcp.&amp;nbsp; the acknowledgement field is nonzero while the ack flag is not set)&lt;/P&gt;&lt;P&gt;&lt;/P&gt;&lt;P&gt;Obviously the traffic is making it's way back to 10.156.16.28, but that host doesn't ACK it.&lt;/P&gt;&lt;P&gt;&lt;/P&gt;&lt;P&gt;I'm running an ASA5520 with 8.2 code and Websense filtering disabled for testing this.&amp;nbsp; I cannot do DNS doctoring as the DNS is on our corporate network (doesn't go through this ASA) and I don't have access to the firewall on that side.&lt;/P&gt;&lt;P&gt;&lt;/P&gt;&lt;P&gt;Thanks.&lt;/P&gt;</description>
      <pubDate>Mon, 11 Mar 2019 17:55:48 GMT</pubDate>
      <guid>https://community.cisco.com/t5/network-security/nat-hairpin-problem/m-p/1458683#M642211</guid>
      <dc:creator>terrygwazdosky</dc:creator>
      <dc:date>2019-03-11T17:55:48Z</dc:date>
    </item>
    <item>
      <title>Re: NAT Hairpin Problem</title>
      <link>https://community.cisco.com/t5/network-security/nat-hairpin-problem/m-p/1458684#M642212</link>
      <description>&lt;HTML&gt;&lt;HEAD&gt;&lt;/HEAD&gt;&lt;BODY&gt;&lt;P&gt;Hi,&lt;/P&gt;&lt;P&gt;&lt;BR /&gt;The sniffing part shows the answered IP is the un-NATed IP.&lt;/P&gt;&lt;P&gt;&lt;/P&gt;&lt;P&gt;source&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp; destination&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp; info&lt;/P&gt;&lt;P&gt;10.156.16.28&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp; 24.x.x.x&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp; SYN&lt;/P&gt;&lt;P&gt;172.22.35.10&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp; 10.156.16.28&amp;nbsp; SYN-ACK &lt;/P&gt;&lt;P&gt;10.156.16.28&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp; 172.22.35.10 RST (broken tcp.&amp;nbsp; the acknowledgement field is nonzero while the ack flag is not set)&lt;/P&gt;&lt;P&gt;&lt;/P&gt;&lt;P&gt;You're talking to the NAT IP 24.x.x.x but you're getting replies from the un-NATed IP 172.22.35.10?&lt;/P&gt;&lt;P&gt;I guess my question is, if you have this command:&lt;/P&gt;&lt;P&gt;&lt;/P&gt;&lt;P&gt;static (inside,inside) 24.x.x.x 172.22.35.10 netmask 255.255.255.255&lt;/P&gt;&lt;P&gt;&lt;/P&gt;&lt;P&gt;Is because you want to see 172.22.35.10 as 24.x.x.x from the inside. So, why is the communication between 10.156.16.28 and 172.22.35.10 (instead of 24.x.x.x)&lt;/P&gt;&lt;P&gt;&lt;/P&gt;&lt;P&gt;Federico.&lt;/P&gt;&lt;/BODY&gt;&lt;/HTML&gt;</description>
      <pubDate>Mon, 07 Jun 2010 22:21:27 GMT</pubDate>
      <guid>https://community.cisco.com/t5/network-security/nat-hairpin-problem/m-p/1458684#M642212</guid>
      <dc:creator>Federico Coto Fajardo</dc:creator>
      <dc:date>2010-06-07T22:21:27Z</dc:date>
    </item>
    <item>
      <title>Re: NAT Hairpin Problem</title>
      <link>https://community.cisco.com/t5/network-security/nat-hairpin-problem/m-p/1458685#M642213</link>
      <description>&lt;HTML&gt;&lt;HEAD&gt;&lt;/HEAD&gt;&lt;BODY&gt;&lt;P&gt;Hi Federico.&lt;/P&gt;&lt;P&gt;&lt;/P&gt;&lt;P&gt;The 24.x.x.x IP is the public IP of the webser and is NAT'd to 172.22.35.10.&lt;/P&gt;&lt;P&gt;&lt;/P&gt;&lt;P&gt;Currently when an inside user does a DNS query for the FQDN of the website, the DNS serever translates it to 24.x.x.x.&amp;nbsp; Since the webserver is actually on the inside (172.22.35.10), the inside host will not be able to access it by using the FQDN.&amp;nbsp; I thought I understood that I could setup a hairpin the way I described&amp;nbsp; in my original post to re-direct any traffic coming from the 10.156.16.x&amp;nbsp; network to the internal IP of the web server.&amp;nbsp; Something similar is outlined here: &lt;A href="http://www.cisco.com/en/US/products/ps6120/products_configuration_example09186a00807968d1.shtml#solution2"&gt;http://www.cisco.com/en/US/products/ps6120/products_configuration_example09186a00807968d1.shtml#solution2&lt;/A&gt;&lt;/P&gt;&lt;P&gt;&lt;/P&gt;&lt;P&gt;So as I see it, this what is happening: 10.156.16.28 makes a DNS query for realcoolwebsite.com and the DNS server tells it the IP is 24.x.x.x.x.&amp;nbsp; Since this IP doesn't reside on the network the router sends it to the default gateway (the ASA).&amp;nbsp; The ASA was dropping the traffic before I added the static statement and the same-security permit intra-interface command.&amp;nbsp; After I add those command the ASA now un-NAT's (that's what it is called in the output of packet-tracer) 24.x.x.x to 172.22.35.10 and sends it back inside.&amp;nbsp; This is proved out in the trace files and the fact that I can ping 24.x.x.x from 10.156.16.28.&lt;/P&gt;&lt;/BODY&gt;&lt;/HTML&gt;</description>
      <pubDate>Mon, 07 Jun 2010 22:52:59 GMT</pubDate>
      <guid>https://community.cisco.com/t5/network-security/nat-hairpin-problem/m-p/1458685#M642213</guid>
      <dc:creator>terrygwazdosky</dc:creator>
      <dc:date>2010-06-07T22:52:59Z</dc:date>
    </item>
    <item>
      <title>Re: NAT Hairpin Problem</title>
      <link>https://community.cisco.com/t5/network-security/nat-hairpin-problem/m-p/1458686#M642214</link>
      <description>&lt;HTML&gt;&lt;HEAD&gt;&lt;/HEAD&gt;&lt;BODY&gt;&lt;P&gt;Correct me if I'm wrong please.&lt;/P&gt;&lt;P&gt;&lt;BR /&gt;The internal client needs to access the web server.&lt;BR /&gt;So, it does a DNS lookup and the DNS server replies with the public IP 24.x.x.x &lt;BR /&gt;The client will send that traffic to the ASA. &lt;BR /&gt;However, the ASA will normally sent this traffic to the outside, but since the webserver is inside, &lt;BR /&gt;the ASA needs to redirect this to the inside interface again. &lt;BR /&gt;You can't do DNS doctoring since the DNS server is also on the inside.&lt;/P&gt;&lt;P&gt;&lt;/P&gt;&lt;P&gt;Then,&lt;BR /&gt;With this command: &lt;BR /&gt;static (inside,inside) 24.x.x.x 172.22.35.10&lt;BR /&gt;The ASA will accept packets intended to 24.x.x.x and send them to 172.22.35.10&lt;/P&gt;&lt;P&gt;This is working since you're able to PING 24.x.x.x from 10.156.156.28&lt;/P&gt;&lt;P&gt;The problem seems with browsing or telneting to that 24.x.x.x&lt;/P&gt;&lt;P&gt;&lt;/P&gt;&lt;P&gt;There are no ACLs applied to the inside interface of the ASA that might be blocking these ports?&lt;BR /&gt;I assume not since Packet Tracer tells you the connection should go through.&lt;/P&gt;&lt;P&gt;&lt;/P&gt;&lt;P&gt;You can try a ''capture'' that should give us more details:&lt;/P&gt;&lt;P&gt;&lt;/P&gt;&lt;P&gt;CAPTURE INSIDE INTERFACE &lt;BR /&gt;access-list test permit tcp host 10.156.156.28 host 24.x.x.x&lt;BR /&gt;access-list test permit tcp host 24.x.x.x host 10.156.156.28&lt;BR /&gt;capture test access-list test interface inside trace&lt;/P&gt;&lt;P&gt;&lt;/P&gt;&lt;P&gt;The get the output using Wireshark&lt;/P&gt;&lt;P&gt;Federico.&lt;/P&gt;&lt;/BODY&gt;&lt;/HTML&gt;</description>
      <pubDate>Mon, 07 Jun 2010 23:28:34 GMT</pubDate>
      <guid>https://community.cisco.com/t5/network-security/nat-hairpin-problem/m-p/1458686#M642214</guid>
      <dc:creator>Federico Coto Fajardo</dc:creator>
      <dc:date>2010-06-07T23:28:34Z</dc:date>
    </item>
    <item>
      <title>Re: NAT Hairpin Problem</title>
      <link>https://community.cisco.com/t5/network-security/nat-hairpin-problem/m-p/1458687#M642215</link>
      <description>&lt;HTML&gt;&lt;HEAD&gt;&lt;/HEAD&gt;&lt;BODY&gt;&lt;P&gt;Federico:&lt;/P&gt;&lt;P&gt;&lt;/P&gt;&lt;P&gt;Talking it out with you and a good night's sleep showed me where I went wrong.&amp;nbsp; I did not include the global and nat stetments and had instead added a nat0 ACL entry.&amp;nbsp; I fixed that with these commands:&lt;/P&gt;&lt;P&gt;global (inside) 98 interface&lt;/P&gt;&lt;P&gt;nat (inside) 98 10.156.16.28 255.255.255.255&lt;/P&gt;&lt;P&gt;&lt;/P&gt;&lt;P&gt;What was happening was basically a triangle effect and the 10.156.16.28 host was dropping the traffic as it didn't expect it.&amp;nbsp; Ping presumably worked because of the stateless nature of ICMP.&lt;/P&gt;&lt;P&gt;&lt;/P&gt;&lt;P&gt;Now I can access the website.&amp;nbsp; However, the 10.156.16.28 host cannot access anything on the outside because the nat &amp;amp; global statements that were being used are now superseded by the better macth.&amp;nbsp; Normally it would match the following for outside connections:&lt;/P&gt;&lt;P&gt;global (outside) 1 36.x.x.x&lt;/P&gt;&lt;P&gt;nat (inside) 1 10.156.16.0 255.255.255.0&lt;/P&gt;&lt;P&gt;&lt;/P&gt;&lt;P&gt;Any thoughts on how I can make the hairpin work as well as allow the 10.156.16.28 host to be translated to 36.x.x.x when it goes to the internet?&lt;/P&gt;&lt;/BODY&gt;&lt;/HTML&gt;</description>
      <pubDate>Tue, 08 Jun 2010 12:08:18 GMT</pubDate>
      <guid>https://community.cisco.com/t5/network-security/nat-hairpin-problem/m-p/1458687#M642215</guid>
      <dc:creator>terrygwazdosky</dc:creator>
      <dc:date>2010-06-08T12:08:18Z</dc:date>
    </item>
    <item>
      <title>Re: NAT Hairpin Problem</title>
      <link>https://community.cisco.com/t5/network-security/nat-hairpin-problem/m-p/1458688#M642216</link>
      <description>&lt;HTML&gt;&lt;HEAD&gt;&lt;/HEAD&gt;&lt;BODY&gt;&lt;P&gt;Hi,&lt;/P&gt;&lt;P&gt;&lt;/P&gt;&lt;P&gt;I imagine you can use policy NAT.&lt;/P&gt;&lt;P&gt;&lt;/P&gt;&lt;P&gt;access-list hairpin permit ip host 10.156.16.28 host 24.x.x.x&lt;BR /&gt;nat (inside) 10 access-list hairpin&lt;BR /&gt;global (inside) 10 interface&lt;/P&gt;&lt;P&gt;&lt;/P&gt;&lt;P&gt;access-list internet permit ip host 10.156.16.28 any &lt;BR /&gt;nat (inside) 20 access-list internet&lt;BR /&gt;global (outside) 20 interface&lt;/P&gt;&lt;P&gt;&lt;/P&gt;&lt;P&gt;The idea is that you define only when going to 24.x.x.x to do the hairpining and&lt;BR /&gt;everything else will be PATed to the internet.&lt;/P&gt;&lt;P&gt;Federico.&lt;/P&gt;&lt;/BODY&gt;&lt;/HTML&gt;</description>
      <pubDate>Tue, 08 Jun 2010 12:30:42 GMT</pubDate>
      <guid>https://community.cisco.com/t5/network-security/nat-hairpin-problem/m-p/1458688#M642216</guid>
      <dc:creator>Federico Coto Fajardo</dc:creator>
      <dc:date>2010-06-08T12:30:42Z</dc:date>
    </item>
    <item>
      <title>Re: NAT Hairpin Problem</title>
      <link>https://community.cisco.com/t5/network-security/nat-hairpin-problem/m-p/1458689#M642217</link>
      <description>&lt;HTML&gt;&lt;HEAD&gt;&lt;/HEAD&gt;&lt;BODY&gt;&lt;P&gt;I can't believe I forgot about policy NAT! &lt;SPAN __jive_emoticon_name="blush" __jive_macro_name="emoticon" class="jive_macro jive_emote" src="https://community.cisco.com/images/emoticons/blush.gif"&gt;&lt;/SPAN&gt;&amp;nbsp; You're absolutely right.&amp;nbsp; Thanks so much.&lt;/P&gt;&lt;/BODY&gt;&lt;/HTML&gt;</description>
      <pubDate>Tue, 08 Jun 2010 12:37:02 GMT</pubDate>
      <guid>https://community.cisco.com/t5/network-security/nat-hairpin-problem/m-p/1458689#M642217</guid>
      <dc:creator>terrygwazdosky</dc:creator>
      <dc:date>2010-06-08T12:37:02Z</dc:date>
    </item>
  </channel>
</rss>

