Traffic not passing through NAT

[DaveJones24876]

Hello,

I have a situation with an ASA 5508-X where I cannot get any traffic to pass through on anything other than it's own IP address on the outside interface. To clarify, the outside interface has a /28 on say 1.2.3.34/28. Traffic passes through for 1.2.3.34 but not 35-46.
I am upgrading from ASA 5510s which have a similar config (minus the post 8.3 NAT changes) so I'm quite baffled.

I do have hosts configured and NAT statements for them under the IPs 35-46.

I also have 2 more sets of /28 that are routed to my outside interface that DOES work, and the NAT statements are exactly the same (minus the host IP address of course).

Here is what I have:

interface Redundant1.1
 vlan xxx
 nameif outside
 security-level 0
 ip address 1.2.3.34 255.255.255.240 

route outside 0.0.0.0 0.0.0.0 1.2.3.33 1

object network Web1
host 192.168.0.2

object network E3
host 192.168.0.3

object network v1
subnet 192.168.0.0 255.255.255.0

object-group service DM_INLINE_SERVICE_5
service-object icmp 
service-object tcp-udp destination eq domain 

access-list outside_access_in extended permit icmp any any 
access-list v1_access_in extended permit object-group DM_INLINE_SERVICE_5 192.168.0.0 255.255.255.0 any 

Does not work:
object network Web1
 nat (v1,outside) static 1.2.3.35

Does work:
object network E3
 nat (v1,outside) static 1.2.3.78

I also have a NAT statement for everything else that's not matched, so everything that sits behind .34 without a specific static NAT is working fine.

object network VNAT
 nat (v1,outside) dynamic interface

Hopefully this makes sense, I'm sure I'm missing something small.

Thanks.

[Sheraz.Salim]

try this,

object network Web1_Public
host 1.2.3.35
!
nat (v1,outside) source static Web1 Web1_Public
!
object network E3_Public
host 1.2.3.78
!
nat (v1,outside) source static E3 E3_public
!

[bhargavdesai]

Can you post packet tracer output.
Moreover, i would say that you should also check for Proxy-arp issue.
To overcome you can make a static host route (1.2.3.35) on the upstream router just to check.

HTH
### RATE ALL HELPFUL RESPONSES ###

[DaveJones24876]

Thanks Sheraz, I'll try that when I can get there next (hopefully tomorrow night). I had to plug in the 5510 until I get this working.

bhargavdesai, I'll run a packet trace when I am in next as mentioned above. 

Just odd that no IPs within the /28 can be NATted but the routed IPs (such as the .78) can using the same statements. Is this a common issue (byt that I mean an incorrect config) that I somehow have just never faced?

[Marius Gunnerud]

Yes packet tracer would be good to look at. 

But I do not quite understand what is not working.  Is it from the server to internet or from internet to the server?  If the issue is that the server cannot reach the internet and the ACL you have posted is all you have configured for this interface then that is where the problem is.  You are only permitting DNS traffic.

[DaveJones24876]

Hi Marius,

I only posted a basic ACL to show things were in place. In reality there are many more to allow http/https, etc but in this example I kept it simple. 

Both directions cannot ping when the NAT rule(s) above are in place. Otherwise the host can ping as 1.2.3.34.

I did run a packet tracer from the v1 interface a couple of days ago and it passed.

[Marius Gunnerud]

And in that packet tracer was traffic hitting the correct NAT statements?  It sounds like traffic from Web1 is matching a different NAT rule than the one you intent it to match.

[bhargavdesai]

As you mentioned that Packet-tracer is fine and hitting right NAT rule, moreover the IP configured on the outside interface along with the other subnets which are routed by the upstream router is working fine in NAT statement. As I mentioned earlier, I suspect proxy-arp issue. To confirm this, I would say check the ARP table of the upstream router, you will find arp entries for all your NATTED IPs (expecting that traffic is flowing constantly on those not flushing the arp before the timer expires). Even if you send traffic to the 1.2.3.35 from outside, you will see the ARP entry on the upstream router will show INCOMPLETE. because ASA is not proxy-arp for that IP.

You can check that proxy-arp is not disabled on the OUTSIDE interface.
Can you post "sh run all | inc sysopt" output.
You can also try (for testing) putting host route on the upstream router. (ip route 1.2.3.35 255.255.255.255 1.2.3.34)



HTH
### RATE ALL HELPFUL RESPONSES ###

[Marius Gunnerud]

I highly doubt the issue is with proxy arp as this is enabled by default in ASA and to turn it off you would need to manually add the no-proxy-arp statement at the end of the NAT statement, which is not present in the NAT statement posted.

[bhargavdesai]

With all due respect to Expert Marius Gunnerud, I saw that there is no argument of no-proxy-arp, hence i requested for the "Can you post "sh run all | inc sysopt" output." As per the user packet tracer is working, so i thought that Proxy-arp is disabled on the interface level.

To check in the first place if ASA is receiving request for IP 1.2.3.35, Can you run packet capture on the outside interface and see if you are receiving packets for the host.

capture CAP interface OUTSIDE match ip any host 1.2.3.35
show capture
show capture CAP

I would request for full configuration (Remove public IPs and credentials) along with packet-tracer output.

HTH
### RATE ALL HELPFUL RESPONSES ###

[DaveJones24876]

Thanks for your time everyone. Turns out it was a service policy/ICMP inspection.

Had a Cisco engineer look at it and after 2 hours mind you, input a protocol fixup and that was it.

I should have toyed with that but sometimes you just need that second pair of eyes...