Evaluation of ASL vs RealWorld Settings

MY BACKGROUND:  I'm a senior network engineer for a very large IP deployment for a major US Telephone company as my secret identity.  At night I don my superhero tights and become a network consultant for small/mid-sized businesses (usually under 20 people).

--

I titled this post "ASL vs RealWorld" because I think some of the shortcoming of ASL reflect a too-narrow vision of where it can/should/would be deployed.  It's rather unfriendly to the SOHO environment.  I'll get into that below...

In any case, I've been evaluating ASL over the past few days in a shootout to determine if ASL will work as a headend for a large IPSec deployment.  My main concerns, in no particular order, are managability, self-monitoring, reliability, and functionality.  In the end I will have to terminate at least 100, and maybe as many as 1000 IPSec connections to allow field offices access to internal application services.

In any case, I wanted to take a few minutes to post regarding my initial evaluation of ASL.  Please note that I have not yet received all of the CPE gear (Consumer VPN routers and sattelite broadband gear) to test against ASL and the other products I'm looking at, so this is some initial comments.  When I've completed my shootout, I will post a more detailed evaluation.

---

First, ASL looks pretty good.  My test box is nothing amazing.  a P3-500 with 256MB and 4 2-port ethernet cards (Intel) and a 15GB IDE drive.  This is not reflective of a deployment machine, but is sufficient for testing purposes.

Installation was a breeze.  It would be nice to have some ability to control partitioning and services (for example, I don't need Squid, so I'd rather that large cache space be available for logging) but even that doesn't seem major.

The management interface is clean and pretty simple, although there is a bit of a learning curve and it's a tad steeper than I expected.  SSL connectivity seems pretty slow, however, even from a directly connected network.  This may be host-resolution related (haven't tested).

NAT, Proxy and packet filtering seems fine and performance is nominal.

As I stated above, my primary evaluation is for IPSec purposes.  I have not had an opportunity to test this as I am awaing equipment.

----

THE BAD:

There are some problems with ASL, some of which can be easily solved.

1)  NO JOURNALING FILESYSTEM!
This is a MAJOR problem and something that should be corrected as soon as possible.  Without a journaling filesystem, a power outtage, at best, will take the firewall down for longer than necessary.  At worse, you have an increased chance of a corrupted file system or needing to do a manual FSCK.

Linux now natively supports ext3.  ext2 filesystems can be converted to ext3 with no loss in data (run the tools, change the fsck timeout, change /etc/fstab to say "ext3", and reboot).

In a perfect world, all file systems would be ext3 (or any journaling system, but ext3 converts easy) except the squid-cache, which would run ReiserFS (also supported natively in kernel now).  Reiser is more tuned for file systems with many small files, like a cache.

2)  LACK OF DHCP SERVER SUPPORT
This is a major problem in almost any MIS setting.  PCs come and go, people bring in laptops, etc.  DHCP is the defacto standard to dynamic environments and requiring the need for another server to operate it basicly results in "why should I get ASL when XYZ will firewall, ipsec, and DHCP for me".  This is something that can be pretty easily added.

3)  LACK OF DHCP CLIENT SUPPORT
Another major shortcoming.  Many small offices connect to the internet via either a common in-building LAN or via consumer xDSL/Cable connectivity which hand out addresses via DHCP.  At this point, customers will dump ASL because it cannot support their connectivity model.

4)  LACK OF TRANSPARENT BRIDGING.  
This is less of a major problem, but still one that should be looked into.  Imagine customer receives a /29 IP block from their ISP (10.0.0.0/29 for this example).  10.0.0.1 is the ISPs router.  With a firewall (read router) in there, the customer makes the firewall 10.0.0.2.  At this point they want to use .3-.6 for public servers operating in a DMZ.  With bridging, those PCs can hang of of another ethernet, be packet filtered, but still default-gateway back to 10.0.0.1.  

Now yes, I grant you this issue could be addressed with good NATting (ie, map 10.0.0.3  192.168.1.3), which is why this is less important than the above issues. 

5)  NEED FOR HOT STANDBY
This is a tricky sucker and I read elsewhere on the board this is being addressed in future version, so I won't go on long here.   Suffice to say, it's needed to become a viable commercial firewall, particularily in VPN setups.

--

Basicly, it's a real good product and I look forward to testing it in more detail in the coming weeks when all of my CPE eval stuff are in my hands.   For my specific deployment, the lack of journaling FS (so far) is really the only major stumbling block, assuming that the VPN stuff functions as I hope.

ASL Crew:  PLEASE PLEASE PLEASE get a hotfix out as soon as possible to move the system to journaling.  If you need help on the procedures, let me know and I'll be happy to give you a hand.

This thread was automatically locked due to age.