<?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 possible NAT issue???  proxy arp???? in Network Security</title>
    <link>https://community.cisco.com/t5/network-security/possible-nat-issue-proxy-arp/m-p/3186304#M1065971</link>
    <description>&lt;P&gt;Upgrading from PIX (6.3) to an ASA 5515 (9.4). Went to make switch other day, and had to backout due to a specific application inside the DMZ not being able to reach an&amp;nbsp;outside destination host. Here is scenario:&lt;/P&gt;&lt;P&gt;Src Host 172.16.10.10 behind DMZ interface (sec level 50)&lt;/P&gt;&lt;P&gt;Dst Host 192.168.1.1 behind Outside interface (sec level 0)&lt;/P&gt;&lt;P&gt;&amp;nbsp;&lt;/P&gt;&lt;P&gt;Src host get's NAT'd to 10.1.1.1 when sending traffic outside. Below is statement on ASA firewall for the NAT&lt;/P&gt;&lt;P&gt;nat (DMZ,Outside source static OBJ-172.16.10.10 OBJ-10.1.1.1&lt;/P&gt;&lt;P&gt;Packet capture taken on ingress and egress interface shows packet entering and leaving, shows the correct src NAT address on its way out the egress interface; shown below&lt;/P&gt;&lt;P&gt;10.1.1.1.51801 &amp;gt; 192.168.1.1.5631: S&lt;BR /&gt;10.1.1.1.51801 &amp;gt; 192.168.1.1.5631: S&lt;BR /&gt;10.1.1.1.51801 &amp;gt; 192.168.1.1.5631: S&lt;/P&gt;&lt;P&gt;&amp;nbsp;&lt;/P&gt;&lt;P&gt;I see no response from the server. As soon as I put PIX back in place, it starts working. The PIX NAT looks like this:&lt;/P&gt;&lt;P&gt;static (DMZ,Outside) 10.1.1.1&amp;nbsp;172.16.10.10 netmask 255.255.255.255 0 0&lt;/P&gt;&lt;P&gt;Connection and XLATE table on PIX look like this when the connection is successful:&lt;/P&gt;&lt;P&gt;LabFW1(config)# sh conn&lt;/P&gt;&lt;P&gt;1 in use, 1 most used&lt;/P&gt;&lt;P&gt;TCP out 192.168.1.1:5631 in 172.16.10.10:51806 idle 0:00:00 Bytes 99541 flags UIO&lt;/P&gt;&lt;P&gt;WMOTFPPLabFW1(config)# sh xlate&lt;/P&gt;&lt;P&gt;1 in use, 1 most used&lt;/P&gt;&lt;P&gt;Global&amp;nbsp;10.1.1.1 Local 172.16.10.10&lt;/P&gt;&lt;P&gt;****************************************&lt;/P&gt;&lt;P&gt;Any idea what would make no return traffic? would proxy arp have anything to do with this? I took the existing static commands from my PIX and ran them through an online converter tool when I built the ASA config, but noticed it didn't append the statements with "no-proxy-arp route-lookup" as I've since seen on some other NAT statements. Would the absense of those keywords have anything to do with no return traffic? Routing is good, I can ping the gateway, just seems tied to this DMZ computer that gets NATd. Not quite clear on what, if any, difference there is in a NAT statement with vs without those appended keywords.&lt;/P&gt;&lt;P&gt;&amp;nbsp;&lt;/P&gt;&lt;P&gt;any help appreciated!&lt;/P&gt;&lt;P&gt;&amp;nbsp;&lt;/P&gt;&lt;P&gt;&amp;nbsp;&lt;/P&gt;</description>
    <pubDate>Fri, 21 Feb 2020 14:20:04 GMT</pubDate>
    <dc:creator>mjsully</dc:creator>
    <dc:date>2020-02-21T14:20:04Z</dc:date>
    <item>
      <title>possible NAT issue???  proxy arp????</title>
      <link>https://community.cisco.com/t5/network-security/possible-nat-issue-proxy-arp/m-p/3186304#M1065971</link>
      <description>&lt;P&gt;Upgrading from PIX (6.3) to an ASA 5515 (9.4). Went to make switch other day, and had to backout due to a specific application inside the DMZ not being able to reach an&amp;nbsp;outside destination host. Here is scenario:&lt;/P&gt;&lt;P&gt;Src Host 172.16.10.10 behind DMZ interface (sec level 50)&lt;/P&gt;&lt;P&gt;Dst Host 192.168.1.1 behind Outside interface (sec level 0)&lt;/P&gt;&lt;P&gt;&amp;nbsp;&lt;/P&gt;&lt;P&gt;Src host get's NAT'd to 10.1.1.1 when sending traffic outside. Below is statement on ASA firewall for the NAT&lt;/P&gt;&lt;P&gt;nat (DMZ,Outside source static OBJ-172.16.10.10 OBJ-10.1.1.1&lt;/P&gt;&lt;P&gt;Packet capture taken on ingress and egress interface shows packet entering and leaving, shows the correct src NAT address on its way out the egress interface; shown below&lt;/P&gt;&lt;P&gt;10.1.1.1.51801 &amp;gt; 192.168.1.1.5631: S&lt;BR /&gt;10.1.1.1.51801 &amp;gt; 192.168.1.1.5631: S&lt;BR /&gt;10.1.1.1.51801 &amp;gt; 192.168.1.1.5631: S&lt;/P&gt;&lt;P&gt;&amp;nbsp;&lt;/P&gt;&lt;P&gt;I see no response from the server. As soon as I put PIX back in place, it starts working. The PIX NAT looks like this:&lt;/P&gt;&lt;P&gt;static (DMZ,Outside) 10.1.1.1&amp;nbsp;172.16.10.10 netmask 255.255.255.255 0 0&lt;/P&gt;&lt;P&gt;Connection and XLATE table on PIX look like this when the connection is successful:&lt;/P&gt;&lt;P&gt;LabFW1(config)# sh conn&lt;/P&gt;&lt;P&gt;1 in use, 1 most used&lt;/P&gt;&lt;P&gt;TCP out 192.168.1.1:5631 in 172.16.10.10:51806 idle 0:00:00 Bytes 99541 flags UIO&lt;/P&gt;&lt;P&gt;WMOTFPPLabFW1(config)# sh xlate&lt;/P&gt;&lt;P&gt;1 in use, 1 most used&lt;/P&gt;&lt;P&gt;Global&amp;nbsp;10.1.1.1 Local 172.16.10.10&lt;/P&gt;&lt;P&gt;****************************************&lt;/P&gt;&lt;P&gt;Any idea what would make no return traffic? would proxy arp have anything to do with this? I took the existing static commands from my PIX and ran them through an online converter tool when I built the ASA config, but noticed it didn't append the statements with "no-proxy-arp route-lookup" as I've since seen on some other NAT statements. Would the absense of those keywords have anything to do with no return traffic? Routing is good, I can ping the gateway, just seems tied to this DMZ computer that gets NATd. Not quite clear on what, if any, difference there is in a NAT statement with vs without those appended keywords.&lt;/P&gt;&lt;P&gt;&amp;nbsp;&lt;/P&gt;&lt;P&gt;any help appreciated!&lt;/P&gt;&lt;P&gt;&amp;nbsp;&lt;/P&gt;&lt;P&gt;&amp;nbsp;&lt;/P&gt;</description>
      <pubDate>Fri, 21 Feb 2020 14:20:04 GMT</pubDate>
      <guid>https://community.cisco.com/t5/network-security/possible-nat-issue-proxy-arp/m-p/3186304#M1065971</guid>
      <dc:creator>mjsully</dc:creator>
      <dc:date>2020-02-21T14:20:04Z</dc:date>
    </item>
    <item>
      <title>Re: possible NAT issue???  proxy arp????</title>
      <link>https://community.cisco.com/t5/network-security/possible-nat-issue-proxy-arp/m-p/3186336#M1065972</link>
      <description>&lt;P&gt;Hi mjsully,&lt;/P&gt;&lt;P&gt;&amp;nbsp;&lt;/P&gt;&lt;P&gt;Your configurtion on ASA looks good. It seems that host&amp;nbsp;&lt;SPAN&gt;192.168.1.1 has an ARP issue. Have you tried to refresh the ARP table of host&amp;nbsp;192.168.1.1?&lt;/SPAN&gt;&lt;/P&gt;</description>
      <pubDate>Tue, 19 Sep 2017 21:46:05 GMT</pubDate>
      <guid>https://community.cisco.com/t5/network-security/possible-nat-issue-proxy-arp/m-p/3186336#M1065972</guid>
      <dc:creator>Spooster IT Services</dc:creator>
      <dc:date>2017-09-19T21:46:05Z</dc:date>
    </item>
    <item>
      <title>Re: possible NAT issue???  proxy arp????</title>
      <link>https://community.cisco.com/t5/network-security/possible-nat-issue-proxy-arp/m-p/3186375#M1065973</link>
      <description>&lt;P&gt;thanks for the reply. I don't think the remote host has the arp issue. I failed to mentiion that the remote host 192.168.1.1 is NOT located locally to the ASA's outside interface. In other words, its a remote network that the ASA only reaches by sending to a specific route for that network. So I believe the only arp involved for the remote host would involve its gateway back to the ASA. But I'm wondering if there is an arp issue on a device in&amp;nbsp; between that has the MAC of the old PIX for the SRC NAT, but I'm not 100% sure on how that works which is why I am posing the question about whether or not my NAT statements make the NAT behave different if I don't have the no-proxy-arp route-lookup keywords.&lt;/P&gt;</description>
      <pubDate>Tue, 19 Sep 2017 22:44:31 GMT</pubDate>
      <guid>https://community.cisco.com/t5/network-security/possible-nat-issue-proxy-arp/m-p/3186375#M1065973</guid>
      <dc:creator>mjsully</dc:creator>
      <dc:date>2017-09-19T22:44:31Z</dc:date>
    </item>
  </channel>
</rss>

