cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
12840
Views
0
Helpful
3
Replies

[ASA] Drop-reason: (no-route) No route to host

e.maksyukov
Level 1
Level 1

//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?

1 Accepted Solution

Accepted Solutions

Akshay Rastogi
Cisco Employee
Cisco Employee

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.

View solution in original post

3 Replies 3

Akshay Rastogi
Cisco Employee
Cisco Employee

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.

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.

There was mismatch positions of NAT rules. With executed "arp permit-nonconnected" it works just fine. Thank you, Akshay. It was very helpful. 

Review Cisco Networking for a $25 gift card