inner workings of IP tables

inner workings of IP tables

[Naleendra]

[-- Attachment #1: Type: text/plain, Size: 688 bytes --]

HI LIST,

	As I've informed you 'fore I am working on the qualitative analysis
of IPTABLEs... & I need to compare it with Checkpoint. From what I've heard
Checkpoint is still the best. 

	1- Because there is minimal network load
	2- It works between the layers datalink & network making the OS that
much secure & making it a must pass-through layer for all pkts. in & out.
	3- It securely supports typical " loop-hole prone protocols such as
FTP, UDP & RPC protocols.

	No, I am not here to brag about checkpoint. I hardly know the thing.
& I use a IPTables firewall. I need some info /web sites on how the Iptables
modules work.. yeah the inner workings. Can some one help pls. ?

 -nal

[-- Attachment #2: Type: text/html, Size: 1524 bytes --]

Re: inner workings of IP tables

[Antony Stone]

On Saturday 28 September 2002 3:11 pm, Naleendra@dms.lanka.net wrote:

> I am working on the qualitative analysis of IPTABLEs... & I need to compare
> it with Checkpoint. From what I've heard Checkpoint is still the best.

Have you heard this from people who have compared the products, and can show 
you how they tested them, or have you heard this from people who either 
bought or sell the Checkpoint product, on the basis that it's got the biggest 
name in the market (the "no-one got fired for buying IBM" philosophy) ?

> 1- Because there is minimal network load

I do not think a firewall product can generate any network load.   A firewall 
filters packets which pass through it, therefore the network load is created 
by the clients and servers on either side, not by the firewall itself.

Checkpoint's product is available to run on Windows Operating Systems, 
Solaris, Red Hat Linux, and Nokia IPSO (a BSD derivative).   The performance 
of their product varies tremendously on these different platforms (from bad 
to good in the order I've given), but that's no reflection on Firewall-1 
itself.

If you want netfilter to give you high performance, run it on a fast 
processor with enough memory.

> 2- It works between the layers datalink & network making the OS that much
> secure & making it a must pass-through layer for all pkts. in & out.

No - Check Point's product works at a higher level than netfilter, in my 
opinion.   They are both OSI layer 3/4 filtering systems, however netfilter 
is built into the Operating System kernel, whereas Firewall-1 is added on top 
of the Operating System as an application.   There is, for example, no 
inherent packet filtering in the Windows 2k kernel, yet once you put 
Firewall-1 on top, it becomes a firewall.

I would say that for this question netfilter is more secure because it is 
embedded in the kernel; Firewall-1 is an application which could get stopped.

> 3- It securely supports typical " loop-hole prone protocols such as FTP,
> UDP & RPC protocols.

What do you mean by "loop-hole prone" ?   FTP is well supported by netfilter 
and is no less secure than Firewall-1's support for it.

I don't know what you mean by UDP in this context, however I do not believe 
there is any difference between the security of netfilter vs Firewall-1 for 
UDP protocols.

RPC is an application-level protocol (usually classified as OSI layer 5) and 
both netfilter and Firewall-1 are stateful inspection packet filters.   
Again, I do not believe there is any difference between the security of 
netfilter vs Firewall-1 for RPC.

> No, I am not here to brag about checkpoint. I hardly know the thing.

Where have you got your information suggesting that Firewall-1 is better ?

> I use a IPTables firewall. I need some info /web sites on how the
> Iptables modules work.. yeah the inner workings. Can some one help pls. ?

If you want to see how netfilter works inside, the source code is readily 
available, and you can really see how everything gets done.   You won't get 
*that* opportunity with Firewall-1,

Check Point Firewall-1 does not have a flawless security record.   Did you 
know, for example, that until FW-1 v4.1 (about 2 years ago) every version of 
FW-1 allowed access from the Internet to any machine on the internal network 
on TCP/UDP ports 53 under a standard installation ?

Netfilter does not have a flawless security record either, but like most open 
source projects, the flaws tend to get found sooner in the development cycle, 
and they certainly get fixed pretty damned fast if they ever get out into a 
released vesion, compared to commercial / proprietary systems.

I wuld be very interested in any reproducible data you have comparing the 
security of Check Point Firewall-1 with netfilter.

Antony.

-- 

In science, one tries to tell people
in such a way as to be understood by everyone
something that no-one ever knew before.

In poetry, it is the exact opposite.

 - Paul Dirac

Re: inner workings of IP tables

[Mitesh P Choksi]

What about ease of use? The GUI
Multiple firewalls.
Management of firewalls.
Delegation of firewalls and types of rules.

I believe that CheckPoint has the level of application along with that
allows all of hte above. For Netfilter you have to build on top of it.

We can't compare apples to oranges.

CheckPoint goes a bit beyond packet filtering on the user
interaction/commercial side of it.

Antony Stone said:
> On Saturday 28 September 2002 3:11 pm, Naleendra@dms.lanka.net wrote:
>
>> I am working on the qualitative analysis of IPTABLEs... & I need to
>> compare it with Checkpoint. From what I've heard Checkpoint is still
>> the best.
>
> Have you heard this from people who have compared the products, and can
> show  you how they tested them, or have you heard this from people who
> either  bought or sell the Checkpoint product, on the basis that it's
> got the biggest  name in the market (the "no-one got fired for buying
> IBM" philosophy) ?
>
>> 1- Because there is minimal network load
>
> I do not think a firewall product can generate any network load.   A
> firewall  filters packets which pass through it, therefore the network
> load is created  by the clients and servers on either side, not by the
> firewall itself.
>
> Checkpoint's product is available to run on Windows Operating Systems,
> Solaris, Red Hat Linux, and Nokia IPSO (a BSD derivative).   The
> performance  of their product varies tremendously on these different
> platforms (from bad  to good in the order I've given), but that's no
> reflection on Firewall-1  itself.
>
> If you want netfilter to give you high performance, run it on a fast
> processor with enough memory.
>
>> 2- It works between the layers datalink & network making the OS that
>> much secure & making it a must pass-through layer for all pkts. in &
>> out.
>
> No - Check Point's product works at a higher level than netfilter, in
> my  opinion.   They are both OSI layer 3/4 filtering systems, however
> netfilter  is built into the Operating System kernel, whereas
> Firewall-1 is added on top  of the Operating System as an application.
>  There is, for example, no  inherent packet filtering in the Windows 2k
> kernel, yet once you put  Firewall-1 on top, it becomes a firewall.
>
> I would say that for this question netfilter is more secure because it
> is  embedded in the kernel; Firewall-1 is an application which could
> get stopped.
>
>> 3- It securely supports typical " loop-hole prone protocols such as
>> FTP, UDP & RPC protocols.
>
> What do you mean by "loop-hole prone" ?   FTP is well supported by
> netfilter  and is no less secure than Firewall-1's support for it.
>
> I don't know what you mean by UDP in this context, however I do not
> believe  there is any difference between the security of netfilter vs
> Firewall-1 for  UDP protocols.
>
> RPC is an application-level protocol (usually classified as OSI layer
> 5) and  both netfilter and Firewall-1 are stateful inspection packet
> filters.    Again, I do not believe there is any difference between the
> security of  netfilter vs Firewall-1 for RPC.
>
>> No, I am not here to brag about checkpoint. I hardly know the thing.
>
> Where have you got your information suggesting that Firewall-1 is
> better ?
>
>> I use a IPTables firewall. I need some info /web sites on how the
>> Iptables modules work.. yeah the inner workings. Can some one help
>> pls. ?
>
> If you want to see how netfilter works inside, the source code is
> readily  available, and you can really see how everything gets done.
> You won't get  *that* opportunity with Firewall-1,
>
> Check Point Firewall-1 does not have a flawless security record.   Did
> you  know, for example, that until FW-1 v4.1 (about 2 years ago) every
> version of  FW-1 allowed access from the Internet to any machine on the
> internal network  on TCP/UDP ports 53 under a standard installation ?
>
> Netfilter does not have a flawless security record either, but like
> most open  source projects, the flaws tend to get found sooner in the
> development cycle,  and they certainly get fixed pretty damned fast if
> they ever get out into a  released vesion, compared to commercial /
> proprietary systems.
>
> I wuld be very interested in any reproducible data you have comparing
> the  security of Check Point Firewall-1 with netfilter.
>
> Antony.
>
> --
>
> In science, one tries to tell people
> in such a way as to be understood by everyone
> something that no-one ever knew before.
>
> In poetry, it is the exact opposite.
>
> - Paul Dirac




Regards,

Cyberdude Murli
The Earth

Re: inner workings of IP tables

[Antony Stone]

On Sunday 29 September 2002 8:05 pm, Mitesh P Choksi wrote:

[ Comparing netfilter with Checkpoint Firewall-1 ]

> What about ease of use? The GUI

There are many netfilter-based firewall products available with a GUI 
interface.   Not all of them tell you they're based on netfilter, but many do.

Checkpoint sell a two-day training course for around $5000 to teach people 
how to use their GUI (I have done it, and their system is not obvious if you 
don't do the training course).   Many of the netfilter products with GUIs are 
available for less money than the Check Point training course, never mind the 
CP product licence...

Anyway, the points you raised in your previous email, which I answered, were 
about the security of the product, not how pretty it looked.

> Multiple firewalls.

Again that is not a security question, this one is about reliability of 
equipment.   If you want fault-tolerance and automatic-failover then 
netfilter isn't the answer, but that doesn't mean it's any less secure.

> Management of firewalls.

What about it ?   If you know Firewall-1 then you can manage a FW-1 
installation.   If you know netfilter then you can manage a netfilter 
installation.   Swap jobs and you're in trouble either way.

> Delegation of firewalls and types of rules.

Either this is the same point as you made above about GUIs, or else you're 
suggesting you can't load the same ruleset onto two netfilter boxes and get 
them to do the same thing ?

Most people require one ruleset on one firewall.   I do know companies who 
have mutliple firewalls and want to manage them centrally, sometimes using a 
single ruleset (which doesn't actually necessarily make things any easier) 
however these are the minority and therefore they have to choose a product 
with specialised features.

> I believe that CheckPoint has the level of application along with that
> allows all of hte above. For Netfilter you have to build on top of it.

You are correct - Firewall-1 does include all the above features.   However, 
various commercial organisations *have* built them to varying degrees on top 
of netfilter, and if you don't mind paying for a product (and a lot less than 
Check Point charge) you can buy one of those and get the benefits.

> We can't compare apples to oranges.

Indeed.   I thought we were talking about the security performance of the 
products, based on the questions you raised earlier.

If you're happy that both products do just as good a job at the security 
level, and now you're comparing them for their management aspects, then yes 
they are different.

> CheckPoint goes a bit beyond packet filtering on the user
> interaction / commercial side of it.

Agreed.   And just as well considering what they charge for it.   However, as 
I say there are many commercially-available firewalls based around netfilter 
which add the features you seem to be looking for.

You can't criticise a car engine built by General Motors because it doesn't 
have as nice a dashboard as a Rolls-Royce car: you should find a car which 
contains that engine and then compare the dashboards.

Antony.

-- 

Documentation is like sex:
when it's good, it's very very good;
when it's bad, it's still better than nothing.

Re: inner workings of IP tables

[Kevin Dwyer]

Sorry to barge in, but included are some comments I thought must be made.

On Sun, 29 Sep 2002, Antony Stone transmitted the following:

> On Sunday 29 September 2002 8:05 pm, Mitesh P Choksi wrote:
>
> [ Comparing netfilter with Checkpoint Firewall-1 ]
>
> > What about ease of use? The GUI

http://www.fwbuilder.org
(which incidentally generates rulesets for iptables, pf, and ipfilter)

Not that a GUI makes a good firewall.  Aren't you pretty much dead in the
water with checkpoint if you don't have access to their GUI?  I know you
can fw load policies, and possibly even compile them via CLI, but I
challenge you to make competent ruleset changes with vi on checkpoint.

> > Multiple firewalls.

http://www.linux-ha.org
http://w3.arobas.net/~jetienne/vrrpd/
(and more, peep the linux-ha site for a huge list of resources)

Netfilter doesn't have the code to pass the state table across machines
(and would be a neat feature) but you can make a firewall pair by either
using VRRPd or Linux-HA.  You'll drop active connections, but CP did too
up until recently I think.

> > Management of firewalls.

..is made more difficult with their reliance on a GUI, IMO.

..is made more difficult with their licensing schemes.

..is made more difficult when CP support says: Sorry, the only solution to
esoteric bug #48129 is to upgrade to the newest version.  Sorry, the only
solution to esoteric bug #48130 is to downgrade to the previous version.
(as the clock counts the downtime)

..is made more difficult when you upgrade the GUI and magically things
like Manual IPSEC (and who knows what else) disappear.


/* Kevin Dwyer                                Allegiance Internet */
/* network security engineer                   Commerce Center II */
/* email: Kevin.Dwyer@algx.net                7601 Ora Glen Drive */
/* phone: 240-616-2075                        Greenbelt, MD 20770 */
/*      >++++++++++[<++++++++++>-]<.+++++.----.[-]++++++++++.     */

Re: inner workings of IP tables

[Antony Stone]

On Monday 30 September 2002 12:37 am, Kevin Dwyer wrote:

> Sorry to barge in, but included are some comments I thought must be made.

No problem - it's a public mailing list :-)

> Not that a GUI makes a good firewall.  Aren't you pretty much dead in the
> water with checkpoint if you don't have access to their GUI?  I know you
> can fw load policies, and possibly even compile them via CLI, but I
> challenge you to make competent ruleset changes with vi on checkpoint.

Yes, and the choice of platforms for the GUI is much smaller than for the 
firewall product itself.   FW-1 runs (to my knowledge, possibly more now) on 
Windows, Solaris, RH Linux and Nokia IPSO.   The GUI runs on Windows.

Okay, there *is* a version of the GUI for Solaris, but it's horrible, and is 
missing quite a number of the features of the version they want you to 
use.....

> Netfilter doesn't have the code to pass the state table across machines
> (and would be a neat feature) but you can make a firewall pair by either
> using VRRPd or Linux-HA.  You'll drop active connections, but CP did too
> up until recently I think.

No, I think CP FW-1 has pretty much had state table synchronisation for as 
long as they've been supporting things like Stonebeat and VRRP to provide the 
failover.   They've certainly had it for the past 5 years.

> > > Management of firewalls.
>
> ..is made more difficult with their reliance on a GUI, IMO.

Hmmm.   It looks easier and gives you "point-and-click" (over)confidence, but 
I agree that if you lose the GUI, you're stuffed.

> ..is made more difficult with their licensing schemes.

Pay them enough $$$ and you get an unlimited licence, full VPN, decent 
encryption.   I'd prefer to use netfilter and spend the money on a house.

> ..is made more difficult when you upgrade the GUI and magically things
> like Manual IPSEC (and who knows what else) disappear.

Hmmm.   I haven't seen that, but then I haven't played with FWng.   As you 
say, though, with a GUI-based product you're at the vendor's mercy how easy 
they make it for you to get at different parts and set things the way you 
want.   At least with a CLI you're in full control, even if you need to learn 
a bit more syntax before you start typing.

Antony.

-- 

Abandon hope, all ye who enter here.
You'll feel much better about things once you do.

Re: inner workings of IP tables

[Kevin Dwyer]

On Mon, 30 Sep 2002, Antony Stone transmitted the following:

> Okay, there *is* a version of the GUI for Solaris, but it's horrible, and is
> missing quite a number of the features of the version they want you to
> use.....

I have used it myself, and they did a half-assed port of it to Solaris
using the WindU stuff.  Plus, I was informed that if you want the latest
GUI you need to drop some *extra* cash, whereas the Windows GUI is
included.

> No, I think CP FW-1 has pretty much had state table synchronisation for as
> long as they've been supporting things like Stonebeat and VRRP to provide the
> failover.   They've certainly had it for the past 5 years.

It's possible that I hadn't seen it _work_, and mistook it as not being
present. ;)

> > ..is made more difficult when you upgrade the GUI and magically things
> > like Manual IPSEC (and who knows what else) disappear.
>
> Hmmm.   I haven't seen that, but then I haven't played with FWng.

It was a bug that popped up while upgrading the GUI to handle clusters or
something. (I was only cursorily involved so I don't know the specifics)

> At least with a CLI you're in full control, even if you need to learn
> a bit more syntax before you start typing.

Precisely.
This is seen as a drawback to some people, because you are given the gun
with which to shoot yourself in the foot.  However, I'd prefer to have a
competent firewall admin over a point-and-click lemming.


/* Kevin Dwyer                                Allegiance Internet */
/* network security engineer                   Commerce Center II */
/* email: Kevin.Dwyer@algx.net                7601 Ora Glen Drive */
/* phone: 240-616-2075                        Greenbelt, MD 20770 */
/*      >++++++++++[<++++++++++>-]<.+++++.----.[-]++++++++++.     */

Re: inner workings of IP tables

[Vadim Kurland]

Kevin Dwyer wrote:

>>At least with a CLI you're in full control, even if you need to learn
>>a bit more syntax before you start typing.
>>    
>>
>
>Precisely.
>This is seen as a drawback to some people, because you are given the gun
>with which to shoot yourself in the foot.  However, I'd prefer to have a
>competent firewall admin over a point-and-click lemming.
>
>  
>

I would like to assert that in the case of CLI we are just as like in 
the mercy of a vendor who may or may not implement interfaces to certain 
features of underlying software. I prefer to think of these components 
as layers of different level of abstraction and access: first, there is 
TCP/IP stack, then a set of hooks and kernel functions, then perhaps a 
CLI tool to configure this stuff and on top of that may be a GUI. This 
is rough and inaccurate model which I have here just to explain my 
point. Each level needs to be implemented and while doing so certain 
features of underlying levels may get dropped by various reasons.

Cluefullness of firewall administrator has almost nothing to do with a 
type of user interface firewall he prefers to use. Like we never saw 
wrong firewall configurations done in iptables, or in ipfilter, or PIX 
using their CLI. In the end, what matters is how much time one needs to 
spend building rules and verifying them, and what is the proprability of 
an error still slipping through. Anything that can help reduce this 
probablility is useful, even if it is a GUI.

Another reason is this: what if you have a staff and need several 
engineers to be able to work on the same policy at different times? 
Again, anything that can make this policy look uniform and 
understandable is useful.

I agree that interface does induce certain model and makes us think of a 
subject in a certain way... That is of course true and choice of good 
unterface, both CLI and a GUI, is a difficult task. But this is a 
different interesting topic, which can be far more scientific that 
religious war of CLI versus GUI.

--vk

Re: inner workings of IP tables

[Kevin Dwyer]

Hi Vadim ;)

On Sun, 29 Sep 2002, Vadim Kurland transmitted the following:

> Kevin Dwyer wrote:
>
> >>At least with a CLI you're in full control, even if you need to learn
> >>a bit more syntax before you start typing.
> >>
> >>
> >
> >Precisely.
> >This is seen as a drawback to some people, because you are given the gun
> >with which to shoot yourself in the foot.  However, I'd prefer to have a
> >competent firewall admin over a point-and-click lemming.

Just wanted to say that I should have said "point-and-click CP lemming,"
as I think fwbuilder is really a fine piece of code, or else I probably
wouldn't have submitted any patches.  ;)

> I would like to assert that in the case of CLI we are just as like in
> the mercy of a vendor who may or may not implement interfaces to certain
> features of underlying software.

I think you're right, with the exception that the CLI in question here is
usually a shell (unless someone has built their own thing on top of it --
I'm only referring to netfilter as it is distributed freely) and usually
has a text editor available, which gives you the means to adequately
modify any ruleset without needing a graphical workstation, given you are
familiar with typical unix commands (which you ought to be if you are
going to be administering a netfilter firewall).

In fact, one of the great thing about tools like fwbuilder is that it
spits out comprehensible text, which can be edited in a pinch.

So if you do use a GUI like fwbuilder for generating rules, you get the
advantage of a visibly clear ruleset and damage control when you're
partying in Hawai'i but the boss calls unexpectedly saying they need a
special quick fix change implemented.  This is not the case with the CP
GUI, as experience has shown.  It's the _option_ that I find most
appealing, I suppose.


> Cluefullness of firewall administrator has almost nothing to do with a
> type of user interface firewall he prefers to use. Like we never saw
> wrong firewall configurations done in iptables, or in ipfilter, or PIX
> using their CLI. In the end, what matters is how much time one needs to
> spend building rules and verifying them, and what is the proprability of
> an error still slipping through. Anything that can help reduce this
> probablility is useful, even if it is a GUI.

Again, I didn't mean to, though I certainly did, imply that GUI user ==
dumb user.  I think there are GUIs that make dumb users, however.



/* Kevin Dwyer                                Allegiance Internet */
/* network security engineer                   Commerce Center II */
/* email: Kevin.Dwyer@algx.net                7601 Ora Glen Drive */
/* phone: 240-616-2075                        Greenbelt, MD 20770 */
/*      >++++++++++[<++++++++++>-]<.+++++.----.[-]++++++++++.     */

Re: inner workings of IP tables

[Antony Stone]

On Monday 30 September 2002 2:21 pm, Kevin Dwyer wrote:

> > Cluefullness of firewall administrator has almost nothing to do with a
> > type of user interface firewall he prefers to use. Like we never saw
> > wrong firewall configurations done in iptables, or in ipfilter, or PIX
> > using their CLI. In the end, what matters is how much time one needs to
> > spend building rules and verifying them, and what is the proprability of
> > an error still slipping through. Anything that can help reduce this
> > probablility is useful, even if it is a GUI.
>
> Again, I didn't mean to, though I certainly did, imply that GUI user ==
> dumb user.  I think there are GUIs that make dumb users, however.

I agree with these sentiments.   The best way I can express it is that dumb 
users will go for a GUI because they think they can get to use it quicker 
than learning a CLI.

Users who know what they're doing will use the right tool for the job at the 
time.

Antony.

-- 

Perfection in design is achieved not when there is nothing left to add,
but rather when there is nothing left to take away.

 - Antoine de Saint-Exupery

Re: inner workings of IP tables

[Vadim Kurland]

Kevin Dwyer wrote:

>>    
>>
>I think you're right, with the exception that the CLI in question here is
>usually a shell (unless someone has built their own thing on top of it --
>I'm only referring to netfilter as it is distributed freely) and usually
>has a text editor available, which gives you the means to adequately
>modify any ruleset without needing a graphical workstation, given you are
>familiar with typical unix commands (which you ought to be if you are
>going to be administering a netfilter firewall).
>  
>

I see. I meant the set of command line options for "iptables", which is 
CLI in this case. Even someone who is very good at shell, vi etc. may 
have no idea about relationship between chains and tables, not to 
mention modules and their parameters. Firewall administrator thinks in 
terms of addresses, packets and protocols, but CLI in this case exposes 
details which are too low-level. This makes learning curve longer, which 
increases the risk.

>So if you do use a GUI like fwbuilder for generating rules, you get the
>advantage of a visibly clear ruleset and damage control when you're
>partying in Hawai'i but the boss calls unexpectedly saying they need a
>special quick fix change implemented.  This is not the case with the CP
>GUI, as experience has shown.  It's the _option_ that I find most
>appealing, I suppose.
>  
>

I do agree very much here. My goal is to find a fine balance between 
high level of abstraction and ease of use of the GUI and maximum control 
that experienced administrators want.

--vk

Re: inner workings of IP tables

[Matthew G. Marsh]

On Sun, 29 Sep 2002, Kevin Dwyer wrote:

> Sorry to barge in, but included are some comments I thought must be made.

Ditto.

> On Sun, 29 Sep 2002, Antony Stone transmitted the following:
>
> > On Sunday 29 September 2002 8:05 pm, Mitesh P Choksi wrote:
> >
> > [ Comparing netfilter with Checkpoint Firewall-1 ]
> >
> > > What about ease of use? The GUI
>
> http://www.fwbuilder.org
> (which incidentally generates rulesets for iptables, pf, and ipfilter)
>
> Not that a GUI makes a good firewall.  Aren't you pretty much dead in the
> water with checkpoint if you don't have access to their GUI?  I know you
> can fw load policies, and possibly even compile them via CLI, but I
> challenge you to make competent ruleset changes with vi on checkpoint.

Hehehehe - BD3 (been dere done dat) and it is actually fairly easy.
There are three main ascii files you need to know about but it is pretty
much the same as scripting iptables. You have Objects that are acted upon
by Rules. Of course you end up defining first the object then the rule in
different files. But I have written up perl scripts to do this for
specific setups (back on 4.1 when I needed a Time limited setup I had a
cron job that would change the rulesets from businesshours to
nonbusinesshours)

In fact once you get used to NetFilter/IPTables especially in a scripting
environment you can actually make better sense out of the CP structure. Of
course I only use(d) CP on Solaris where I had SSH access. I remember when
they decided that I should not have access to the GUI because that was the
FW Admin's job. Funny part is he never did notice all the special rules I
implemented (hint - there is a way in the command files to declare rules
as implicit and also as internal ~= hidden)

> > > Multiple firewalls.
>
> http://www.linux-ha.org
> http://w3.arobas.net/~jetienne/vrrpd/
> (and more, peep the linux-ha site for a huge list of resources)
>
> Netfilter doesn't have the code to pass the state table across machines
> (and would be a neat feature) but you can make a firewall pair by either
> using VRRPd or Linux-HA.  You'll drop active connections, but CP did too
> up until recently I think.

Still pretty much does even in NG. At least under real testing (ie: unplug
the one box in the setup)...

> > > Management of firewalls.
>
> ..is made more difficult with their reliance on a GUI, IMO.
>
> ..is made more difficult with their licensing schemes.

YES!

> ..is made more difficult when CP support says: Sorry, the only solution to
> esoteric bug #48129 is to upgrade to the newest version.  Sorry, the only
> solution to esoteric bug #48130 is to downgrade to the previous version.
> (as the clock counts the downtime)

Hehehehehe - yep.

> ..is made more difficult when you upgrade the GUI and magically things
> like Manual IPSEC (and who knows what else) disappear.

Or even better - you now have a bunch of defined Objects which you CANNOT
change except by manually deleting them from the file... sigh.

> /* Kevin Dwyer                                Allegiance Internet */
> /* network security engineer                   Commerce Center II */
> /* email: Kevin.Dwyer@algx.net                7601 Ora Glen Drive */
> /* phone: 240-616-2075                        Greenbelt, MD 20770 */
> /*      >++++++++++[<++++++++++>-]<.+++++.----.[-]++++++++++.     */

--------------------------------------------------
Matthew G. Marsh,  President
Paktronix Systems LLC
1506 North 59th Street
Omaha  NE  68104
Phone: (402) 932-7250 x101
Email: mgm@paktronix.com
WWW:  http://www.paktronix.com
--------------------------------------------------

Re: inner workings of IP tables

[Julian Gomez]

On Sun, 29 Sep 2002, Kevin Dwyer wrote:

> http://www.linux-ha.org
> http://w3.arobas.net/~jetienne/vrrpd/
> (and more, peep the linux-ha site for a huge list of resources)
>
> Netfilter doesn't have the code to pass the state table across
> machines (and would be a neat feature) but you can make a firewall
> pair by either using VRRPd or Linux-HA.  You'll drop active
> connections, but CP did too up until recently I think.

I _think_ PIX still has the option for either failover. With state and
without state depending on what you're willing to lose and how much $$$
you're willing to shell out :)

(snip rest)