12-07-2015 08:49 PM - edited 03-12-2019 12:00 AM
//Excuse me for my English in advance
Greetings everyone! Need assistance. I can't get work logic of ASA's routing decision process (IOS - 9.2(4)). NAT rules override routing table they said. But that's what I get:
I have ASA, let's say, with 2 interfaces. "inside" and "srv-mng". "srv-mng" interface is terminating 10.132.162.0/24 subnet. All other networks is on "inside", ASA even gets it's default route from there. For some reason I want host 10.132.162.16 (on "srv-mng") to be accessed by IP address 172.16.10.10 from "inside". I configure:
//Interfaces
interface GigabitEthernet1/0.402
vlan 402
nameif srv-mng
security-level 94
ip address 10.132.162.1 255.255.255.0
interface GigabitEthernet1/3.400
vlan 400
nameif inside
security-level 90
ip address 10.133.226.5 255.255.255.248 standby 10.133.226.6
//Route for redistribution to routing protocol running on ASA and "inside" routers
route Null0 172.16.10.10 255.255.255.255 1
//NAT rule and objects
object network test_srv-mng
host 10.132.162.16
object network test_test
host 172.16.10.10
nat (srv-mng,inside) source static test_srv-mng test_test
//End of configuration
//Confirmation
asa# show run nat
nat (srv-mng,inside) source static test_srv-mng test_test
asa# show xlate
...
NAT from srv-mng:10.132.162.16 to inside:172.16.10.10
flags sT idle 0:00:05 timeout 0:00:00
...
Then i'm trying to access 172.16.10.10 from inside host 10.132.0.147. Vainly. Let's see logs of that process.
%ASA-6-110002: Failed to locate egress interface for TCP from inside:10.132.0.147/7005 to 172.16.10.10/80
Let's use "packet-tracer" feature.
asa# packet-tracer input inside tcp 10.132.0.147 7005 172.16.10.10 80
Result:
input-interface: inside
input-status: up
input-line-status: up
Action: drop
Drop-reason: (no-route) No route to host
So this is my question. Why is that way? I know route aims Null0 interface, but NAT should define egress interface ("srv-mng") and it does. NAT is static so it should do it both ways. Am I wrong? What do I miss?
Solved! Go to Solution.
12-08-2015 06:41 AM
Hi,
You are using 172.16.10.10 which is different subnet than your 'svr-mng' subnet which is 10.132.162.x subnet. Now ASA would not respond to ARP request coming from DMZ server. Therefore ASA would consider it in a way that ASA is not supposed to have any details related to this host. Therefore please run the below command and test :
"arp permit-nonconnected". Also remove 'route Null0 172.16.10.10 255.255.255.255 1'. Without this it should work.
Hope it helps.
Regards,
Akshay Rastogi
Remember to rate helpful posts.
12-08-2015 06:41 AM
Hi,
You are using 172.16.10.10 which is different subnet than your 'svr-mng' subnet which is 10.132.162.x subnet. Now ASA would not respond to ARP request coming from DMZ server. Therefore ASA would consider it in a way that ASA is not supposed to have any details related to this host. Therefore please run the below command and test :
"arp permit-nonconnected". Also remove 'route Null0 172.16.10.10 255.255.255.255 1'. Without this it should work.
Hope it helps.
Regards,
Akshay Rastogi
Remember to rate helpful posts.
12-08-2015 06:34 PM
Good day, Akshay! Thanks for your reply!
I deleted that static route. Therefore, to maintain routing, I need to migrate that staic route to the first hop router on "inside" ASA interface (and do not redistribute it) . It looks like:
ip route 172.16.10.10 255.255.255.255 10.133.226.5 //10.133.226.5 IP-addr of the "inside"
Also I commited in ASA configuration "arp permit-nonconnected" as you told me.
That's what i got in logs:
%ASA-2-106001: Inbound TCP connection denied from 10.132.0.147/2257 to 172.16.10.10/80 flags SYN on interface inside
Packet-tracer gave me output:
asa# packet-tracer input inside tcp 10.132.0.147 6745 172.16.10.10 80
Phase: 1
Type: ROUTE-LOOKUP
Subtype: Resolve Egress Interface
Result: ALLOW
Config:
Additional Information:
in 0.0.0.0 0.0.0.0 via 10.133.226.3, inside
Phase: 2
Type: ACCESS-LIST
Subtype:
Result: DROP
Config:
Implicit Rule
Additional Information:
Result:
input-interface: inside
input-status: up
input-line-status: up
output-interface: inside
output-status: up
output-line-status: up
Action: drop
Drop-reason: (acl-drop) Flow is denied by configured rule
Yes, as I told earlier, ASA gets default from the "inside". By some reason ASA decides to route packets back to the "inside" interface despite NAT rule. I am eager to know why, to understand routing process.
12-09-2015 08:39 PM
There was mismatch positions of NAT rules. With executed "arp permit-nonconnected" it works just fine. Thank you, Akshay. It was very helpful.
Discover and save your favorite ideas. Come back to expert answers, step-by-step guides, recent topics, and more.
New here? Get started with these tips. How to use Community New member guide