Why does Packet Capture not see ftp data packets?



  • 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.



  • 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.



  • 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!


Log in to reply