cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
1419
Views
0
Helpful
7
Replies

ACL not working for TFTP download.

patel.nishit
Level 1
Level 1

I have an 877W ROUTER

Ethernets are VLAN1

Wireless is DOT11RADIO 0

Internet is DIALER1

I wish VLAN1 to have full access to both DIALER1 and DOT11RADIO 0 networks

I wish DOT11RADIO 0 to have limited access to EVERYWHERE (i.e. DIALER1 & VLAN1) - this is achieved by means of EXTENDED ACCESS-LIST 101 applied to Interface DOT11RADIO 0

I have this almost working, but I cannot run a TFTP server on DOT11RADIO 0 AND copy configurations from the 877W to the TFTP server. The router can see UDP PORT 69 but reply traffic seems to be blocked.

Attached is a drawing of the network, the running config and some logs of the blocked traffic when I attempt to copy to the TFTP server on DOT11RADIO 0.

If I remove EXTENDED ACCESS-LIST 101 I can copy to the TFTP server just fine. The logging shows ACL 101 is the problem. I just can't work out how get the access lists right to get TFTP working from the 877W to DOT11RADIO 0.

What could be the problem or what do I need to do.

7 Replies 7

mhellman
Level 7
Level 7

I don't see anything attached. tftp doesn't use just port 69. If memory serves, the client sends a packet to the server on udp 69 to start the session, and then all the rest of the communication is on udp >1023 in both directions. It's a bit of an odd protocol. In any event, I don't recall if a regular Cisco router can deal with this intelligently. You'll have to create an ACL that allows the following:

client:any --> server:69

server:>1023 --> client:1023

client:>1023 --> server:1023

Ihave attached the running config of the device.

TFTP applications uses both TCP port 69 as well as UDP port 69 .

Add following statement to access list:

access-list 101 permit tcp 172.16.0.0 0.0.255.255 any eq tftp

check and post results.

HTH

Saju

Pls rate helpful posts

Based on what, grep'ing /etc/services? I've yet to come across a tftp implementation that uses TCP, although nything is possible I guess.

Here's the RFC:

http://www.networksorcery.com/enp/rfc/rfc1350.txt

Here's the relevant details:

"A requesting host chooses its source TID as described above, and sends its initial request to the known TID 69 decimal (105 octal) on the

serving host."

SO, client:>1023 --> server:69

"The response to the request, under normal operation, uses a TID chosen by the server as its source TID and the TID chosen for the previous message by the requestor as its destination TID. The two chosen TID's are then used for the remainder of the transfer."

SO, server:>1023 <--> client:>1023

Based on what, grep'ing /etc/services? I've yet to come across a tftp implementation that uses TCP, although nything is possible I guess.

Here's the RFC:

http://www.networksorcery.com/enp/rfc/rfc1350.txt

Here's the relevant details:

"A requesting host chooses its source TID as described above, and sends its initial request to the known TID 69 decimal (105 octal) on the

serving host."

SO, client:>1023 --> server:69

"The response to the request, under normal operation, uses a TID chosen by the server as its source TID and the TID chosen for the previous message by the requestor as its destination TID. The two chosen TID's are then used for the remainder of the transfer."

SO, server:>1023 <--> client:>1023

I have manage to solve this by doing the following:

access-list 101 permit ip 172.16.0.0 0.0.255.255 172.16.0.0 0.0.255.255

Ths is now working but I am confused how this would resolved the problem as source & destination are same address range.

that ACL allows full IP connectivity between hosts that fall into that huge range. If both IP address fall into that range, then it will work.

Getting Started

Find answers to your questions by entering keywords or phrases in the Search bar above. New here? Use these resources to familiarize yourself with the community: