I've got a Win2k8 FTP server behind a pfSense firewall running the August 25th build.  I can connect to the FTP server from the outside world using active mode, but passive mode fails.  Prior to having a pfSense firewall in place, we had a Linux-based solution through which active and passive FTP sessions worked.

I've been reluctant to upgrade to newer builds in the past few weeks due to all the problems that have cropped up.  Does anyone else have passive sessions working to a NAT'ed FTP server?

Of course...I never indicated that.

My point was that, since the type of attack that you're trying to protect against is not generally going to come at a firewall by name, then this check is probably pointless.  It only serves to keep the people who own/administer the device out of it in some situations.

I'm done trying to debate this...

Its purpose is almost entirely protecting from gross negligence - a system with default or easily guessed password. Or, if some vulnerability is found in our web interface in the future, it protects against that being exploited in such a manner.

Only if accessed via a hostname that isn't on the list.  If accessed by IP, which I have a tendency to think is more likely for a brute-force attack, this check does nothing.

Please don't turn into Microsoft in the security department...trying to protect from gross negligence by making everything harder to use.  Why not just force the user to change the admin password on first login?  Wouldn't that be 100% more effective than protecting from DNS rebinding "attacks"  You can't, and shouldn't, be trying to force best practice procedures on people assuming that your way is the best in every scenario.

I don't have any problem with this being an option, but enabling it by default only prompts more questions here and elsewhere.

I understand that, but how is that realistically an actual hole in security?  No one but an admin knows the login for the firewall, so redirecting random users to it shouldn't pose a problem.  If an admin gets redirected to it, then they can log in.

I'm still missing where the "hole" is.  Setting up wildcard records just to resolve to a firewall's IP has been a possibility since DNS was invented.  Is this only in the DoS category?

Sure, I've done that now, but my point is that I shouldn't have to.  I think all this "feature" is going to do is generate lots more questions from end-users.  I simply don't see how it increases security in the slightest.

I read that, but still don't see how it has any relevance to pfSense.  I mean, we're talking about guys who are operating their own firewalls and accessing them from their own workstations using DNS records on their own domains, which they control.  An external attacker doesn't have access to any of that, and if they do, security is already compromised.

No, it's a security feature that should be on by default for everyone, and easy to work around should you be in a scenario where it doesn't automatically work (which is the vast majority now that we've fixed the initial fallout), such as accessing it by IP instead of hostname if the hostname is something other than the configured hostname or any locally configured dyndns name. What were you trying to use to access it?

I have two DNS names resolving to the private and public IP's on this particular firewall.  There can be only one hostname, so that is based on the public name, not the private one.  It's really just a DNS shortcut for me to use internally.  I don't see why using a DNS name that doesn't match one of the listed hostnames would be a security vulnerability???

It was, thanks!  Must have been a new feature added in the past month or so.  That setting should probably remain disabled for upgrade installs.

When I try to log into the web gui after installing today's snapshot, I get this error message:

Potential DNS Rebind attack detected, see http://en.wikipedia.org/wiki/DNS_rebinding

I tried yesterday's snap as well, and got the same thing.  The firewall appears functional, I just can't connect to it.  Any idea how far back I should go to get this working again?

Subject line pretty much says it all.  I can't enable the penalized IP queue in the shaper wizard.  The error is that I have to enter something in the bandwidth field.  I've tried percentages and kbit/s values but get the same error.

Just choose a mask of none and it will apply that limit to all the traffic passing though it.

How, then, do I apply that queue to an interface...specifically the downstream channel?

Limiters appear, at least in the GUI, as applying dynamic queues to multiple source or destination IP's.  They don't appear to be able to define a limit on an interface as a whole, unless I'm missing something?

It kind of surprises me that this hasn't been brought up before, but isn't downstream traffic shaping (in it's current implementation) basically useless in multi-wan scenarios?  The downstream shaper is created as an upstream queue on your LAN interface, but you'll very rarely hit that shaping limit.  You can saturate one or more downstream queues on your WAN interfaces, but unless *all* WAN interfaces are fully saturated in the downstream direction, the shaping on the LAN's upstream channel never has the opportunity to kick in.

Surely the mighty BSD has a work-around for this?

If your problem was like mine when I first tried multi-wan on 2.0, you'll need to disable sticky connections in the advanced settings.

I can confirm this upgrade does NOT work when going from 1.2.3 to 2.0 on the nanobsd architecture.  Importing the config worked reasonably well, though.