Why does Packet Capture not see ftp data packets?

[Korendyk]

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.

[cmb]

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.

[Korendyk]

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!