[Updated June 2005] I'm sure things have improved in the half decade since I tested novell's firewall. That's plenty of time for any company to get their act together, and their decision to run on top of a *nix os does seem to bode well. Back when I played with it, though, I was less than impressed. This is what I had to say back then

Seven reasons not to use BorderManager

1. Novell complicates simple tasks

Compare adding a NAT rule in BSD's ipnat:
	echo "rdr ne1 64.17.42.5/0 port 80 -> 192.168.1.5 port 80" >> /etc/ipnat.rules
	ipnat -c -f /etc/ipnat.rules

with adding a NAT rule in Novell's INETCFG.NLM:
	load inetcfg
	Select protocals > Bindings
	Select the NIC you want to bind an address to
	Select "Expert TCP/IP Bind Options"
	Select Network Address Translation
	Select Network Address Translation Table
	Press Insert
	Type in the Public and Private addresses
	Press Escape so the rule gets added to the NAT table
	Press Escape
	Press Escape
	Select Yes (you are choosing to save your changes)
	Press Escape
	Press Escape
	Select Yes (...so you can leave INETCFG.NLM)
	down the server
	restart the server

2. BorderManager's implimentation of NAT is broken

Most good firewalls are capable of redirecting the endpoints of two sockets (two ip address/port combinations) to one ipaddress. For example, you would do this in ipnat as follows:

        echo "rdr ne1 64.17.42.5/0 port 80 -> 192.168.1.5 port 80" >> /etc/ipnat.rules
        echo "rdr ne1 64.17.42.5/0 port 22 -> 192.168.1.9 port 22" >> /etc/ipnat.rules
        ipnat -c -f /etc/ipnat.rules

BorderManager cannot do this. If you have mapped 64.17.42.5 to 192.168.1.5 for port 80 on a BorderManager box, any other ports on 64.17.42.5 must also map to 192.168.1.5

3. The Novell documentation for BorderManager is inconsistant

example 1
A. The Installation and Setup (100-004452-002-B) guide for BorderManager Enterprise Edition 3, which is included with BorderManager 3.5 when the product ships, recommends configuring the firewall by setting the default action to "Deny Packets in Filter List", setting up the list with a single filter of ALL ALL (all ports, all addresses), and then setting up exceptions to allow specified traffic through the firewall.

B. Novell's Guide to BorderManager(0-7645-4540-X), which is also published by Novell Press, says to set the default rule to "Permit Packets in Flilter List", then use rules in the filter list to allow specified traffic through the firewall.

4. BorderManager can't filter on ICMP type

As near as I can tell, you either allow ICMP or you disallow it. If you let people ping your web server, you let them send it ICMP redirects

5. The system-defined rules are broken

On close inspection of the rule named "pop3-stateful", you will see that the line for stateful filtering reads "Disabled". The rule named "realaudio" only allows connections to destinations at port 7070, which prevents use of realaudio sites using tcp on port 554. I'm sure there are other examples, but those are the ones that I've personally dealt with. How did I deal with them, you may ask? I created new rules that had the proper flags/ports set....there's no way to modify the system-defined rules in bordermanager.

6. The HTTP rules are dangerous

You either allow it, or you don't. There's no way to filter out PUT, DELETE, LINK, or UNLINK commands. (Yes, I know: The web server ought to be configured so that it doesn't allow those anyway. Personally, though, I'm a believer in the idea of using a belt and suspenders; i.e. multiple layers of protection.)

7. The password is in plain text

BorderManager doesn't require an NDS password to run FILTCFG.NLM. It only requires the rconsole password, which is, of course stored in the netinfo.cfg file. Yes, I know that normal users don't have the ability to read that password, but it still bothers me.

BSC 1005

BSC 1010

BSC 1011

BSC 1930