Re: [vox-tech] before i go...
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [vox-tech] before i go...
- Subject: Re: [vox-tech] before i go...
- From: Ted Deppner <ted@psMAPSyber.com>
- Date: Fri, 13 Oct 2000 18:21:33 -0700
- References: Pine.LNX.4.21.0010130922260.2910-100000@satan
On Fri, Oct 13, 2000 at 09:29:40AM -0700, Peter Jay Salzman wrote:
> i just compiled 2.4.0. very impressive! unfortunately, it's starting to
> look like dselect. i'd say they increased config options by about 50%. it
> took quite awhile to go through everything. if you use 'make oldconfig',
> have a cup of coffee at your side; it'll take a while!
It's all good as far as I'm concerned. Every current "feature" of every
firewall type product is implimented _properly_ in 2.4.0. The industry as
a whole will have to take notice. (this includes Cisco's PIX firewall,
ATM's QoS, etc, etc).
> there are some very interesting and innovative new options. one of them
> talks about being able to update firmware on your CPU. sounds really cool,
> but i'm not sure if i'm interpreting this correctly. can you "flash" the
> CPU the way you can a bios chip? i've never heard of such a thing; doesn't
> seem possible.
Intel chips have flashable microcode. It is not a widely known item, and
usually you can't obtain the flasher or code unless you are a big reseller
That said, I read this section as support for BIOS flash and other types
of flashable things...
> ipchains has been replaced by netfilter, although you have the option of
> continuing to use ipchains. i recommend people to keep ipchains for now.
> there are some tricky configuration issues involved. for example, if you
Ugh. This is FUD. The ipchains support in 2.4 will likely be phased out
later in the 2.4 series (essentially). It is antiquated, hard to
configure, and the new netfilter package just roasts it to char.
With ipchains you had only one set of chains (INPUT, FORWARD, OUTPUT), and
each packet passed through each of them, and your resulting configuration
grew terribly complex. With netfilter, you have multiple "tables" of
chains, and they are more correctly implimented.
The "filter" table has INPUT, FORWARD, and OUTPUT. INPUT is packets from
the outside world INPUT to the local machine. FORWARD are those packets
that would be possibly forwarded (from external to external). OUTPUT are
those packets locally generated being sent.
Thus, rather than having to qualify what you will forward in your INPUT,
FORWARD, and OUTPUT chains with ipchains, you simply add what you'll
forward to your FORWARD chain in netfilter. SIMPLE. Your FORWARD entries
do not affect or require any matching stuff in your INPUT table. *very*
Activating NAT and MASQUERADING are equally simply, and are not a kludge
like ipchains required. There is a whole table (the "nat" table strangely
enough), with the following chains: PREROUTING, POSTROUTING, and OUTPUT.
PREROUTING allows you to change destination addresses & ports (destination
NAT), POSTROUTING allows source address & port NATting, and MASQUERADE.
(don't remember what output is).
Did I mention that with 2.4.0 and netfilter that NAT actually works? That
Microsofts VPN (and all GRE based ip tunneling) is NATtable and
MASQUERADable? With no extraneous patches or kludged up handling?
I've a friend who comes over with his laptop, which is configured for
internal to HP LAN access. I've provided him with the same default
gateway and subnet he sees when at HP. I've also MASQUERADEd his outbound
traffic to the outside world, while leaving him directly routed to the
rest of my home LAN. I've also NATted his DNS requests which go to
internal to HP DNS servers onto the ip addresses of my providers' DNS
machines. Simple. This config takes about 10 lines (6 lines for the DNS
server NATting alone). Oh, and I block all his laptop's Windows netbios
broadcasts, etc, so that HP's gateways don't see rogue packets from my
> say to "fast switching", packets can bypass the netfilter. i'm sure stuff
> like that will change as people start to complain...
This has always been the case. Fast switching allows bus mastering NIC
cards to do direct memory copies between their buffers... the packet never
enters the kernel memory space.
> one last thing -- i noticed that 'make oldconfig' didn't work perfectly.
It's best with a major new series to do a "make mrproper" and configure it
cleanly. make oldconfig is only intended for minor upgrades.
Pete, thanks for taking the time to write this up for the group... I
really appreciate that. I've been running 2.4 for about 2 months and have
three production machines operating without any problems. I'm too busy at
the moment to organize my thoughts coherantly... spreading the good news
about 2.4.0 is something I'd been hoping to find time for.