For the last week or so I have been playing with an installation of Freepbx 10.13.66 with Asterisk 13.
I have been trying to get the TFTP server working to provision some Cisco phones. The Freepbx firewall has TFTP set to “Internal” but seems to be blocking inbound connections. I can use tftp on the freepbx console to retrieve files from 127.0.0.1 but, for example, when trying to retrieve a file via TFTP from a Windows client on the LAN, it just times-out.
I have run various tests and can see that the TFTP UDP listener is open on the server (obviously I guess since the local tftp client works).
I am hesitant to modify iptables from any guides I have found on the internet since my understanding is the Freepbx firewall performs this configuration of iptables.
Am I alone - or can anyone suggest something I’ve missed?
I’ve been wrestling with the Firewall module a little bit over the past couple of months.
My first recommendation is to make sure that you have the local network in the Trusted zone. I’m not convinced that this feature is always working, but when it works, it does so well.
If the firewall is set up correctly, you also need to doublecheck the operation of the TFTP server files.
You should log in as root as “cd” to your /tftpboot directory and double-check that the files are all owned by Asterisk and that they are all chmodded to “666”. They don’t need to be executable (and should not be) to ‘666’ (universal read and write) should be enough.
There’s a setting on the tftpd file in the /etc/inetd.d (???) file/directory that turns on verbosity. Set that on (man tftpd should help) and look in your /var/log/messages file. This may give you additional hints on what is failing.
I’m having the same problem. I have verified that it works locally (tftp client on the pbx from the IP address of the pbx) and have also gotten tftp to work from a remote client for a brief period after a reboot or applying changes after a module update or something like that. When it is not working I don’t see anything in the /var/log/messages. I have also attempted turning off the firewall and fail2ban.
Yesterday I updated the System Firewall module from 13.0.18.1 to 13.0.19 and after applying changes the tftp worked for about 10 minutes then quit.
In the third tab under the “Services” (I’m not a PBX right now) you can add all of the “other” ports. Add the TFTP UDP port in there as well as making sure that you’ve allowed the local network to access the system. Setting all of these pieces correct should get you back on line.
A few people are having problems with the integrated firewall and Fail2Ban - it sounds exactly like what’s happening to you.
If you have the “System Administration” module installed, check the settings in there to make sure the local network is white-listed. I’m almost certain that it “shouldn’t” matter, but adding the local network to the whitelist in there AND in the integrated firewall (which should be accessing the same config files) might be enough to get the whole thing working.
As pointed out - the integrated firewall is still in Beta, so expecting to be perfect out of the box might be asking a lot. There are a lot of moving parts here, and getting the exact order ot allows and denies right could take some tweaking. If you get it working, be sure to let everyone know what you did (or think you did) so that the developers can catch the problems out strange (non-standard) systems are having.
It’s also possible that you are causing fail2ban to hit on your pulls too - make sure (look in /var/log/messages) to make sure you aren’t trying to download non-existent files.
Keep at it - stay positive - remember that this is all built by a lot of talented amateurs and a handful of dedicated professionals like @tm1000. The system, even when it has warts, is worth way more than you paid for it…
That means that only hosts from internal networks (defined in zones) have access to TFTP. Are you sure you’ve added your internal networks to internal, or trusted?
I have added my internal network to the trusted zone in the firewall zones. BTW all of the clients attempting to connect are on the same subnet as this pbx. I also explicitly added the IP addresses of those phones and my test laptop to the whitelist of the intrusion detection.
Finally I turned them both off and it still doesn’t work. I’m going to investigate this as a possible network issue.
It was a network issue! I did have to tweak the firewall and sip configuration a little but the provisioning via tftp is working now. We had too many hops on the VLAN trunks. That is to say we had too many Cisco switches between the phones and the pbx.
Just to update this, what we discovered was there was a configuration issue on the server hardware (Cisco UCS running VMWare) in the networking fabric. We discovered this by moving the VM to another cluster on completely different hardware and it worked fine.
It looks like the issue has to do with the UCS fabric being in End Host Mode rather than Switch Mode but we have not completed our diagnosis of it to say for certain. What is certain is that the FreePBX VM works fine as does the firewall.
