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=anyPhase: 2
Type: ROUTE-LOOKUP
Subtype: Resolve Egress Interface
Result: ALLOW
Config:
Additional Information:
found next-hop 192.168.138.1 using egress ifc insidePhase: 3
Type: ROUTE-LOOKUP
Subtype: Resolve Egress Interface
Result: ALLOW
Config:
Additional Information:
found next-hop 192.168.138.1 using egress ifc insidePhase: 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 46Phase: 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=anyResult:
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?