Skip to main content

autoprovisioning using tftp and sp100 (pfsense)

Posted by k3leland on Thu, 07/08/2010

eeman,

We are trying to set up autoprovisioning of linksys spa942's with tftp through your sp100 using dhcp option 66.
We are running into the problem with pfsense dropping the packets coming back from the tftp server because the source port is randomly chosen by the tftp server and is not recognized by pfsense.

We have tried:
atftp-server - the tftp server in the thirdlane repository
tftp-server - the tftp server in the centos repository

And we have tried running both of them with and without xinetd.
Neither tftp server seems to support sending data from source port 69.

We would use http for auto-provisioning however we cannot get that to work with the linksys spa942's using option 66 and would thus have to break this into two phases (as the linksys docs suggest):
phase 1 - pre-provisioning using dhcp and tftp (this can be done by some phone vendors so that the phone arrives with the profile rule set already)
phase 2 - provisioning proper using http

We were thinking of configuring tftp-proxy on the sp100 but the filesystem is read only and we don't hvae a compact flash card writer.

Do you have any suggestions for this scenario?


Submitted by eeman on Thu, 07/08/2010 Permalink

yes. I am aware of the issue with TFTP. I can send you a link but TFTP does not seem to work from behind nat on firewalls that are not Linux. The SP100 is based on a pfSense build which is BSD based. There is a TFTP proxy in the latest beta version we are testing. The new build also allows for installing more packages and upgrading as well.

Submitted by voipempire on Wed, 07/14/2010 Permalink

I am having a similar problem with provisioning.
I am using a WPU-7700 and tried TFTP and HTTP. THe files are there but it will not pull them down. I can see the HTTP files in a web browser.

I really want to use HTTP but for now will have to manually configure them.

Submitted by eeman on Wed, 07/14/2010 Permalink

i dont see how you have the same problem. I dont show you having purchased an SP100. and nothing restricts tcp based provisioning

Submitted by xxot on Sun, 01/23/2011 Permalink

Hi all. Is this issue with tftpd and nat not solved now? We are going to start with different customers in many locations and all they have different routers. Just some thoughts - is it so hard to implement tftp server for sending replays from 69 port, not from 4xxxx or 5xxxx? I'm not a programmer, but I suppose that it is possible, because of apache, for example, able to work only with port 80. And I believe, that many people use nat and use devices with tftp client and now not a 1997 year. Of course it is better to use good nat firewalls, but unfortunately not all have it. Is there now any solution, like tftp-proxy or alternative tftp server, which could overcome this issue?

Submitted by eeman on Mon, 01/24/2011 Permalink

the 2.0 version of pfsense does in fact have a TFTP invisible proxy to help with TFTP provisioning. This does not imply that any BSD based firewall will be immune to the problems with TFTP. Linux based firewalls do not experience this issue because they usually come with the full array of NetFilter modules which use connection tracking to assist in this manner. BSD really missed an opportunity to steal a really good idea with these netfilter modules IMHO.

FWIW now that ipv6 is really starting to roll out (we run out of numbers worldwide in a matter of a few weeks), this problem will be waning. There wont be any such thing as NAT in the ipv6 space. We are by no means anywhere near the size of verizon or comcast for userbase, yet our block of ipv6 numbers is a /32. This is more than the square of the entire internet currently. Yes we have been given a netblock that includes 18,446,744,073,709,552,000 possible numbers.

Submitted by xxot on Mon, 01/24/2011 Permalink

Erik, do you mean installation pfsense before Thirdlane solution and use it as tftp proxy or install it on the customer side?

Submitted by eeman on Mon, 01/24/2011 Permalink

customer side. There is no such thing as a public ip cure for a private ip problem. Thats a magic pill that really doesnt exist.

Submitted by xxot on Mon, 01/24/2011 Permalink

So, you suppose that it is impossible to use tftp proxy or alternative tftp for overcoming this issue with nat? I agree with you that cisco pix or linux to every house is a perfect idea, but we are living in severe reality sometimes with old incompatible equipment :(

Submitted by eeman on Mon, 01/24/2011 Permalink

most 'houses' use home grade wireless routers that are in fact linux not bsd therefore do not have this obstacle.