Hello all.
I am potentially looking at firewall products and wanted suggestions as to the easiest firewalls to install, configure and maintain? I have a few small networks ( 50 nodes at one site, 50 odd at another, and maybe 20 at another. I have worked with Cisco Pix, ASA, Netscreen, and Checkpoint (Nokia), and each have strong and not as strong features for ease of use. Like everyone, I'm resource challenged and need an easy solution to stand up and operate.
Feel free to ping me offline - and thank you for the assistance.
ASA's are a classic fallback because of the stability implied by the cisco name. Complaints about them tend to be cost on getting all the shiny bits attached to them (IDS, IPS, Content filtering). This coming from a Cisco partner. I am not a Netscreen fan myself due to past experiences and sour tastes. Checkpoint's are OK, but I don't like the application need for configuring on SMB appliances.
Add to the list Sonicwall. We use them primarily for our customers at work and are partners with them as well. They have appliances that go from 10 office size to Active/Active HA pairing that can do multi gbit of throughput. They support all the standard features you look for IPSEC VPN, SSLVPN, L2TP, VLAN Interfaces, Dynamic routing support (OSPF and RIP in small models, BGP in the larger) LDAP auth for all of the above, content filtering, IPS, IDS, Anti Spyware stateful blah blah and centralized management. Some of the newer things that are gaining popularity that you can license is the App Visualization (think netflow in a web UI with good filters), WAN Acceleration modules via a VMware Appliance, RBL Filtering (which can be applied to just about anything), DPI-SSL inspection for https traffic, Active/Active HA, Physical port redundancy per appliance, list goes on. Configuration logic is similar to a ASA, however takes a little to get used to. The nice thing is everything in the config is name based and searchable within the WebUI and you can talk non technical people through making changes in the config if you have to.
The feature list is growing every day, and I almost prefer them anymore just because of the simplicity as well as the scalability.
Ping me if you have more questions or want a few example setups.
It really depends on what constraints you have. Do you care about:
cost? performance? support?
Personally, for cost-constrained applications of 1 Gbit/s or less
(assuming modestly-sized packets, not all-DNS for example), I like
OpenBSD/pf or Linux/netfilter and generic x86 64-bit servers.
It's cheap, deeply customizable and since everything touches a CPU, it
allows for deep traffic inspection.
The tradeoff is that there's no support from major vendors, but there
are many smaller but very experienced consulting shops that can
integrate any patches and fix and issues that may arise.
pfSense is a free open source FreeBSD based firewall with the pf packet
filter. http://www.pfsense.org
It supports various features and installable packages that might fill
your needs. Commercial support is also available.
One of the reasons I use it at work is because it is by far the cheapest
solution to gigabit redundant (Active/Passive) firewalls. It runs on x86
machines from the low end PCengines.ch Alix 2D3 to something like a dual
core Intel Atom for or the higher end on a "normal" server.
It is administered entirely via the webUI, saves the config in a XML
file you can backup and then restore on pretty much any other hardware
you have around should it need to be replaced.
The (readable) XML file was also really easy to provision things like
hundreds of VPN tunnels instead of clicking through the UI.
The PHP command interface allows you to perform scripting operations on
the XML as well which comes in handy on mass mutations.
pfSense is a free open source FreeBSD based firewall with the pf
packet filter. http://www.pfsense.org
I'm a very happy user of m0n0wall and I know pfSense is often seen as
the more 'grown up' variant.
Still though, I hear bad things of the IPv6 support in pfSense. It's
"available" but not stock-standard & supported.
That is correct, it is in the 2.1 branch. Our code has diverged a lot
from m0n0wall where it came from so porting it was not easy. Instead I
wrote the code from scratch.
I wrote the IPv6 code in pfSense 2.1 for the last year and I've been
using it in production for quite a while now. Since February this year
to be precise.
It is true that until 2.1 is released somewhere next year the latest
official release is pfSense 2.0.
The people running Commercial support do support 2.1 with IPv6 if you
need it though. There are already a number of customers running it in
production because they needed IPv6 support.
The biggest holdup is lack of commercial VPN client support for
dual-stack. Viscosity, TunnelBlick I am looking at you. We do ship a
working Windows OpenVPN dual stack client solution in the Client
exporter on 2.1.
Working dual stack for your VPN solution is kind of important if you
expect to be able to reach your corporate servers. Much grief/fun to be
had here. If the corporate LAN advertises quad A records then it will
confuse your VPN clients if they have a v4 VPN address but only a v6
internet address.
How does the pfSense developer attitude towards filtering the entire
Internet, IPv6 included, currently stand?
I do not quite understand your question. If you are referring to a
default deny policy on incoming traffic, then yes.
The default rule is to deny incoming traffic over IPv6 as it did over
IPv4. You will need to create rules to allow it through. Default LAN
rule is allow both IPv4 and IPv6 out. Ofcourse you can alter the
firewall rules as you see fit.
If I misunderstood your question then please verify.
That is correct, it is in the 2.1 branch. Our code has diverged a lot
from m0n0wall where it came from so porting it was not easy. Instead I
wrote the code from scratch.
I wrote the IPv6 code in pfSense 2.1 for the last year and I've been
using it in production for quite a while now. Since February this year
to be precise.
It is true that until 2.1 is released somewhere next year the latest
official release is pfSense 2.0.
The people running Commercial support do support 2.1 with IPv6 if you
need it though. There are already a number of customers running it in
production because they needed IPv6 support.
TH: This is good news. I look forward to the general availability of 2.1
in this case. An "official" release supporting v6 properly is long
over-due for pfSense; users have been complaining about the lack of
support for *years*.
The biggest holdup is lack of commercial VPN client support for
dual-stack. Viscosity, TunnelBlick I am looking at you. We do ship a
working Windows OpenVPN dual stack client solution in the Client
exporter on 2.1.
Working dual stack for your VPN solution is kind of important if you
expect to be able to reach your corporate servers. Much grief/fun to be
had here. If the corporate LAN advertises quad A records then it will
confuse your VPN clients if they have a v4 VPN address but only a v6
internet address.
TH: Indeed, but the more you push on it the better it will become
(hopefully). VPN clients/concentrators in the FOSS world is already a
minefield of incompatibilities and other such problems.
> How does the pfSense developer attitude towards filtering the entire
> Internet, IPv6 included, currently stand?
I do not quite understand your question. If you are referring to a
default deny policy on incoming traffic, then yes.
The default rule is to deny incoming traffic over IPv6 as it did over
IPv4. You will need to create rules to allow it through. Default LAN
rule is allow both IPv4 and IPv6 out. Ofcourse you can alter the
firewall rules as you see fit.
If I misunderstood your question then please verify.
TH: In the past, the pfSense developer's attitude to IPv6 support has
been pretty poor. I have mentioned above that customers have been asking
for such support for years (i.e. since m0n0wall had it) and the response
has been 'it's not important yet', which really wasn't true.
But, despite that, it sounds like it's finally getting better. And that
can only be good news.
You will find it very difficult to beat pf on OpenBSD for efficiency,
features, flexibility, robustness, and security. Maintenance is very
easy: edit a configuration file, reload, done.
An important feature lacking for now as far as I know is content/web filtering especially for corporates wishing to block inappropriate/time wasting content like facebook. Addition of this would place it a par with the best like Sonicwall and Fortinet.
I would probably disagree with Richard's statement; most organizations
are looking for something that's a little more of a product/appliance
and a little less of a one-off solution/generic UNIX box.
That having been said, if you AREN'T put off by "edit a configuration
file", then maybe you won't be put off by "install Squid, add squidGuard
(IIRC), and configure transparent proxying" and you're pretty much all
the way there. Oh, and you get caching acceleration for free.
1. That's not a firewall function. That's a censorship function.
2. You can of course easily do that via a variety of means, including
BOGUS'ing the domains in DNS, blocking port 80 traffic to their network
allocations, running an HTTP proxy that blocks them, etc. I presume
that any minimally-competent censor could easily devise a first-order
solution (using the software packages supplied with OpenBSD) in an afternoon.
There are several areas where pf falls down. One is auto-synchronisation
from primary to backup firewall (not really a pf problem, but it's
important for production firewall systems). Another is ipv6 fragments,
although this was mostly fixed in a commit on 20110329 (released in 5.0),
which unfortunately has not yet made its way to freebsd yet. A third is
openbsd's poor ethernet hardware interrupt handling. Again, this has
improved recently, but it's still lags seriously behind linux / freebsd.
Having said that, it's still my least disfavoured stateful packet filtering
system.
> An important feature lacking for now as far as I know is content/web
> filtering especially for corporates wishing to block
> inappropriate/time wasting content like facebook.
1. That's not a firewall function. That's a censorship function.
A "firewall" is pretty much a censorship function, you're using it to
disallow certain types of traffic on your network. It's simply a matter
of what layer you find most convenient to block things... a firewall
is better closer to the bottom of the OSI layer model, a proxy is better
closer to the top of the OSI layer model.
Is it "censorship" not to want unwanted connection attempts to our
gear, and block unsolicited TCP connections inbound?
Is it "censorship" not to want unwanted exploit attempts to our
gear, and run everything through ClamAV, and use blocklists to
prevent users inadvertently pulling content from known malware sites?
There's no functional differentiation between blocking content for
one reason and blocking it for another. There's certainly a huge
difference in the POLICY decisions that drive those blocking decisions,
but the technology to do them is essentially identical. You can,
after all, block facebook on your firewall at the IP level and I think
we would both agree that that is "censorship" but also something a
firewall is completely capable of. It's just neater and more practical
to do at a higher level, for when facebook changes IP addresses (etc),
so a higher level block is really more appropriate.
2. You can of course easily do that via a variety of means, including
BOGUS'ing the domains in DNS, blocking port 80 traffic to their network
allocations, running an HTTP proxy that blocks them, etc. I presume
that any minimally-competent censor could easily devise a first-order
solution (using the software packages supplied with OpenBSD) in an afternoon.
It's a little trickier to do in practice. I kind of wish pfSense
included such functionality by default, it'd be so killer.
Last I checked, it was possible-but-a-fair-bit-of-messing-around.
I think that firewall/censorship is all semantics. The real question is the scale of the environment and the culture of your shop and areas of ownership.
I work in a large enterprise. Combining "functions" such as L3 firewalling with content filtering with url filtering with XXX can be difficult.
1. Can the platform actually handle all the traffic?
2. Does one group own ALL the separate functions? If not, RBAC becomes an important (and sometimes political) issue.
3. How easy is it to troubleshoot?
Although modern hardware is quickly catching up with all the glorious software features people want these days, in our environment we found it easier and saner to separate these functions. They were owned by different groups and the number of FWs we deploy vs the number of content filters didn't add up to make sense when aggregating functions was discussed.
In a smaller operation a Fortinet or other product that consolidates these efforts may make sense. In a larger operation in depends on many outside factors.
I've had the (dis)pleasure of working with PIX/FWSM/ASA since Vietnam. I've worked with Netscreen/Juniper, IPTables, PFsense, CheckPoint over Nokia, CheckPoint over Winblows, CheckPoint over UTM, Fortinet, Sonicwall (say Uncle!) and others. They all have their pros and cons and in the end it is specific to your shops needs.
More of a UNIX guy? BSD FWs. No we aren't going to talk about how BSD isn't UNIX. That's a different mailing list.
More of a Linux guy and need to make sure you have a vendor to yell at? CheckPoint. IPSO/SPLAT/GAEA is all Linux.
Not a UNIX/Linux guy and you need a more reliable vendor? And a traditionally safer bet? "No one ever got fired for buying Cisco."
Need to save money? Consolidate functions? Confident of the capabilities of the product? Fortinet.
MANAGEMENT: If you have a few FWs and you manage them independently life is grand. But what if you have 20? 50? 100? and if 30-40 percent of the policy is the same?
Cisco: NOTHING. Don't let them lie to you.
CheckPoint: Provider 1 and SmartManager.
Juniper: Not sure.
BSD/PFSense: Nothing I know of
Others: ???
Disclaimer: We are currently a CheckPoint/FWSM/PIX/ASA/Juniper shop. This is the byproduct of mergers/acquisitions/etc. We have standardized on CheckPoint and are phasing out the other vendors as they sunset. A major factor in the decision was management. In the end, if you separate the functions like we do, a FW is a FW is a FW. L3/4 isn't that complicated these days. It's L7 FWs that get the attention. So if the product is stable and has a good MTBF then it's not a huge difference to us as far as the capability of the FW to perform it's function. They all do it well.
I've found that this works decently well, via pfsync. It sends out
multicast IP packets with multi-valued elements describing the state
of the flows it has in its table.
If you're having pf inspect TCP sequence numbers, there's a bit of a
race condition in failover with frequently or fast-moving TCP streams.
As the window of acceptable sequence numbers moves on the active
firewall, they're slightly delayed in getting replicated to the
backup(s) and installed in their state tables.
Consequently, on failover, it's possible for some flows to get blocked
and which have to be re-created.
I've hit this and dug into it recently, so if you're having a problem,
I'd be happy to chat offlist.
An important feature lacking for now as far as I know is content/web
filtering especially for corporates wishing to block inappropriate/time
wasting content like facebook. Addition of this would place it a par
with the best like Sonicwall and Fortinet.
At a previous employer, we utilized a Fortigate 200B to replace multiple boxen (two firewalls, barracuda, etc). I found it utterly underpowered for the featureset (even with much of it disabled), and its ability to utilize multiple WAN connections was extremely limited. I realize this is only a low-to-midline example of their lineup, but I was consistently surprised by how easy it was to overwhelm the device, especially given the price-point. The only thing I remember liking was the SSL-VPN functionality, but we couldn't use it because there was no Vista support at the time, so that was disabled too.
Now, perhaps they've made progress, or their higher end devices perform better - just sharing my experience with the 200B.
