[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Firewall Public IP's?



In article <[🔎] 1018539247.3cb5acef8ec6d@heritage.sd57.bc.ca> 
megglestone@heritage.sd57.bc.ca writes:
>But for some reason, boss wants to keep the public IP's 
>assigned to all the workstations.
>Its a basic Class C network with around 200 workstations
>and a few servers, printers etc etc.

Unlike most of the respondents, I've actually put a debian woody
box in to firewall a /24 without having to reconfigure the other
boxes.  It only needs a single IP address, unless you are also
using it as a dhcp server, which will require a seperate address in
the /24 for each interface that has both dhcp and that /24 due to
a bug in the dhcp server design.

My configuration:
PIII/1.1 Ghz, 256 M ram, 7 10/100 Ethernet interfaces 
(buit-in, two dual, two single, two open pci)
Incoming internet feed is a T3 over 100baseFX
We have 10 24port 10/100 managed switches with 1000baseSX connections between
them and some other misc.  (SMC switches are good, Linksys never worked right)
Users are split into 6 Vlans.
One vlan is nat.
A few users are outside of the firewall, because they still run IPX to
systems outside of our control.

The routing table on the firewall is complex, since I didn't renumber the
systems.  Fortunatly, no other system has to worry about this due to proxy
arp.  If possible, group your users in nice consecutive IP addresses
starting on clean powers of two.

Iptables requires the 2.4 kernel.  2.4.18 is what I'm using.

The system seems to be overkill, but it was easier to overspec than
have it be overloaded and fail.

Apply my arpwatch patch if you have more than a couple of interfaces
with users.

iptstate may eventually be usable, but right now it's a broken toy, even
with all the patches I put on it.

I mostly ignore the conventual configuration, and control all the details
with the ip command.

The cisco router on the incoming feed has long arp timeouts.  I did
manage to get them to reset the table when most of the users moved
over.

I've been planning to write this up, but at least this summery tells you
that this has been done.



-- 
To UNSUBSCRIBE, email to debian-firewall-request@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org



Reply to: