Hi Paul,
Paul E Condon wrote:
> I'm lurking here, looking to better understand a problem that I've never
had to confront: NAT, I understand requires translation tables, one entry
for each active tcp connection. This takes RAM. It also takes enough
CPU cycles to maintain this table --- set up new connections and find
and delete old connections that are no longer in use. I can see a number
of reasons why the old router would have to quit and need resetting.
I wonder if one of the uplist suggestions which was to set up an old
computer as a router might not work unless the hardware is powerful
enough to keep up with the heavy maintenance activity on the NAT tables.
Extra RMA also implies extra cpu cycles to find and remove old table
entries. It might be that for this service, a somewhat heavy duty
computer is needed.
As others have mentioned, RAM and CPU are the biggest issues. And yes a
PC is likely to use more power, however I think some newer PCs would be
ideal -- those using low power CPUs, any of those will likely have
enough memory too.
So, a cheap headless box that is power efficient with ample CPU and RAM
would be a better choice. Bridge the modem and let the headless box
login via PPPoE. Make sure the cheap box is running an x86 chip though,
don't go with an ARM or ARMEL one as that will limit your options.
My choice of firewall is IPCop, it wins over Smoothwall options due to
be "really free". Smoothwall has limitations depending on version.
IPCop is long overdue for a major upgrade, but the team is working on
that. Having said that, the current release version of IPCop works very
well and there are a great many very happy users. I also suggest to
keep it as a firewall and don't be tempted to bolt on extras from third
parties.
A cheap, lower power, headless NEW machine will likely not cost too much
when compared to other options. Although you need to make sure you have
"enough" network connections available -- one for RED (Internet), one
for GREEN (trusted LAN).
Splitting networks and having multiple GREEN networks is more of an
issue, but it can be done. Two IPCop boxes working each with their own
public IP could be an option if the cable provider will supply two
public IPs to use. There is no point going too far down this track if
the ISP won't play ball to start with though.
Having said all that, many around here would be using a Debian box as
their firewall. That might be the way to go, then you can choose from
more architecture (ARMEL for instance). But if you want a good
replacement for the current situation without too much work, then IPCop
is well worth looking into, but it will be better to use an x86 based
CPU. IPCop is optimized [and hardened by design] for it's job, a Debian
install won't be, unless it is specifically a variant that is meant for
firewall duties with appropriate hardening.
Coming from me, the above is little more than idle speculation. I'd be
interested in reading your comments on this speculation. Does it make
any sense? How might OP go about specifying hardware that doesn't
need resetting in his environment? Would it be likely that some
'industrial strength' routers meet his needs, and others are really
expensive over kill? Would the appropriate industrial grade router be
a bigger/smaller energy hog than something cobbled together out of an
old computer and junk box network cards? Or compare to new consumer
suitably sized for the job?
An older clunker machine will use more power, for sure, but a newer
low-power machine would be much more efficient. At one stage I kept a
few PIIIs around because they were much less power hungry than P4 CPUs.
Anything from Core 2 Duo onwards is going to be more efficient, but an
Intel based low power CPU should be fine.
Whatever you have time to write will be interesting to me and
might be really useful to OP.
Thanks.
--
Kind Regards
AndrewM
Andrew McGlashan
Broadband Solutions now including VoIP
--
To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/4dafa99d.3030...@affinityvision.com.au