Make sure that the firewall is enabled, and click on “Allow an app or feature through Windows Defender Firewall”. Click on “Change Settings,” then “Allow another app”. Click on “Browse” and find the TFTP.exe from the System32 folder and click on Open. Then click on “Add”. I've been using Core FTP mini server to provide one SFTP connection for many years. I'm having trouble figuring how to set the Windows firewall in Windows 10 Pro. In the inbound rules there are two rules permitting TCP and UDP. In the outbound rules I created a rule permitting TCP on any local port and remote port 22.
- Part 2 – the tftp client requires firewalld changes as well (this blog post)
The rest of this blog post will elaborate on what happens if you don’t do this.
The quick bit is: if you want to run the TFTP client on, say, RHEL7, you need to enable a service in firewalld on the client.
Obviously, I’m assuming you’ve got firewalld turned on, otherwise you wouldn’t be here.
Puppet code, using crayfishx/firewalld, and the firewalld-cmd fix for this follows.
Quick test:
24 hours earlier.
Once I’d got the TFTP server running cleanly, unhelpful stuff was happening. I tried various things, in summary:
client:
server:
Yeah, complete with random noise from the client. Nice.
The file’s empty. There’s no error anywhere, and there’s nothing else logged. (Spoiler: if it was all working correctly, more would be logged on the server.)
- I turned off the server’s firewalld.
- I set selinux permissive on the server, and the following is clean.
From Part 1: the tftp daemon stays running.
That makes it much easier to trace, which at this point became necessary. Ran out of ideas. I’m not a syscall guru by any means, but it all started with truss on Solaris, and I still fall back to it sometimes.
I was expecting a problem reading the file, in which case the syscalls will show this.
I’ve annotated the end of it here; the PID is that root owned TFTP process. (see Part 1.)
Not a problem reading the file.
It reads the file, tries to pass the data to the client, loses the client.
A network issue.
Process of elimination.
I don’t know tftp that well, but I do know that FTP traffic is a bit odd and involves two sessions, and firewalls have to cope with that.
Allow Programs Firewall Windows 10
Here we have a hand off between daemons on the server side, perhaps there’s some oddness with ports, and the *client* firewall has to keep track of it. Otherwise, you’ve got incoming data from an unexpected source.
Of course, you don’t usually run the TFTP client – that’s a Cisco device or appliance doing a backup, or it’s your PXE client. It just works, right?
Windows 10 Ftp Firewall Rule
So client side:
Insert scratchy screetching noise here.
Just ignore that last bit. Firewalld on the client I was testing with got screwed up. That shouldn’t have worked.
Tftp Windows 10 Server
- I rebooted and the problem came back.
- Post reboot, stopping firewalld fixed it again, starting it broke it again.