Unable to connect using tftp other than over openvpn

John Summerfield debian at herakles.homelinux.org
Wed Mar 5 22:00:45 UTC 2008


CSB wrote:
> I am trying to configure a tftp server and am having difficulty connecting
> to it from a tftp client
>
> vi /etc/xinetd.d/tftp
> service tftp
> {
>         socket_type             = dgram
>         protocol                = udp
>         wait                    = yes
>         user                    = root
>         server                  = /usr/sbin/in.tftpd
>         server_args             = -s /tftpboot
>         disable                 = no
>         per_source              = 11
>         cps                     = 100 2
>         flags                   = IPv4
>         log_type                = FILE /var/log/tftp.log
> }
>
> >From client
> tftp -v 203.89.001.001 -c get cfg000b82024216 Connected to 203.89.001.001
> (203.89.001.001), port 69 getting from 203.89.001.001:cfg000b82024216 to
> cfg000b82024216 [netascii] Transfer timed out.
>
> The server is running open vpn and the client is connected to it. I can
> successfully connect using tftp over openvpn so it's not a permissions
> issue.
> tftp -v 10.8.0.1 -c get cfg000b82024216
> Connected to 10.8.0.1 (10.8.0.1), port 69 getting from
> 10.8.0.1:cfg000b82024216 to cfg000b82024216 [netascii] Received 890 bytes in
> 4.4 seconds [1611 bit/s]
>
> If I add the bind directive then I still can't connect over the public ip
> (and I can no longer connect over the vpn either):
>         bind                    = 203.89.001.001
>
> If I stop the openvpn service I still cannot connect over the public ip
> address.
>
> If I flush the firewall rules I still cannot connect over the public ip
> address.
>
> Any help appreciated
>
> Cameron
>
> ifconfig
> eth1      Link encap:Ethernet  HWaddr 00:18:71:8C:32:FF
>           inet addr:203.89.001.001  Bcast:203.89.001.255  Mask:255.255.255.0
>           inet6 addr: fe88::208:88ff:fe8c:32ff/64 Scope:Link
>           UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
>           RX packets:34918988 errors:0 dropped:0 overruns:0 frame:0
>           TX packets:34021478 errors:0 dropped:0 overruns:0 carrier:0
>           collisions:0 txqueuelen:1000
>           RX bytes:1462983820 (1.3 GiB)  TX bytes:1275513509 (1.1 GiB)
>           Interrupt:193
>
> eth1:1    Link encap:Ethernet  HWaddr 00:18:71:8C:32:FF
>           inet addr:203.89.001.007  Bcast:203.89.001.255  Mask:255.255.255.0
>           UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
>           Interrupt:193
>
> eth1:2    Link encap:Ethernet  HWaddr 00:18:71:8C:32:FF
>           inet addr:203.89.001.008  Bcast:203.89.001.255  Mask:255.255.255.0
>           UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
>           Interrupt:193
>
> eth1:3    Link encap:Ethernet  HWaddr 00:18:71:8C:32:FF
>           inet addr:203.89.001.009  Bcast:203.89.001.255  Mask:255.255.255.0
>           UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
>           Interrupt:193
>
> lo        Link encap:Local Loopback
>           inet addr:127.0.0.1  Mask:255.0.0.0
>           inet6 addr: ::1/128 Scope:Host
>           UP LOOPBACK RUNNING  MTU:16436  Metric:1
>           RX packets:7470203 errors:0 dropped:0 overruns:0 frame:0
>           TX packets:7470203 errors:0 dropped:0 overruns:0 carrier:0
>           collisions:0 txqueuelen:0
>           RX bytes:1010165066 (963.3 MiB)  TX bytes:1010165066 (963.3 MiB)
>
> tun0      Link encap:UNSPEC  HWaddr
> 00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00
>           inet addr:10.8.0.1  P-t-P:10.8.0.2  Mask:255.255.255.255
>           UP POINTOPOINT RUNNING NOARP MULTICAST  MTU:1500  Metric:1
>           RX packets:0 errors:0 dropped:0 overruns:0 frame:0
>           TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
>           collisions:0 txqueuelen:100
>           RX bytes:0 (0.0 b)  TX bytes:0 (0.0 b)
>
>
>
>   
All the documentation I read when learning to set up tftp stated that 
it's an insecure protocol ill-suited to sharing stuff over public 
networks. It's best left for its intended purpose, sharing firmware, 
boot code and such over networks under one's own control.

One of the risks is that, with a default installation[1], anyone who can 
read your data can change your data.

If you control both ends of the VPN then that would seem to meet that 
guideline.

If you want to persist with sharing over the public internet, then look 
at your firewall rules to see whether
1, There's a problem restricting your transfer
2. You have adequate controls over who can share your data.


For more general data sharing I recommend and use http.

[1] The Fedora/Red Hat installations are not default, they're secured 
and configured to a special purpose, sharing boot code. Changing that 
setup isn't hard, but one needs to understand the possible consequences.

-- 




More information about the fedora-list mailing list