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