TFTP Works from LAN but not from WAN.

[silvereye]

Hey guys,

I've ran into some trouble while configuring TFTP on my home server (CentOS 6.10)

it works perfectly fine from LAN:

Code: Select all

-bash-4.1# tftp 192.168.0.21 -c get test.txt

But when i try the same thing from WAN it times-out.

Code: Select all

tftp **.***.***.*** -c get test.txt
Transfer timed out.

i've portforwarded every port both TCP/UDP to my home server. (for testing purposes)

both firewalls of my router and my server are off.

I also checked if the router was letting through the requests with tcpdump

Code: Select all

sudo tcpdump -i eth0 -n -v udp port 69
tcpdump: listening on eth0, link-type EN10MB (Ethernet), capture size 65535 bytes
08:11:44.849906 IP (tos 0x0, ttl 64, id 0, offset 0, flags [DF], proto UDP (17), length 52)
    192.168.0.21.49928 > **.***.***.***.tftp:  24 RRQ "axistftp1.sh" netascii
08:11:44.850799 IP (tos 0x0, ttl 64, id 0, offset 0, flags [DF], proto UDP (17), length 52)
    192.168.0.21.49928 > **.***.***.***.tftp:  24 RRQ "axistftp1.sh" netascii

If you know anything that might help, please reply.

Thanks

[jlehtone]

In other words, your network looks like:

Code: Select all

Server --LAN-- Router --WAN

Everyone in LAN can access Server, but nobody through the Router?

According to https://en.wikipedia.org/wiki/Trivial_F ... r_Protocol server responds from ephemeral port.
Lets have:

Code: Select all

Server -- Router -- Client

1. Client sends request to Router:69
2. Router forwards to Server:69
3. Server responds from Server:E
4. Router does SNAT Server:E to Router:N
5. Client may or may not see packet from Router:N as reply to initial request
6. If yes, then Client replies to Router:N
7. Will Router forward this reply to Server:E?

However, that is all academic. Why would you open TFTP to the world?
TFTP is extremely simple: no authentication, no encryption, no security.
There must be more appropriate file sharing protocols.


PS. CentOS 6.10 has only one month life left. Migrate.

[silvereye]

I tested if the router forwarded the request to the server using the tcpdump command.

Code: Select all

sudo tcpdump -i eth0 -n -v udp port 69
tcpdump: listening on eth0, link-type EN10MB (Ethernet), capture size 65535 bytes
08:11:44.849906 IP (tos 0x0, ttl 64, id 0, offset 0, flags [DF], proto UDP (17), length 52)
    192.168.0.21.49928 > **.***.***.***.tftp:  24 RRQ "axistftp1.sh" netascii
08:11:44.850799 IP (tos 0x0, ttl 64, id 0, offset 0, flags [DF], proto UDP (17), length 52)
    **.***.***.***.49928 > 192.168.0.21.tftp:  24 RRQ "axistftp1.sh" netascii
08:11:49.850046 IP (tos 0x0, ttl 64, id 0, offset 0, flags [DF], proto UDP (17), length 52)
    192.168.0.21.49928 > **.***.***.***.tftp:  24 RRQ "axistftp1.sh" netascii

and it looks like it received the request, yet it still timed-out.

and i want to use tftp because it's nice and simple.
I really want this to work with TFTP.

[aks]

Why do you thing UDP is reliable?

[silvereye]

Why do you thing UDP is reliable?

I want it to work, i don't need it to be reliable.

[jlehtone]

Contradictory. If it is not reliable, then it will not work reliably. In short: it will not "work".


vsftpd is simple too.

[TrevorH]

Both ftp and tftp use random ports that are extremely difficult to firewall. It's very likely that the firewall on CentOS has the correct nf_conntrack_[t]ftp kernel module loaded to keep track of which random ports require to be opened but your external firewall will not have a clue about that.