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

Issue with TFTP upgrade

bender.mike
Level 1
Level 1

I'm experiencing a problem with performing TFTP upgrades through a site-to-site tunnel between a CVPN3015 and a 831 router.

I suspect that it's an issue with an ACL. Can anyone see anything that I'm missing?

TFTP server has IP 10.64.0.x. I can perform extended ping from inside interface, but standard ping times out.

Sample config:

interface Ethernet0

description $FW_INSIDE$$ETH-LAN$$INTF-INFO-Ethernet 10/100$

ip address 10.0.0.129 255.255.255.128

ip access-group 101 in

no ip redirects

no ip unreachables

no ip proxy-arp

ip route-cache flow

ip tcp adjust-mss 1300

ip policy route-map clear-df

no cdp enable

!

interface Ethernet1

description $FW_OUTSIDE$$ETH-WAN$

ip address 65.65.65.65 255.255.255.248

ip access-group 102 in

no ip redirects

no ip unreachables

no ip proxy-arp

ip inspect DEFAULT100 out

ip route-cache flow

duplex auto

no cdp enable

crypto map USKK2K

!

ip classless

ip route 0.0.0.0 0.0.0.0 65.65.65.66

ip http server

ip http access-class 1

ip http authentication local

ip http secure-server

!

!

logging trap debugging

access-list 1 remark HTTP Access-class list

access-list 1 remark SDM_ACL Category=1

access-list 1 permit 10.0.0.0 0.255.255.255

access-list 1 deny any

access-list 101 remark auto generated by SDM firewall configuration

access-list 101 remark SDM_ACL Category=1

access-list 101 deny ip 192.168.0.1 0.0.0.7 any

access-list 101 deny ip host 255.255.255.255 any

access-list 101 deny ip 127.0.0.0 0.255.255.255 any

access-list 101 permit ip any any

access-list 102 remark auto generated by SDM firewall configuration

access-list 102 remark SDM_ACL Category=1

access-list 102 remark Auto generated by SDM for NTP (123) 10.1.0.1

access-list 102 permit udp host 10.1.0.1 eq ntp host 65.65.65.65 eq ntp

access-list 102 permit udp host 10.1.0.2 eq domain any

access-list 102 permit udp host 10.1.0.3 eq domain any

access-list 102 permit ahp host 64.64.64.65 host 65.65.65.65

access-list 102 permit esp host 64.64.64.65 host 65.65.65.65

access-list 102 permit udp host 64.64.64.65 host 65.65.65.65 eq isakmp

access-list 102 permit udp host 64.64.64.65 host 65.65.65.65 eq non500-isakmp

access-list 102 permit icmp any host 65.65.65.65 echo-reply

access-list 102 permit icmp any host 65.65.65.65 time-exceeded

access-list 102 permit icmp any host 65.65.65.65 unreachable

access-list 102 remark IPSec Rule

access-list 102 permit ip 10.0.0.0 0.255.255.255 10.0.0.128 0.0.0.127

access-list 102 deny ip 10.0.0.128 0.0.0.127 any

access-list 102 deny ip 172.16.0.0 0.15.255.255 any

access-list 102 deny ip 192.168.0.0 0.0.255.255 any

access-list 102 deny ip 127.0.0.0 0.255.255.255 any

access-list 102 deny ip host 255.255.255.255 any

access-list 102 deny ip host 0.0.0.0 any

access-list 102 deny ip any any log

access-list 103 permit ip 10.0.0.0 0.255.255.255 any

access-list 103 deny ip any any

access-list 104 remark DF-bit Clear list

access-list 104 permit ip 10.0.0.0 0.255.255.255 any

access-list 150 remark SDM_ACL Category=4

access-list 150 permit ip 10.0.0.128 0.0.0.127 10.0.0.0 0.255.255.255

access-list 150 permit icmp 10.0.0.128 0.0.0.127 10.0.0.0 0.255.255.255

access-list 150 deny ip any any

no cdp run

route-map clear-df permit 10

match ip address 104

set ip df 0

---------end config

Thanks for any help!

Mike

3 Replies 3

Richard Burts
Hall of Fame
Hall of Fame

Mike

I believe the basic issue is that by default the TFTP packets are sent using the source address of the outbound interface (in this case Ethernet 1). Since you did not include the crypto map in the posting we can not tell whether that traffic is included in the IPSec tunnel but I am guessing that it is not. The other part of the issue is that inteface Ethernet 1 has inbound access list 102. This access list permits some NTP, some DNS, IPSec and traffic from 10.0.0.0 to 10.0.0.128. But it has no permit for non-IPSec with destination address of 65.65.65.65 and I believe this includes tftp.

I believe there is an easy solution. If you include this in the config:

ip tftp source-interface ethernet 0

this will source the tftp from the ethernet 0 interface. I believe the return traffic will be permitted if it is sourced from ethernet 0.

HTH

Rick

HTH

Rick

Rick,

Thanks for the reply. That indeed resolved the problem. I figured the problem was that tftp was using Eth1 for the source address, which was why I suspected my ACLs. I also figured there had to be a way to specify TFTP to use a different source address.

Thanks,

Mike

Mike

Thanks for the update indicating that the problem is resolved. It helps make the forum more valuable when people read discussion of a problem and can see what the solution turned out to be.

I am glad that we were able to help solve your problem.

HTH

Rick

HTH

Rick
Review Cisco Networking for a $25 gift card