by ganeshh_iyer on Thu Jun 24, 2010 10:32 am
Rouven,
TFTP typically uses UDP as its transport protocol, but it is not a requirement. Data transfer is initiated on port 69, but the data transfer ports are chosen independently by the send and receiver during initialization of the connection. The ports are chosen at random and must be in the range 0–65535.
Genrally what happens when you apply acl for only tftp on protocol udp
* From the original case, PC initiates a TFTP session from an arbitrary port at its side to server port 69 (conventional TFTP port for initiating TFTP session). Server then acknowledges from an arbitrary port PC at its side. The following exchanges occur between PC and Server. (Ports PC and Server are commonly named transfer identifiers as referred into RFC 1350 relative to TFTP specification.
* Thence the ACL entry defined as "permit udp 192.168.30.0 0.0.0.255 host 192.168.40.10 eq tftp" only allows the first exchange from PC to Server and back. Because of the varying values of PC and Server -- distinct from 69 (TFTP initial port) -- and of no matching criteria in the ACL, the TFTP data transfer is not permitted.
As part of solutions, I would think about providing one of the following implementations of ACL.
* Adding the ACL entry "permit udp host 192.168.30.0 0.0.0.255 host 192.168.40.10 gt 1024" (in addition with ACL "permit udp 192.168.30.0 0.0.0.255 host 192.168.40.10 eq tftp"): with the assumption that PC and Server are chosen greater than 1024, otherwise this value could be adapted. The main drawback of this solution is to allow whatever UDP datagram on port over 1024 which may be over what one wishes to permit.
* Adding the ACL entry "permit udp host 192.168.30.0 0.0.0.255 eq X host 192.168.40.10" (in addition with ACL "permit udp 192.168.30.0 0.0.0.255 host 192.168.40.10 eq tftp"): where X is a pre-defined integer (greater than 1024).
Hope to Help !!
Ganesh.H