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

    Trying to create an inbound FTP rule

    Scheduled Pinned Locked Moved Firewalling
    6 Posts 4 Posters 1.6k 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.
    • M
      Mr.Si
      last edited by

      Hi All,

      So I come from a background in Sonicwall configuration so pfsense is possibly very different in ways of doing things…

      I'm trying to create an inbound firewall rule to allow FTP to my server but it doesn't seem to work when I test it.

      I have a public IP for the server and have a 1:1 NAT policy for any port to go to its private IP and intend to control what is allowed in by use of firewall rules.

      In the rule above the alias in destination is the Public IP of the server.

      But it's timing out when I'm trying to connect.

      I am on a site-site VPN at the same time, would that matter?

      1 Reply Last reply Reply Quote 0
      • N
        Nullity
        last edited by

        The destination would be your WAN IP, not the internal IP of AAServer, right?

        Please correct any obvious misinformation in my posts.
        -Not a professional; an arrogant ignoramous.

        1 Reply Last reply Reply Quote 0
        • M
          Mr.Si
          last edited by

          Sorry, I may have not explained it properly, but I've now got conenction as apparently in the Destination of the Firewall Rule, I needed to use the LAN IP of the server, not the assigned Public IP.

          So it's a different way of doing it than I'm used to.

          I just need to find out why the FTP isn't working properly over the wan now!

          1 Reply Last reply Reply Quote 0
          • DerelictD
            Derelict LAYER 8 Netgate
            last edited by

            Can you elaborate more as to what "isn't working properly" means?

            The fact that the destination host of the firewall rule has to be the "Real IP" address of the server is in every port forwarding document ever.

            https://doc.pfsense.org/index.php/How_can_I_forward_ports_with_pfSense

            https://doc.pfsense.org/index.php/Port_Forward_Troubleshooting

            Chattanooga, Tennessee, USA
            A comprehensive network diagram is worth 10,000 words and 15 conference calls.
            DO NOT set a source address/port in a port forward or firewall rule unless you KNOW you need it!
            Do Not Chat For Help! NO_WAN_EGRESS(TM)

            1 Reply Last reply Reply Quote 0
            • M
              Mr.Si
              last edited by

              @Derelict:

              Can you elaborate more as to what "isn't working properly" means?

              The fact that the destination host of the firewall rule has to be the "Real IP" address of the server is in every port forwarding document ever.

              https://doc.pfsense.org/index.php/How_can_I_forward_ports_with_pfSense

              https://doc.pfsense.org/index.php/Port_Forward_Troubleshooting

              I've always done port forwarding via nat ookicy not firewall ruling but as I said, sonicwalls are different.

              Anyway, the ftp is actually just a problem with my server vsftpd not set up for passive mode so that is just something I need to change, not anything wrong with pfsense. I used to use port 21 for connection and port 20 for data but that doesn't seem to work for me now.

              I do love this firewall though.

              1 Reply Last reply Reply Quote 0
              • johnpozJ
                johnpoz LAYER 8 Global Moderator
                last edited by

                "I used to use port 21 for connection and port 20 for data "

                There is NO scenario ever that port 20 would need to be forwarded for ftp.  Port 20 is only ever used as the source port in active ftp.  You would never need to forward to this port.

                If the clients are outside pfsense, and they are using active then 21 would need to be forwarded to your ftp server.  It would then make a connection to them from port 20.  So unless your blocking outbound traffic from your ftp server this would work with simple 21 forwarded/allowed.

                If your clients outside pfsense are going to use passive, then you need to forward the passive ports your ftp server is going to use.  And you need to make sure your ftp server gives the clients its public IP and not its rfc1918 address.

                There is no helper any more in pfsense that use to correct this sort of thing, open the passive ports for you when it saw the commands in the command channel to use passive.

                What I really suggest to anyone using ftp, be it your just a user or trying to run a server is fully understanding the difference between active and passive and what ports are used and what directions the data connection is made when using either active or passive.

                here is great write up on active vs passive in ftp http://slacksite.com/other/ftp.html

                The other thing I would suggest to anyone is to move away from the antiquated ftp protocol completely - just use sftp.  Which just uses 1 port, normally 22 and now all traffic is encrypted not like ftp.  And is much easier to use through firewalls unlike the 2 channel 2 method ftp with control and data which can be a pita for nat especially when done on both the client and server side which is the common configuration these days.

                An intelligent man is sometimes forced to be drunk to spend time with his fools
                If you get confused: Listen to the Music Play
                Please don't Chat/PM me for help, unless mod related
                SG-4860 24.11 | Lab VMs 2.8, 24.11

                1 Reply Last reply Reply Quote 0
                • First post
                  Last post
                Copyright 2025 Rubicon Communications LLC (Netgate). All rights reserved.