Another alternative is RouterOS/MikroTik. Plenty of high end solutions and low end. ----------------------------------------------------------- Dennis Burgess, Mikrotik Certified Trainer Link Technologies, Inc -- Mikrotik & WISP Support Services Office: 314-735-0270 Website: http://www.linktechs.net LIVE On-Line Mikrotik Training - Author of "Learn RouterOS"

-----Original Message----- From: -Hammer- [mailto:bhmccie@gmail.com] Sent: Tuesday, November 08, 2011 5:32 PM To: nanog@nanog.org Subject: Re: Firewalls - Ease of Use and Maintenance?

You've worked with all the big dogs. What are you looking for? Alternative options?

-Hammer-

"I was a normal American nerd" -Jack Herer

...

Hello all. I am potentially looking at firewall products and wanted suggestions as to

On 11/08/2011 05:06 PM, Jones, Barry wrote: 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.

---------------------------------------- Barry Jones - CISSP GSNA Project Manager II Sempra Energy Utilities (760) 271-6822

P please don't print this e-mail unless you really need to. ----------------------------------------

On Wed, 2011-11-09 at 09:13 +0100, Seth Mos wrote:

I am biased because I am a pfSense developer.

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. How does the pfSense developer attitude towards filtering the entire Internet, IPv6 included, currently stand? Tom

On Wed, 2011-11-09 at 12:01 +0100, Seth Mos wrote:

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. Tom

On 11/09/2011 03:22 PM, Richard Kulawiec wrote:

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.

---rsk

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. Alex

On Wed, Nov 09, 2011 at 03:32:45PM +0300, Alex Nderitu wrote:

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. 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. ---rsk

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. And the list goes on and on and on.... -Hammer- "I was a normal American nerd" -Jack Herer On 11/09/2011 08:00 AM, Joe Greco wrote:

...

On Wed, Nov 09, 2011 at 03:32:45PM +0300, Alex Nderitu wrote:

...

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.

Still, vote++ for pfSense.

... JG

On Wed, 09 Nov 2011 08:00:01 CST, Joe Greco said:

...

On Wed, Nov 09, 2011 at 03:32:45PM +0300, Alex Nderitu wrote:

...

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.

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?

I do believe that Alex was saying "blocking outbound access to time wasters like Facebook" is a censorship function, not a firewall function.

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. Nathan

On Wed, Nov 9, 2011 at 5:24 AM, Nick Hilliard <nick@foobar.org> wrote:

On 09/11/2011 12:22, Richard Kulawiec wrote:

...

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.

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).

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. Cheers, jof

I meant config sync, not state sync.

I have multiple deployments of the config synchronization working just fine. :)

On 09/11/2011 19:07, C. Jon Larsen wrote:

put the main portion of the conf in subversion as an include file and factor out local differences in the configs with macros that are defined in pf.conf

Easy.

As I said, it's not a pf problem. Commercial firewalls will do all this sort of thing off the shelf. It's a pain to have to write scripts to do this manually. Nick

The other high cost of "free" that people sometimes overlook is liability. Many organizations want/need someone to hold the fire to in the event of an issue. I believe in open source and am an advocate of open source computing (this email is from my Debian (NOT UBUNTU) laptop and my BSD workstation is right beside it), but at an organizational level, if I had an open source FW and a vulnerability was allowed to get thru it and compromise customer or confidential data, my management would be looking to the vendor for answers. If I told them "it's open source, there is no "vendor"" it would not go over well. Why? Because the liability is now assumed by my company. So when the customer sues it's on me. Or (and we see these on a regular basis) when the patent troll contacts us about his patent that the open source product is violating and wants compensation the liability stops at my company. IF I am using a vendor supported platform, I can take that to my vendor and discuss options. Many (not all) large businesses have agreements with vendors that go well beyond NDAs. Agreements about liability. Healthcare/Financial/Defense all have these kinds of agreements. I'm not saying it's fair. It's just how the world works. For that reason there are some areas where open source is smart while there are other areas (a firewall you depend on to protect you) where open source may put you and your employer at risk. You have to consider that. Or... Some of us do. -Hammer- "I was a normal American nerd" -Jack Herer On 11/10/2011 07:36 AM, Jimmy Hess wrote:

On Wed, Nov 9, 2011 at 2:44 PM, Nick Hilliard<nick@foobar.org> wrote:

...

On 09/11/2011 19:07, C. Jon Larsen wrote: As I said, it's not a pf problem. Commercial firewalls will do all this sort of thing off the shelf. It's a pain to have to write scripts to do this manually.

Ah... the high cost of 'free' products, you have to do some scripting, or pay another organization to support it / do scripting work for you. The advantage is... you _can_ do a small amount of scripting or programming to add minor additional required functionality. And a very large number commercial firewalls do not have config synchronization, except, perhaps between a failover pair, anyways.

Anyways... I can see synchronizing blacklists on a firewall, or having a firewall configured to fetch certain 'drop' rules from a HTTPS URL. Otherwise: the thought of mass synchronization of lots of firewalls can be bad in that it creates a single point of system compromise; supposing the synchronization source machine were compromised, one dirty rule inserted by an intruder followed by a kick off of the sync mechanism, and then actions to break it/prevent further syncing, defeats the security of the entire deployment....

-- -JH

OK. Right off the bat you know I can't and won't. But in some places it is common practice to make sure agreements are in place to make sure all parties are protected based on how a product is expected/designed to perform. I can't say more than that. Realize I'm speaking about things that are solely on the vendor. Not "Did you configure the ACL properly?" What you can Google is the names of companies who have settled out of court against various trolling lawsuits vs the names of companies that are still in litigation. There is a mix of both manufacturer/vendor and end customer. It all depends on the case. This shouldn't surprise you. If Toyota makes a defective brake and you slam into someone else, your insurance covers you. Eventually, if the issue scales out to the point that it is obvious that Toyota made a defective brake and it is not your fault, some insurance companies collectively will go to the government or directly to the manufacturer for compensation. This is no different. If you sell me a FW and it catches on fire thru no fault of my own and then the public finds out that FWs are catching on fire all over the place, it's a good bet that that FW vendor will be getting some lawsuits. If a FW vendor reports a product to work a certain way and instead thru a massive vulnerability or development oversight it does not the same applies. Software. Hardware. Physical (fire). Logical (vulnerability). I'm not saying that it happens all the time and I'm not even saying it's a general practice. What I'm saying is it happens. And depending on your business vertical it could be a very real consideration. COMPLETELY 100% MADE UP HYPOTHETICAL SCENARIO: I put a FW in. I put proper L3 ACLs in. I block 443 inbound. I didn't say I block HTTPS. I block 443. I test it by telnetting from the Internet to 1.1.1.1:443 and I am unable to connect. Looks good. A month later our CEO is surfing the Internet. Thru a development oversight in the product, when I NAT or PAT him to the Internet his source port is not pulled from the Ephemeral range but is instead sourced as port 443. He of course goes to sites riddled with Malware because that's what CEOs do. They click on links. So the Malware website initiates a new TCP session to destination port 443 with his NATted IP. The state table has an entry for that IP and 443 and even though this is a new TCP session the FW lets it thru. The malware site bad guys are able to retrieve confidential information about a merger and publish it. The other company that we were merging with sues us because the information is leaked to the public and adversely impacted their stock value. Everything in the above paragraph is able to be documented thru forensics and it is indisputable that the FW was properly configured and should have blocked it but didn't. The FW did NOT perform as advertised/designed. This is NOT the fault of me or my company. If a few thousand dollars is at stake nothing may come of this. If tens or hundreds of millions of dollars are at stake I promise you that our lawyers will be contacting the manufacturer whose product did not perform as advertised. They will compensate (in one way or another) us for our losses. It's a big ugly world full of lots of lawyers. -Hammer- "I was a normal American nerd" -Jack Herer On 11/10/2011 09:14 AM, Richard Kulawiec wrote:

On Thu, Nov 10, 2011 at 08:52:22AM -0600, -Hammer- wrote:

...

The other high cost of "free" that people sometimes overlook is liability.

Please point to an instance (case citation, please) where a commercial firewall vendor has been successfully litigated against -- that is, held responsible by a court of law for a failure of their product to provide the functionality that it's claimed to provide.

---rsk

Look the thread was about considerations for various firewalls. Eventually it spun off to be considerations and issues with Open Source options. I was merely pointing out a consideration that some folks have to take into account. You don't have to like it, agree with it, or even believe it. But it does happen and it is out there. I was just pointing it out. Take it for what you want but arguing it is pointless. It's out there for some of us. -Hammer- "I was a normal American nerd" -Jack Herer On 11/10/2011 10:04 AM, Peter Kristolaitis wrote:

Your hypothetical scenario assumes you're the only organization compromised by the flaw (or one of very few), and not #3972 on the list, in which case the company could go bankrupt before a court can hear your case, and the "liability protection" they offered you is worth the electrons it's printed on. It's great if you're a Fortune 50 and have the legal, political and financial clout to be #1 on the lawsuit list, but nearly worthless for most organizations.

- Peter

On 11/10/2011 10:39 AM, -Hammer- wrote:

...

OK. Right off the bat you know I can't and won't. But in some places it is common practice to make sure agreements are in place to make sure all parties are protected based on how a product is expected/designed to perform. I can't say more than that. Realize I'm speaking about things that are solely on the vendor. Not "Did you configure the ACL properly?"

What you can Google is the names of companies who have settled out of court against various trolling lawsuits vs the names of companies that are still in litigation. There is a mix of both manufacturer/vendor and end customer. It all depends on the case.

This shouldn't surprise you. If Toyota makes a defective brake and you slam into someone else, your insurance covers you. Eventually, if the issue scales out to the point that it is obvious that Toyota made a defective brake and it is not your fault, some insurance companies collectively will go to the government or directly to the manufacturer for compensation. This is no different. If you sell me a FW and it catches on fire thru no fault of my own and then the public finds out that FWs are catching on fire all over the place, it's a good bet that that FW vendor will be getting some lawsuits. If a FW vendor reports a product to work a certain way and instead thru a massive vulnerability or development oversight it does not the same applies. Software. Hardware. Physical (fire). Logical (vulnerability). I'm not saying that it happens all the time and I'm not even saying it's a general practice. What I'm saying is it happens. And depending on your business vertical it could be a very real consideration.

COMPLETELY 100% MADE UP HYPOTHETICAL SCENARIO:

I put a FW in. I put proper L3 ACLs in. I block 443 inbound. I didn't say I block HTTPS. I block 443. I test it by telnetting from the Internet to 1.1.1.1:443 and I am unable to connect. Looks good. A month later our CEO is surfing the Internet. Thru a development oversight in the product, when I NAT or PAT him to the Internet his source port is not pulled from the Ephemeral range but is instead sourced as port 443. He of course goes to sites riddled with Malware because that's what CEOs do. They click on links. So the Malware website initiates a new TCP session to destination port 443 with his NATted IP. The state table has an entry for that IP and 443 and even though this is a new TCP session the FW lets it thru. The malware site bad guys are able to retrieve confidential information about a merger and publish it. The other company that we were merging with sues us because the information is leaked to the public and adversely impacted their stock value. Everything in the above paragraph is able to be documented thru forensics and it is indisputable that the FW was properly configured and should have blocked it but didn't. The FW did NOT perform as advertised/designed. This is NOT the fault of me or my company. If a few thousand dollars is at stake nothing may come of this. If tens or hundreds of millions of dollars are at stake I promise you that our lawyers will be contacting the manufacturer whose product did not perform as advertised. They will compensate (in one way or another) us for our losses. It's a big ugly world full of lots of lawyers.

-Hammer-

"I was a normal American nerd" -Jack Herer

On 11/10/2011 09:14 AM, Richard Kulawiec wrote:

...

...

The other high cost of "free" that people sometimes overlook is liability. Please point to an instance (case citation, please) where a commercial firewall vendor has been successfully litigated against -- that is, held responsible by a court of law for a failure of their product to provide

On Thu, Nov 10, 2011 at 08:52:22AM -0600, -Hammer- wrote: the functionality that it's claimed to provide.

---rsk

WOW. You really are naive.... -Hammer- "I was a normal American nerd" -Jack Herer On 11/10/2011 12:12 PM, Richard Kulawiec wrote:

On Thu, Nov 10, 2011 at 09:39:29AM -0600, -Hammer- wrote:

...

OK. Right off the bat you know I can't and won't.

Right. I know you can't and won't. I can't either. So we can summarily dismiss all the concerns about liability because they have no relationship to reality. You will not be suing BigFirewallCo, no matter how horribly their product fails, no matter how bad the damage is, no matter how obvious to all of us the failure is, no matter how culpable we might all agree they are, because (a) your pockets aren't as deep as BigFirewallCo's, and (b) you'd probably lose anyway (c) after 11 years and a lot of billable hours for everyone's attorneys. (s/you/I/ and everyone else, unless we happen to work for a Fortune 50 company...and probably not even then.)

When it comes to security, I think it's better to rely on software engineering than litigation.

---rsk

OK. Maybe I jumped to hard. But to tell me that what I'm referring to has never happened (even though I've participated) just because he hasn't heard of it is not the best way to approach an argument. When these things happen, there are agreements in place so it's not discussed. Especially when it's settled out of court. If you want some fun reading on the subject google Walker Digital or Leon Stambler. Again, I never said it happens to everyone. But it does happen and some of us have to consider it. I didn't realize it would come under such scrutiny just because it isn't widely published. Again, I'll try and leave this thread alone. -Hammer- "I was a normal American nerd" -Jack Herer On 11/10/2011 12:24 PM, Valdis.Kletnieks@vt.edu wrote:

On Thu, 10 Nov 2011 12:12:21 CST, -Hammer- said:

...

WOW. You really are naive....

I think Rich has been around long enough that he gets called a *lot* of things (many of them non-complimentary), but this is the first time this century anybody's called him *naive*... ;)

I changed my mind. I want to clear this up. Here is an example of where a patent troll skipped over the manufacturer and went straight for the end customer. There are dozens of these attacking all verticals and manufacturers alike for various reasons. http://dockets.justia.com/docket/texas/txedce/2:2008cv00471/113504/ So a customer buys a product that contains a technology. Then the customer is sued for possessing said technology. You don't think the customer (Merrill Lynch / BofA / Citigroup / etc) isn't gonna take that lawsuit and call the manufacturer up and tell them they are gonna eat it? You don't think a financial institution or a healthcare organization would attempt to recuperate the costs? You don't think that after the fact agreements are put in place so that frivolous lawsuits like this are appropriately handled between the manufacturer and the customer in the future? When millions of dollars are at stake? You don't have to like it. But you should be a little more objective. I am not speaking of specific cases I'm involved in. I just googled a few things and found some results.... -Hammer- "I was a normal American nerd" -Jack Herer On 11/10/2011 12:24 PM, Valdis.Kletnieks@vt.edu wrote:

On Thu, 10 Nov 2011 12:12:21 CST, -Hammer- said:

...

WOW. You really are naive....

I think Rich has been around long enough that he gets called a *lot* of things (many of them non-complimentary), but this is the first time this century anybody's called him *naive*... ;)

Hey all. I wanted to say thanks for all the advice. Barry -----Original Message----- From: Jack Bates [mailto:jbates@brightok.net] Sent: Thursday, November 10, 2011 6:06 PM To: Valdis.Kletnieks@vt.edu Cc: nanog@nanog.org Subject: Re: Firewalls - Ease of Use and Maintenance? On 11/10/2011 12:24 PM, Valdis.Kletnieks@vt.edu wrote:

I think Rich has been around long enough that he gets called a*lot* of things (many of them non-complimentary), but this is the first time this century anybody's called him*naive*...;)

Given that all of humankind is naive, it would be redundant. The other things are much more entertaining. Jack

You guys are hilarious. OK. I give up. It never happens. I'll leave this thread alone. -Hammer- "I was a normal American nerd" -Jack Herer On 11/10/2011 12:19 PM, Jay Ashworth wrote:

----- Original Message -----

...

From: "Richard Kulawiec"<rsk@gsp.org>

...

Right. I know you can't and won't. I can't either. So we can summarily dismiss all the concerns about liability because they have no relationship to reality. You will not be suing BigFirewallCo, no matter how horribly their product fails, no matter how bad the damage is, no matter how obvious to all of us the failure is, no matter how culpable we might all agree they are, because (a) your pockets aren't as deep as BigFirewallCo's, and (b) you'd probably lose anyway (c) after 11 years and a lot of billable hours for everyone's attorneys. (s/you/I/ and everyone else, unless we happen to work for a Fortune 50 company...and probably not even then.)

Yeah, Rich, but come on: you and I -- and even his managers -- know that while that is true (that no one's actually going to sue anyone, and likely legally cannot anyway), that *still* won't keep Pointy Haired Bosses from making that *capability* a firm requirement.

That's why their hair is pointy.

Cheers, -- jra

---- Original Message -----

From: "Leo Bicknell" <bicknell@ufp.org>

Just ask folks like AutoZone or DaimlerChrysler how much it cost to use Linux when they were sued by SCO and had to defend themselves. Sure, they prevailed, but I bet tens of thousands of dollars were spent on litigation.

Sure. But compare that to the millions they would have spent using SCO... :-) Cheers, -- jra [1]Yes, I realize AutoZone may have been paying for their Linux distro... -- Jay R. Ashworth Baylink jra@baylink.com Designer The Things I Think RFC 2100 Ashworth & Associates http://baylink.pitas.com 2000 Land Rover DII St Petersburg FL USA http://photo.imageinc.us +1 727 647 1274

On Thu, Nov 10, 2011 at 08:30:46AM -0800, Jonathan Lassoff wrote:

...

As I said, it's not a pf problem. ?Commercial firewalls will do all this sort of thing off the shelf. ?It's a pain to have to write scripts to do this manually.

Agreed. This is rather a pain to have to do manually each time (either scp'ing or scripting). It's unfortunate that there's not a conventional script or mechanism for doing this.

I don't see why this is a problem. I've been using tools like make, RCS (or CVS or subversion), perl, and rsync to maintain all kinds of unified and diverse configurations on small and large numbers of systems for many years. It's simple, it's scalable, it's easy to write, it's portable, it's robust (provided you pay attention to command exit codes), and it allows easy integration between disparate configuration files. (As an example of that last: I can cause changes in pf.conf to be synchronized with appropriately-matching changes in sendmail.cf or named.conf. Use of "make" ensures that they're kept in a consistent state. Of course, if I make a mistake, they're consistently wrong: but that's highly desirable.) Yes, you have to understand the interrelationships between all these moving parts to write the scripts/makefiles; but that's a good thing. And the payoff is that you get FAR more flexibility than any commercial product. And it's free (modulo your time investment...and you'd be investing time anyway, trying to make some vendor's setup do what you want). ---rsk