simplydrew
Member
- Joined
- Feb 19, 2012
- Messages
- 92
- Reaction score
- 4
I'm in the process of setting up a Linode instance of PIAF Green as a hosted solution for around 10 phones at the moment. Spec'd out some Cisco 7975 phones for this particular site, using chan-sccp-b (which works beautifully - great project), but am running into issues with having t*f*t*p send configuration files from the Linode instance through the WAN to the phone remotely.
As a test, I grabbed one of my spare 7965s sitting here in in my home office, threw the firmware and configuration file needed on the Linode instance, manually pointed the phone to the Linode IP, and let it rip. When checking /var/log/messages, I could see that xinetd's t*f*t*p process was verbosely outputting that it was trying to respond to the phone's t*f*t*p request, but the transmission wasn't making it through:
Stumped, I tcpdump'd my pfSense router's WAN interface and noticed that I was getting a response ingested back to the phone end, but pfSense was blocking the t*f*t*p return - as every t*f*t*p reply would be a randomized port number. Reading through RFC 1350, this seems to be business as usual.
However, this obviously introduces a problem for me. I could build an OpenVPN tunnel or otherwise from the customer's side when the phones are deployed to them back to my Linode PIAF instance, but that would require a box of some sort on site to introduce that routing - which I'm trying to avoid (thus the hosted PBX, no hardware to fail onsite beside the phones). I could also put a box on site to serve as a local t*f*t*p point, but that would still introduce having to put another piece of equipment on site.
I've searched the forums and read through a few different trials and tribulations with hosted solutions, but didn't come up with anything that addresses the t*f*t*p point. Any thoughts?
As a test, I grabbed one of my spare 7965s sitting here in in my home office, threw the firmware and configuration file needed on the Linode instance, manually pointed the phone to the Linode IP, and let it rip. When checking /var/log/messages, I could see that xinetd's t*f*t*p process was verbosely outputting that it was trying to respond to the phone's t*f*t*p request, but the transmission wasn't making it through:
Code:
Jun 25 18:48:03 li922-231 in.tftpd[31397]: RRQ from [insert home wan IP here] filename term65.default.loads
Jun 25 18:48:07 li922-231 in.tftpd[31398]: RRQ from [insert home wan IP here] filename term65.default.loads
Jun 25 18:48:11 li922-231 in.tftpd[31399]: RRQ from [insert home wan IP here] filename term65.default.loads
Jun 25 18:48:18 li922-231in.tftpd[31400]: RRQ from [insert home wan IP here] filename term65.default.loads
Jun 25 18:48:22 li922-231 in.tftpd[31402]: RRQ from [insert home wan IP here] filename term65.default.loads
Jun 25 18:48:26 li922-231 in.tftpd[31420]: RRQ from [insert home wan IP here] filename term65.default.loads
Jun 25 18:48:30 li922-231.tftpd[31448]: RRQ from [insert home wan IP here] filename term65.default.loads
Stumped, I tcpdump'd my pfSense router's WAN interface and noticed that I was getting a response ingested back to the phone end, but pfSense was blocking the t*f*t*p return - as every t*f*t*p reply would be a randomized port number. Reading through RFC 1350, this seems to be business as usual.
However, this obviously introduces a problem for me. I could build an OpenVPN tunnel or otherwise from the customer's side when the phones are deployed to them back to my Linode PIAF instance, but that would require a box of some sort on site to introduce that routing - which I'm trying to avoid (thus the hosted PBX, no hardware to fail onsite beside the phones). I could also put a box on site to serve as a local t*f*t*p point, but that would still introduce having to put another piece of equipment on site.
I've searched the forums and read through a few different trials and tribulations with hosted solutions, but didn't come up with anything that addresses the t*f*t*p point. Any thoughts?