ASA Fails to tftp config to server inside on a subnet the ASA routes to

Hello, folks. I am having a problem pushing an ASA’s config from itself to the tftp server. The server is reached via a route over its inside subnet, but the ASA doesn’t share a subnet with the tftp server.

The ASA’s inside address is 192.168.138.3, and it has only two routes:

S*       0.0.0.0 0.0.0.0 [100/0] via W.X.Y.Z, outside
S        192.168.107.0 255.255.255.0 [1/0] via 192.168.138.1, inside

The ASA can ping the tftp server at 192.168.107.252 as expected, and can traceroute its way there without issue:

ping 192.168.107.252
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 192.168.107.252, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 1/2/10 ms


traceroute 192.168.107.252

Type escape sequence to abort.
Tracing the route to 192.168.107.252

 1  192.168.138.1 1 msec 1 msec 1 msec
 2  192.168.107.252 1 msec 1 msec 1 msec

Every time I try to tftp the ASA’s config file to 192.168.107.252, it fails with the message, “Unable to reach server 192.168.107.252
%Error opening tftp://192.168.107.252/192.168.138.3 (Resource temporarily unavailable)”

I dug in with packet-tracer, and am very confused with the access-list drop that is occurring -

packet-tracer input inside_1 udp 192.168.138.3 9999 192.168.107.252 tftp detailed

Phase: 1
Type: ACCESS-LIST
Subtype:
Result: ALLOW
Config:
Implicit Rule
Additional Information:
Forward Flow based lookup yields rule:
in id=0x7fdc183d3740, priority=1, domain=permit, deny=false
hits=7148171871, user_data=0x0, cs_id=0x0, l3_type=0x8
src mac=0000.0000.0000, mask=0000.0000.0000
dst mac=0000.0000.0000, mask=0100.0000.0000
input_ifc=inside_1, output_ifc=any

Phase: 2
Type: ROUTE-LOOKUP
Subtype: Resolve Egress Interface
Result: ALLOW
Config:
Additional Information:
found next-hop 192.168.138.1 using egress ifc inside

Phase: 3
Type: ROUTE-LOOKUP
Subtype: Resolve Egress Interface
Result: ALLOW
Config:
Additional Information:
found next-hop 192.168.138.1 using egress ifc inside

Phase: 4
Type: ADJACENCY-LOOKUP
Subtype: next-hop and adjacency
Result: ALLOW
Config:
Additional Information:
adjacency Active
next-hop mac address ffff.ffff.ffff hits 539381 reference 46

Phase: 5
Type: ACCESS-LIST
Subtype:
Result: DROP
Config:
Implicit Rule
Additional Information:
Forward Flow based lookup yields rule:
in id=0x7fdc184f8530, priority=501, domain=permit, deny=true
hits=3, user_data=0x7, cs_id=0x0, reverse, flags=0x0, protocol=0
src ip/id=192.168.138.3, mask=255.255.255.255, port=0, tag=any
dst ip/id=0.0.0.0, mask=0.0.0.0, port=0, tag=any, dscp=0x0
input_ifc=inside_1, output_ifc=any

Result:
input-interface: inside_1
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

If I’m interpreting this correctly, despite knowing that the way to 192.168.107.0/24 is through 192.168.138.1, the ASA seems to be sending these tftp packets out the outside interface. It mentions the general route to 0.0.0.0 rather than the specific route it is aware of to 192.168.107.0/24. What is happening that it is aware of the correct route for icmp but is going the wrong way with tftp?

Hello James

It looks to me that you have an access list that is blocking the specific communication. In Phase 5 it states that you have a drop due to an implicit rule in an access list. What the “implicit rule” here states is that it is the implicit deny that is at the end of an access list that has blocked this communication. This means that your pings and traceroutes have explicitly been allowed in the ACL, but not your TFTP communication.

Note that Phases 2 and 3 indicate that the correct next hop and egress interface have been found. Phase 4 indicates that an adjacency has also been found with the next hop router, but its MAC wasn’t in the ARP table, so ARP with a broadcast MAC was used to determine the next hop MAC address.

Ultimately, you’ll have to look at your access lists. The result at the end stating: Drop-reason: (acl-drop) Flow is denied by configured rule verifies that the problem is in an ACL.

I hope this has been helpful!

Laz