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

    Why does Packet Capture not see ftp data packets?

    Scheduled Pinned Locked Moved Firewalling
    3 Posts 2 Posters 2.4k 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.
    • K
      Korendyk
      last edited by

      Hi.

      I was looking for a more modern replacement for a (very old) lrp
      (Linux Router Project) server, and decided on pfSense since it
      seemed to offer the features (and then some) that would fit the
      network environment. In simple terms:

      LAN - public network(s) (housed within an organization)
        WAN - many other public networks (ie. The Internet)

      On a box with two NICs, pfSense is configured with one NIC at a
      static address in the LAN and the other with a static address in the
      WAN.  No NAT rules defined, no ftp-helpers, no virtual IPs, no
      multi-WAN, nothing at all fancy. Just routing between public
      networks with "firewall rules" on the WAN interface blocking access
      to the LAN except for the things that I want.  And everything works
      fine, except FTP.

      My apologies for rehashing the FTP issue, but I've gone through
      the forum messages and tried the suggestions, even when they don't
      really make sense for my configuration. All to no avail.

      The WAN firewall rules that I thought would allow ftp connections:

      Proto  Source  Port  Destination    Port      Gateway
          TCP    *      *    "ftp-server"    20          *
          TCP    *      *    "ftp-server"    21(FTP)    *

      Similar rules work for every other destination port I've tried.

      But FTP clients on the WAN have difficulty accessing the FTP servers
      on the LAN. They establish connections (ie. login), but data
      transfers time-out.  Seems that "passive" transfers sometimes work
      (perhaps depending on the firewalls at the client's end), but
      "active" transfers do not. So I tried the "Packet Capture" (under
      the Diagnostics option) to see what was happening.

      To make a long story short, without the firewall rules active (using
      the check box in "System->Advanced") everything works as expected
      with a non-filtering firewall: ftp control packets (ie.  to port 21)
      flow as do the ftp data packets (on port 20). But with the firewall
      rules active, the ftp data packets expected from the WAN do not even
      appear among the captured packets.

      So it seems "Packet Capture" on the WAN interface will capture the
      ftp data packets if firewall rules are disabled, but not when the
      firewall rules are enabled?  Unless I messed up, it is very
      confusing. Either the ftp-data packets are not being returned
      (doubtful), or the WAN interface doesn't see (or ignores) the
      ftp-data packets returned. Where do they go?

      Or am I missing something else.

      1 Reply Last reply Reply Quote 0
      • C
        cmb
        last edited by

        Packet capture will see all frames that are on the wire, if you aren't seeing it, it isn't there.

        Not sure what your specific issue might be, but maybe that'll help some at least.

        1 Reply Last reply Reply Quote 0
        • K
          Korendyk
          last edited by

          I had a chance to play with this some more over the weekend, which
          proved enlightening. So yes cmb, I suspect Packet Capture does see
          all frames, but I unfortuantely was only looking at ones (filtered) by
          specific IP addresses… otherwise there are just so many... :-)

          Silly me for thinking that if I do not define any NAT options or parameters
          that NAT would not be active and that all the addresses in my public (LAN)
          network would appear as public addresses on the WAN with access limited
          (filtered) by the firewall rules. Apparently not so.

          I discovered that many outgoing connections appear on the WAN as coming
          from the WAN interface address. I was seeing ftp packets going out from the
          public IP address from my LAN but not seeing anything coming back from the
          FTP server on the WAN because, I guess, it was coming back to the WAN
          interface address. At least that's what I think was happening.

          A similar thing may have been happening with HTTP as the web servers were
          being told the client was at the WAN interface address. But HTTP being the
          way it is, all the magic port assignments seemed to allow communications.
          Except for the (secured) web server that wouldn't let me talk to it because
          it did not recognise the request as coming from my proper public IP address.

          I wonder if any other similar failures have gone unnoticed... Oddly, as best
          I can tell without looking too deeply, not all protocols or ports are afflicted
          with NAT translations (eg. DNS, NTP). Or so it seems.

          Anyways, that is what I think was happening, so locating the solution became
          less difficult. The first was to force NAT into a full 1:1 for all addresses of the
          public LAN network. And suddenly everything behaved as expected. I also
          found I could configure NAT Outbound for "Advanced Outbound NAT (AON)",
          and once I removed the automatically generated mapping (which essentially
          turned NAT back on for the LAN network) my "firewall" now seems to behave
          like a simple router with access controlled by the firewall rules. Which is all I
          wanted in the first place ;-)

          Thankfully, with active mode FTP now working I can close up all those high
          ports needed for passive mode... I was astonished at how quickly and how
          often they were probed. And now sites expecting to "see" my public IP
          addresses are happy.

          All in all, I'm very pleased with pfSense. My praises to all involved in making it
          such a useful, flexible, and effective product!

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