Jure Pečar wrote:
Since everyone is just singing praises, I'll add some things to look for
;)
Besides running it at home we run it on three production locations, which
are two server rooms and one fast growing wireless lan.
First bad expirience: it is really touchy about the quality of your cd
burner and blank CDs. This mostly shows as misterious crashes and kernel
panics during boot or later during install. It took us some time to
figure that out.
I know a very small percentage of people have issues of this nature. On
dozens of different systems I have used, I've never personally seen it,
and the vast majority of users have never seen it.
Second bad expirience: 1.0.1 leaves hw.ata.wc enabled by default (didn't
check 1.2), which ended up with one toasted fs after a power failure.
Fortunately config.xml was backed up :)
1.2 has that disabled, and also fixed some other issues that caused file
system and/or configuration corruption. 1.2 beta/RC has been the
recommended version for months now for this reason and others.
Unfortunately we can't release 1.0 bug fix updates because we didn't tag
that release in CVS, 1.2 will receive interim bug fix updates as
necessary to address issues of this nature.
Third bad expirience: once it's up it works rock solid, but there is a
kernel panic every now and then during boot or during shutdown. Again,
this is 1.0.1, haven't looked at 1.2.
1.2 should be better in that area, but those are likely FreeBSD issues
specific to your hardware. If it's something you can replicate with 1.2,
it might be worthwhile to install the developer kernel with debugging
tools (an option during the install now), and get a back trace. Start a
new thread if you want to investigate in the future.
For the original poster: The only really common issue going from a test
environment into production, when replacing an existing firewall (which
is common to any network device, not pfsense-specific) is ARP caches -
your perimeter router, or your ISP's router (depending on the type of
connection you have) has an ARP cache with your existing firewall's MAC
address. When you change the firewall, it can take several hours for
that cache to timeout and recognize the new system. On Cisco routers,
the ARP cache is 4 hours by default. You may need cooperation from your
ISP if you don't have access to that router. If you do have access to
the router, you can just power cycle it. Cable and DSL modems commonly
require a power cycle to pick up a replaced system.
Aside from that, which is common to any firewall migration regardless of
software, we haven't seen any widespread issues with going from testing
to production.
