I'm left questioning my effort of five hours last night. I have a feeling
that, like many of my complaints to WatchGuard, this will invariably be
discounted out of hand. In order to salvage those hours of work, I've
crossposted this message to the firewalls mailing list so that someone
might gain something from my effort. I realise now that WatchGuard never
really cared about the faults of its systems, and to that end, it's
customers. I hope that WatchGuard as a whole will change its philosophy
about how it treats its customers to prevent cases like mine in the
future.
Thank you.
[note to the mailing list: This is a CC of an exchange between myself and
WatchGuard, started out of something I had said to the mailing list a few
weeks ago. As I stated above, it does not appear as though WatchGuard will
act on this information, so I will give you the same information that I
gave them. Please note that if you do have the WatchGuard firewall on your
network, you have the potential to incur these problems. While you, as a
customer of WatchGuard, might have had wonderful experiences with them,
bear in mind that this is how they treated a customer that helped the
company get its feet off the ground.]
On Wed, 8 Apr 1998, Randy Boroughs wrote:
> Brian,
>
> Thank you for taking the time to detail your experiences with our
> company and our product. You have given me some insight that will
> ultimately improve our company and our products. I now have a personal
> challenge; to create a customer base satisfied enough to invalidate your
> position. I take this challenge seriously, and hope that one day we can
> chat about WatchGuard's ultimate success.
>
> Randy Boroughs
> VP of Product Management
> WatchGuard Technologies
> (206) 521-1419 (phone)
> (206) 521-8341 (fax)
> randy .
boroughs @
watchguard .
com
> www.watchguard.com
On Tue, 7 Apr 1998, Brian Macke wrote:
> I've put a lot of thought into how I should respond to this, sometimes
> doubting whether I should respond or not. I think I've come to the
> conclusion that it's for the better that I do outline what problems I had
> with both the WatchGuard product as well as the company itself. While the
> following comments are my opinion, they are based in the experiences I
> had from when I began administering Telegroup's firewall system in
> September of 1997.
>
> 1> The 128 rule limit
> This, by far, was the worst aspect of the firewall that my company
> could have ever encountered. We only discovered it well after we had lost
> major portions of our production traffic due to the peripheral
> repercussions that I will discuss later. This limit is, allegedly,
> codified and as a result should have been placed in the literature of the
> firewall. A company cannot idly stand by and let its customers discover
> such things on its own. Otherwise, embittered customers, like myself, will
> take such a polarised stance on the company that it will only impede
> public relations like it has in my postings to the Firewalls mailing list.
>
> 2> The source port blocking issue
> This problem appears to have been a direct cause of the
> aforementioned limit. This was not the worst aspect of this problem,
> however, as I'll mention later. To summarise the problem, during normal
> operation, even during low usage times, the firewall would block traffic
> based on the source port of the connection. For example, if there were a
> rule in the firewall allowing outgoing connections to, say, 2099, but the
> incoming rule was to block - when someone would make a normal outgoing
> connection (say, to port 80), and the source port were 2099, that
> connection would get blocked. Here's a diagram:
>
> Inside firewall Outside
> User A WG Web Site
> Dst port = 80 Src Port = 80
> Src port = 2099 Dst Port = 2099
>
> Rule tcp/2099
> Allow any/any outgoing
> Deny any/any incoming
> 2099 --------------------Allow------------------> 80
> 2099 <-------------------Deny-------------------- 80
>
> I hope this illustrates exactly what I'm trying to say that Telegroup
> experienced serious problems with production traffic because of a bug in
> the software for WatchGuard
>
> 3> Massively poor and judgemental technical support
> I do not know if you have any say in the Technical Support area,
> but WG's support was far worse than any company's I have ever experienced
> during my eleven years in the work force. Things massively started off on
> the wrong foot when I was told that I could only use Windows 95/NT or
> Redhat Linux 4.0 for the Console software. I felt highly uncomfortable
> having an extremely old version of RedHat on my workstation, so I
> installed the latest version of Slackware (3.3, if memory serves me
> correctly), and installed the Console software on top of it. I was
> instantly told that it wouldn't work (even after being successful), and
> that it was wrong for me to go outside the recommended install. That may
> be true, but this meant that every single bug report I ever put in for the
> product was met with "It's your fault. You're the aberrant one." even
> after I had taken the console software off the Slackware machine. I gave
> the tech support vivid and undeniable proof that bugs were there, and they
> insisted that it was still because of Slackware. They never listened to me
> once, ever. I can say that rather authoritatively, since I have yet to see
> any of the things I've mentioned in any of the product releases. To this
> day, I believe that Telegroup should have dropped all use of WatchGuard
> upon the first sign that we could no longer get a single person in Tech
> Support to listen to us.
>
> 4> Poor hardware
> When we signed onto the reseller program, we received three
> fireboxen. Two were sold to satellite offices, and the third was kept for
> replacing our old box (486/100, CD-ROM, 540 meg HD. Worth mentioning now,
> since they're coming up again later). We installed the new box, much to
> the awe of other employees. But shortly after the install, the honeymoon
> was over and it was discovered that the system had a bad floppy drive. We
> RMA'ed the box, and replaced it with a new one. That one also had a bad
> floppy drive. We RMA's that box, got the replacement, and that, too had a
> bad floppy drive. We replaced the drive (with approval from WG), and it
> was then discovered that it was the FDC that was actually bad in all three
> boxes. Oh, it should also be mentioned that it appeared that box #2 had
> other problems as well, since the httpd-proxy and other programs were
> dying with Signal 11's, the bode of bad hardware.
> We ended up having to revert back to the original box with and old
> configuration because of the serious hardware issues that came up with the
> new box. At that point, we were left with no alternative other than to
> sever our usage of the WG product in all locations and find an appropriate
> alternative.
>
> 5> Latency
> WG has purported that it can handle T1 speeds, but instead we
> found that with even the most sparse configuration, we barely could use
> 50% of our available T1. As more rules were added to the box, the slower
> our connection became until it was barely better than a 256k link. As a
> point of information, I've installed Linux on one of the old 486's, along
> with the ipfwadm package and have been able to get 256kBps transfer rates,
> even with complex configurations on par with the WatchGuard setup. The
> software on the WG boxes is just too bloated to be able to handle a large
> amount of bandwidth.
>
> 6> Random reboots
> This problem was never truly pinpointed, however it had a number
> of suspected parents. The first was, of course, the 128-ruleset limit.
> Others included bugs in the fw-watcher daemon and the control daemon. Tech
> Supports canned response was that I was running Slackware, however the
> reboots occurred even after I had switched to NT. As far as I know, not
> only was this problem never traced back to a source, it was also never
> corrected, either.
>
> 7> controld
> Controld was a thorn in our sides from the minute we installed our
> 2nd firewall. Notification was always dependent on which firewall sent its
> config file to controld first. So we had to make a choice between which
> firewall was more important. Failing that, we ended up having to run
> controld on separate machines in order to get the most out of the
> firewalls. This, allegedly, was solved in 2.3, but we couldn't upgrade to
> it. This was because of....
>
> 8> 2.3 broke SQL
> When ping was fixed, this broke SQL, and Tech Support felt that
> it was a non-issue, so it was dropped, apparently. As a result, production
> traffic was lost, and Telegroup was left running an old, outdated version
> of the software.
>
> 9> remote upgrades
> This was a very big issue that can probably never be solved. We
> were administering two boxes in Europe for our satellite offices, and the
> only way we could upgrade the boxes would be to send a floppy to the
> remote sites, hope they put it in properly, then have them reboot the
> machine. This was a very bad policy from an support standpoint, and we
> needed a way to upgrade the OS on the machines without cutting new
> floppies. Again, lacking any real possibility of this being changed, I felt
> that the WatchGuard was a failure in our situation.
>
> ---
>
> I believe this concludes all of the possible problems I had with the
> WatchGuard when we were using them in production. I'm sure I've left out
> some things, but I believe this is a good sampling of the problems.
>
> To preemptively cover the question, I don't believe there is anything that
> could be done to convince me to use any of WatchGuard's products ever
> again. They did have positive points, like the encrypted communications.
> But I stand by my statement that there are too many serious blowbacks to
> the WatchGuard firewall product to actually use it ever again. This
> includes Telegroup, as well as any other company I might work for in the
> future. I feel that the market for "Firewall Appliances" will soon fade
> from the market as people realise that you can't have it all in one box.
>
> I've worked very hard to change co-workers opinion of what a firewall
> truly is. We're moving away from pointing at a box and saying, "This is
> the firewall," and more towards "This is part of our firewall system." It
> would be very silly for me to endorse a product which attempts to do too
> many things and fails to do at least some of the jobs correctly..
>
> Bearing all of this in mind, I implore you to take my opinions seriously,
> as I've put a lot of thought into them. I have nothing to really gain by
> sending this letter, but I assume that you do. If WatchGuard's product
> improves, then the next time I post about WG on the firewalls list, I can
> be resoundingly rebutted by someone who's used WG since my bad
> experiences. At that point, I will know that things have changed enough at
> WatchGuard that my views are no longer valid, and I will stop spreading
> them. Until that time, however, I will be up front and honest with anyone
> asking about whether or not I trust WatchGuard as a firewall or as a
> company.
>
>
> On Mon, 6 Apr 1998, Randy Boroughs wrote:
>
> > Hi Brian,
> > A little over a week ago you commented on the Firewall mailing list that
> > the WatchGuard product "has such serious blowbacks that I wouldn't trust
> > it as a monitor stand, much less a production system." I obviously have
> > an interest in ensuring that the WatchGuard products are successful
> > security appliances. Could you please expand upon your comments and
> > give me a better idea of how you arrived at this conclusion. Thanks for
> > your time.
> >
> > Randy Boroughs
> > VP of Product Management
> > WatchGuard Technologies
> > (206) 521-1419 (phone)
> > (206) 521-8341 (fax)
> > randy .
boroughs @
watchguard .
com
> > www.watchguard.com
> >
>
> -Brian James Macke macke @
telegroup .
com
> Unix SysAdmin/Security Specialist Telegroup, Inc.
> "In order to get that which you wish for, you must first get that which
> builds it." -- Unknown
>
>
>
>
-Brian James Macke macke @
telegroup .
com
Unix SysAdmin/Security Specialist Telegroup, Inc.
"In order to get that which you wish for, you must first get that which
builds it." -- Unknown
|
|
