Anyone have any ideas or pointers for accessing devices through NAT on an ASA? I've got a VMware server with several different Voice apps on it but they are on a network I can't route.
I'm trying to NAT a 10.x.x.x network to a 172.x.x.x network. The inside/outside interfaces are on different subnets from the NAT addresses, I've got static routes to take care of this. I've tried every combo of NAT I can think of and/or find on the line. I can ping the different servers and I can also see in the logs that a connection was made for 443 yet no webpage. Same thing for port 22.
I've followed the guide below, which has a different way than what I was doing things but still same results. I'm at a loss for what I could be missing.
http://www.cisco.com/c/en/us/td/docs/security/asa/asa91/configuration/firewall/asa_91_firewall_config/nat_objects.html#30173
Create rules to permit the traffic. If the interfaces have the same trust level, then permit traffic between interfaces with the same trust level.
Just so I understand:
Your servers are on 10.x.x.x and you've NATed them to 172.x.x.x. A host on the outside is trying to get to the NAT IP of 172.x.x.x (which translates to 10.x.x.x), right? And you also said the inside of the firewall knows how to get to 10.x.x.x, right?
Here's a few issues I've come across:
- The FW rule permits the traffic, but the packet doesn't NAT
---Look at the logs for syslog IDs 305011 and 305012. If you don't see them, then the packet isn't getting NATed. It sounds like you're seeing syslogs for the sessions being built (and maybe also for traffic getting permitted depending if you're logging on your ACLs), but you should also see some for translations occurring
- The FW rule doesn't permit the traffic
---Make sure the object IP is what the FW expects it to be based on its perspective of where the packet is ingressing. If the traffic is ingressing on the outside interface and the outside interface should only ever know of the 172.x.x.x IP and NOT the 10.x.x.x, then make sure the object IP is 172.x.x.x
- The FW rule should havepermitted the traffic, but NAT RFP drops the packet because of "asymmetric NAT rules matched" (305013). This error is saying that the traffic is getting NATed by two different rules on the forward and reverse direction.
---I'm still on the fence on whether I should turn off NAT RFP globally, but for now I carefully scan the NAT rule for the culprit NAT rules
---I commonly have this issue when I'm doing object-NAT in combination with some global, catch-all no-NATs (or Identity NAT, I think is what ASA calls it)
If none of the above help, could you post the pertinent output of the following commands:
- sh run object id <ObjectName>
- sh run nat (for the object)
- sh run access-list (where the object is listed)
- sh log | include <IP of outside source>
- sh log | include <NAT IP>
- sh log | include <Server Real IP>
- show nat (where the object/IP is listed)
- show xlate (for the IPs in question)
Thanks for the responses guys. So evidently the guys onsite had something plugged in wrong and the outside interface ended up being on the same LAN segment as a SVI on the core switch which also had an SVI for the inside interface so the server traffic had an alternate path back. So long story short we got it working after a ton of wasted time. :wall: :wall: :wall: