• Categories
  • Recent
  • Tags
  • Popular
  • Users
  • Search
  • Register
  • Login
Netgate Discussion Forum
  • Categories
  • Recent
  • Tags
  • Popular
  • Users
  • Search
  • Register
  • Login

TFTP & pfsense

Scheduled Pinned Locked Moved General pfSense Questions
12 Posts 4 Posters 18.8k Views
Loading More Posts
  • Oldest to Newest
  • Newest to Oldest
  • Most Votes
Reply
  • Reply as topic
Log in to reply
This topic has been deleted. Only users with topic management privileges can see it.
  • C
    cjkeeme
    last edited by Feb 19, 2010, 4:00 AM

    I've searched the forums and on Google for a while.  Is it correct that my VoIP phones can't update through tftp when they are behind pfsense?  I can't get this working and it seems that it is a problem with no solution.  Anyone had luck with this?

    1 Reply Last reply Reply Quote 0
    • C
      cjkeeme
      last edited by Feb 19, 2010, 2:45 PM

      This is a little frustrating.  I have tried everything and searched everywhere with no solution.  One individual suggests the below:

      nano /etc/rc.d/rc.network
      
      add these two lines:
      modprobe ip_conntrack_tftp
      modprobe ip_nat_tftp
      
      Save and exit.
      

      I have no way to test this right now.  Does anyone have some reference to how to fix this problem?  Thanks.

      1 Reply Last reply Reply Quote 0
      • D
        danswartz
        last edited by Feb 19, 2010, 2:52 PM

        The suggestion they gave you seems to have been for a linux setup :(  Do your phones connect to a tftp server visible to anyone on the internet?  If so, that is not very secure.

        1 Reply Last reply Reply Quote 0
        • C
          cjkeeme
          last edited by Feb 19, 2010, 3:17 PM

          Do your phones connect to a tftp server visible to anyone on the internet?  If so, that is not very secure.

          We have taken proper measures to ensure security.  I do want to get TFTP working though.  Anyone with any thoughts?

          1 Reply Last reply Reply Quote 0
          • E
            Eugene
            last edited by Feb 21, 2010, 2:43 AM

            Technically to allow your IP phones to download from public TFTP server it is enough to open UDP port 69. So if your phone settings allow you specify TFTP server IP you should be fine.
            But typical scenario is IP phone gets TFTP server address from DHCP-server. As I know in 1.2.3 DHCP server does not allow you to distribute TFTP server IP address, so the solution would be to use separate DHCP server for your phones.

            http://ru.doc.pfsense.org

            1 Reply Last reply Reply Quote 0
            • D
              danswartz
              last edited by Feb 21, 2010, 5:10 AM

              true for 1.2.3 - however i found it a one-line patch to the services.inc file to allow me to set my tftp server address.  2.0 allows this the right way though.

              1 Reply Last reply Reply Quote 0
              • D
                danswartz
                last edited by Feb 21, 2010, 5:11 AM

                also, when you said it didn't work, that didn't really get too specific.  do you have any kind of packet trace showing what is going on (if anything?)

                1 Reply Last reply Reply Quote 0
                • W
                  wallabybob
                  last edited by Feb 21, 2010, 7:58 PM

                  @cjkeeme:

                  . . . Is it correct that my VoIP phones can't update through tftp when they are behind pfsense?  I can't get this working and it seems that it is a problem with no solution.  Anyone had luck with this?

                  The pfSense book says (p150) TFTP will not work through pfSense 1.2. pFsense 2.0 includes a TFTP proxy that eliminates this limitation.

                  @Eugene:

                  Technically to allow your IP phones to download from public TFTP server it is enough to open UDP port 69.

                  The pfSense book says the TFTP server is supposed to reply from a pseudo random source port rather than port 69. Consequently the firewall code thinks a TFTP response is unsolicited (the pseudo random source port doesn't match the destination port of previously seen traffic from the LAN) and blocks it.

                  1 Reply Last reply Reply Quote 0
                  • D
                    danswartz
                    last edited by Feb 22, 2010, 1:42 PM

                    good point, wallaby, i'd forgotten about that.  the protocol is that the first packet arrives on port 69, the first reply is sent from an ephemeral port, and the client's subsequent requests are sent to that port (i think it's done that way so it will work out of inetd.)

                    1 Reply Last reply Reply Quote 0
                    • E
                      Eugene
                      last edited by Feb 22, 2010, 3:26 PM

                      @wallabybob:

                      The pfSense book says (p150) TFTP will not work through pfSense 1.2. pFsense 2.0 includes a TFTP proxy that eliminates this limitation.

                      I am sorry I was wrong. Forgot this specifics.

                      http://ru.doc.pfsense.org

                      1 Reply Last reply Reply Quote 0
                      • E
                        Eugene
                        last edited by Feb 27, 2010, 3:06 PM

                        TFTP proxy is the only way.

                        http://ru.doc.pfsense.org

                        1 Reply Last reply Reply Quote 0
                        • W
                          wallabybob
                          last edited by Feb 28, 2010, 1:59 AM

                          Just to elaborate on the previous reply because the question didn't make the context plain. TFTP on "local" subnets (routing between source and destination but not NAT) shouldn't be any problem. TFTP through NAT (e.g. to Internet) requires a TFTP proxy as discussed earlier in this topic.

                          1 Reply Last reply Reply Quote 0
                          12 out of 12
                          • First post
                            12/12
                            Last post
                          Copyright 2025 Rubicon Communications LLC (Netgate). All rights reserved.
                            This community forum collects and processes your personal information.
                            consent.not_received