Very Computer

We have a block of IPs and there is a mixture of operating systems
connected to them.  Each server is assigned one of those IPs.

We want to create a [ firewall / DMZ / whatever you wanna call it ]
Linux machine that passes the allowable packets to and from  those
computers in such a way that the external IP determines which host
(inside the DMZ) is accessed.  

We hope that the DMZ machine can allocate bandwidth to the internal
computers in such a way that no single internal machine hoggs the
whole connection.  It must be the firewall.

The problem we are attempting to address right now is how to get the
DMZ machine to listen to all the external IPs and to pass the packets
on to the correct internal server.  One of the internal computers
presently serves as a transparent proxy for all our internet access.
The rest are specialized, eg: an NNTP server, an internet demo machine
and an HTTP server.

How do we allow internet connections to each server?

What keywords should I use in a google search?

How many NICs does the DMZ computer need?  Is there anything special
about assigning IPs to them?

What we have tried:
ifconfig eth1:0 IP1
ifconfig eth1:1 IP2
Etc.
SNAT these with the FORWARD chain set to ACCEPT.

But although the DMZ can "talk" to the internet and to the internal
computers, the internal computers cannot talk to the internet.  They
can talk to the DMZ but no packets get forwarded.

DIAGRAM as currently (MIS)configured (I hope this displays correctly):
        ETHERNET DSL
                    |
                 dmz
                    |
    ETHERNET SWITCH
    |          |          |          |
proxy   nntp   demo   http

Any help, examples and ideas will be sincerely appreciated.

buck

Looking thru your plan, I don't see why you need a real DMZ.  Load
balancing is relatively straightforward - see wondershaper.  You can
route web requests thru a firewall/proxy without using a dedicated
DMZ.  Ditto mail and so on, but I admit I just skimmed your plan - I'm
supposed to be writing a rebuild plan of my own for one of my clients
right now. 8-)>

Take a look thru here - it's written for the mid-level geek. This
guide is faily specific to shorewall, but it should give you the idea.
http://www.shorewall.net/three-interface.htm

Alternatively, try :

http://lartc.org/
http://linux-ip.net/html/routing-intro.html

Mike-

--
Mornings:  Evolution in action.  Only the grumpy will survive.
--

Please note - Due to the intense volume of spam, we have installed site-wide spam
 filters at catherders.com.  If email from you bounces, try non-HTML, non-encoded,
non-attachments.

sounds like your proxy server is misconfigured, or the firewall on your
"dmz" machine is blocking packets to and/or from the proxy server. Or
both.

The GW/firewall is distinct/separate from a dmz.  the first acts as a
(packet filtering) router to forward traffic to the subnet of the dmz
(just a subnet of hosts/servers exposed to public access).

The "allowable" packets will be determined by iptables rules.
Directing packets to the dmz is accomplished with route table entries.
Your ISP is responisible for forwarding your public IP packets to your
connection(s).

Quote:> We hope that the DMZ machine can allocate bandwidth to the internal
> computers in such a way that no single internal machine hoggs the
> whole connection.  It must be the firewall.

The GW/firewall can shape traffic going to the dmz.  See here for
various scripts, tutorials, etc.:
http://www.veryComputer.com/

See especially: http://www.veryComputer.com/

Quote:> The problem we are attempting to address right now is how to get the
> DMZ machine to listen to all the external IPs and to pass the packets
> on to the correct internal server.  One of the internal computers
> presently serves as a transparent proxy for all our internet access.
> The rest are specialized, eg: an NNTP server, an internet demo
machine
> and an HTTP server.

Since your proxy is internal, it has no public IP.  Therefore the
GW/firewall will need to NAT its traffic more than likely.  Proxy
servers usually placed in the dmz or on the GW/firewall and sometimes
just upstream of the GW/firewall so that it will have its own public
IP.  Can depend on the proxy you are using.  Looked at Squid?

What does your internal proxy do?  Just NAT?  If so, you don't need it
with iptables -- you would be NATing at proxy, then NATing the proxy
NATs at the GW/firewall most likely.  Again, depends on proxy, your
setup, and what you need.  You may not need the internal proxy any
longer.

Quote:> How do we allow internet connections to each server?

With iptables you would ALLOW based on dst address (incoming SYN
packets) and use connection tracking and ESTABLIHED, NEW to maintain
packet state.  You also need proper route table entries to forward
packets headed for the public IP dmz.

Quote:> What keywords should I use in a google search?

See above... and:
http://www.veryComputer.com/

Quote:> How many NICs does the DMZ computer need?  Is there anything special
> about assigning IPs to them?

Most common, standard setup is to have the GW/firewall with 3 nics --
eg., eth0 to ISP, eth1 to dmz, eth2 to (private) LAN.

Quote:> What we have tried:
> ifconfig eth1:0 IP1
> ifconfig eth1:1 IP2
> Etc.
> SNAT these with the FORWARD chain set to ACCEPT.

You should not need this IP aliasing.  Proper route tables will forward
the packets to the correct nic, which will place the packets on the
correct subnet, where properly configured servers are listening on
proper ports.

To filter packets additionally will depend on what you're looking to
do.  Shape?  Rate limit?  Contol "outside" access?  Which one(s) of
hundreds of other possibilities?

Quote:> But although the DMZ can "talk" to the internet and to the internal
> computers, the internal computers cannot talk to the internet.  They
> can talk to the DMZ but no packets get forwarded.

You will need to check each interface config and route table, look out
for host firewalls, use traceroute for clues, check the arp cache, note
reachability errors, etc.

Get ethereal to sniff the packets on the wire -- often required to get
a precise picture of what's going on/wrong.  Of course, you need to
understand what the packets are telling you, but it's not _that_ hard.
Will likely save you days of "diagnosing" the problem source(s).

Quote:> DIAGRAM as currently (MIS)configured (I hope this displays
correctly):
>.         ETHERNET DSL
>.              |
>.             dmz
>.              |
>.     -----ETHERNET SWITCH-------
>.     |    |      |      |      |
>. proxy   nntp   demo   http

More usual layout like this:
.
.            ISP
.             |
.        GW/firewall
.       |           |
.       |          LAN
.     dmz

There are several ways to get the LAN hosts properly talking to dmz
hosts.  How you do it will depend on what you want to achieve, what you
_understand_, what you can _maintain_.  My idea of how to do it is
likely much different from yours as I'm more familiar with IP routing
and netfilter/iptables firewall rules.  Start simple, DENY everything
coming in by default, then open "paths" or "holes" in firewall to let
traffic pass, use connection tracking with ESTABLISED, NEW connections
to speed and control packet traversal, use shaping to control bandwidth
usage.

Hire someone to set it up/explain it to you -- quite advisable if your
knowledge of routing/packet filtering and network design is not up to
*with the number/kind of services you are exposing to the public.
hth,
prg
email above disabled

WOW!  Thank you for that.  I can tell you spent a non-trivial amount
of time to give me some help and I sincerely appreciate it.

One thing I'm not getting, though, is that if I don't alias the
external interface, what in the world is going to make the GW/firewall
"hear" packets sent to 206.###.89.154 through .157 when its IP is
206.###.89.158?!

For example, when a user asks for HTTP, (s)he connects to .154.  When
asking for NNTP, the connection is to .155.  The demo connects to
.157.  The domain name entered by the user must contain
SERVER.DOMAIN.com in order to interact with the correct server.

ASIDE:  Ordinarily I'd snip most of this, but I think that the context
here is important enough to keep for a while.
--
buck

echo 1 > /proc/sys/net/ipv4/ip_forward
Set ip_forward=yes (or true or 1) in your distro's networking config
file to make it "permanent".

This makes this Linux box a router rather than just a leaf
host/destination.

Quote:> For example, when a user asks for HTTP, (s)he connects to .154.  When
> asking for NNTP, the connection is to .155.  The demo connects to
> .157.  The domain name entered by the user must contain
> SERVER.DOMAIN.com in order to interact with the correct server.

The routing table tells where (which nic) to forward the packet.  Once
it's out the router onto the correct segment/subnet, it's up to the
server to listen and respond to packets directed to it.

Only you can decide just how to set up a GW/firewall layout.  The one I
gave you is the _most_ basic and is often not the best/most secure
setup.  With as many services as you propose to run you might want to
consider something a bit more sophisticated.

You are also going to have to contend with stipping down your servers
to the minimum required to provide service.  Not just no extra running
daemons, not even extra software on the machine's disk.  Each needs to
be made a "bastion" host that has been hardened against attack.

The GW/firewall should similarly be trimmed of all excess software.

Unfortunately, I'm not aware of any one-stop descriptions of how to set
up such a design in detail.  A couple of general approaches are
available.

http://www.linuxexposed.com/internal.php?op=modload&name=News&file=ar...
http://www.linuxexposed.com/internal.php?op=modload&name=News&file=index
Just a couple of "easier" to understand alternatives.

Add to that, you mentioned wanting to perform traffic shaping to
maintain bandwidth control.  Out-of-the-box tools are not user friendly
for the uninitiated.  There are some tools include in some GW/firewall
packages.

You should probably start with a "floppy" Linux router/firewall distro
that will make configuring easier.  Boo-boos here could be "not fun".
Along the way you will gain some knowledge and experience with Linux
networking tools and may later decide to DIY (at least in part).

http://www.freesco.org/?L=overview
http://www.viperlair.com/articles/soft_guide/networking/lnx_fw_1.shtml
http://www.shorewall.net/
http://www.smoothwall.org/
http://www.astaro.com/firewall_network_security/security_facts
.  The one above is commercial.

Google:
http://www.google.com/search?num=50&hl=en&lr=lang_en&ie=ISO-8859-1&q=...
Other terms should occur to you as you see which ones are most relevant
to your questions.

If your assets (internal LAN and external servers) are quite valuable
in any sense, then you really should pony up $ and have someone help
you get set up.  Pick a layout/design that you understand and can
maintain afterwards.  Your knowledge will grow as your needs
grow/change.  Simply "properly" maintaining a good design may tax your
present knoledge as config changes and software upgrades proceed.
hth,
prg
email above disabled

For future readers:
The above answer is Just Plain Wrong.  ip_forward allows packets to be
sent to other interfaces on _this box_ only.  It has no effect on what
packets the immediate next hop sends to the external interface; that
is the job of ARP.  See Oskar Andreasson's ipsysctl-tutorial:
http://ipsysctl-tutorial.frozentux.net/ipsysctl-tutorial.html#AEN263

buck

The above answer did not say otherwise -- you misinterpreted my
meaning.  Nor was it intended to be taken as complete or without
reference to previous posts.  I've overestimated your knowledge of IP
(thought you could fill in the blanks and I was too harried this week
to wish otherwise) and your determination to make a DIY setup work.
Sorry for adding to your confusion -- my fault.

Your problem relates to getting the ISP interface to respond correctly
to the arp requests trying to locate the MAC associated with the dst IP
so that a proper frame may be built (Who has?).

As I said there are several ways to go about that -- aliases on the ISP
interface are possible but present big problems re: your other goals
like shaping and firewall rules that will get more complicated than
"just the usual".  They don't work with aliases as a rule.

There are other, peculiar to Linux, sorts of problems also.  Add to
that the fact that I've no idea how your ISP is handling things
upstream, or how your dsl modem/router needs to be configured (if at
all), or how many IPs you have in your block.  With as many services as
you want to run I assumed you have at least 6 (/29 - very tight for
subnetting) or 14 (/28 - which would be enough), but who knows.

I was suggesting that _you_ subnet your IPs further.  I did not make
that clear and you did not pick up on it.  My fault.  This setup can
also present problems for the uninitiated.  See this explanation (much
better than I can provide):
http://www.shorewall.net/shorewall_setup_guide.htm#Routed

Your best bet is to get a firewall package that you can be comfortable
with and effectively use.  With some experience from using it you will
gain knolwledge for a later DIY project or customization.

Smoothwall and others have already been mentioned.  Google for the
hundreds of other possible candidates, like:
http://www.fwbuilder.org/

If you can't find a firewall-in-a package that suits you, here are some
more docs that may help.
http://www.sjdjweis.com/linux/proxyarp/
http://www.maths.leeds.ac.uk/~read/iproute2.doc.html#ss9.2

If your interests in the details remain, get some good books on IP
routing.  The remainder shelf usually can provide some -- or used via
Amazon.  Cisco offers about as good a one-stop site for downloadable
info as any:
http://www.cisco.com/univercd/cc/td/doc/cisintwk/ito_doc/index.htm
http://www.cisco.com/univercd/cc/td/doc/cisintwk/idg4/index.htm

Digest some of this and the RFCs make good sense.

Again, sorry for any hair pulling, thumb smashing, and shouted
indignities aimed at the gods and me (well, at least I deserved some).
good luck,
prg
email above disabled

I am posting my solution for Deja and Google.  Perhaps this will
assist someone else.

PRELIMINARIES:
I built a new box (we'll call it ROUTER here) out of spare parts:  AMD
K6 233 CPU, 2.8 (approx) gig Maxtor 90288D2 HD, 192 megs RAM and 3
NICs; 3c905B (eth0), DLink (tulip) eth1 and (after everything was
running which we'll get to later) Realtek (8139too) eth2.  The AMD K6
233 was a mistake; this setup needs a minimum CPU more like a 500.  It
never uses any swap but it too often is at 90+% CPU utilization.

On Router, installed Slackware 10.0.  The only services that are
running are (in 'ps xa' order) portmap, inetd, sshd, crond, ostiaryd,
axfrdns and tinydns.

Downloaded the 2.4.29 kernel source, iptables 1.3.0 +
patch-o-matic-ng-20050119, iproute2-2.6.10 and ostiary-1.81b.  Also
the daemontools + djbdns + ucspi-tcp stuff for axfrdns + tinydns (but
not dnscache).

Downloaded esfq-0.2 and hacked it so it builds (and runs!) in
iproute2-2.6.10.  Posted that hack to the LARTC mailing list.

Downloaded patch-2.4.29-ja1.diff from http://www.ssi.bg/~ja/ because
we are getting an additional DSL connection next week and the patch
helps with multipath routing.

For completeness here:  downloaded chklogs-2.0-3 and chkrootkit-0.44.

THE PROBLEM:
In the original setup, any one of the 4 boxes connected to the /29 DSL
WAN could use all the bandwidth and each had to have its own firewall.
There was no way to use more than one ISP without (IMO) unreasonable
complexity.

THE GOAL:
Insert a box ("Router") that listens to all WAN connections, then
firewalls, then forwards the remaining packets to an ethernet switch
where the 4 original boxes connect. It should go without saying that
packets outbound must also be correctly handled.  In bridging /
forwarding, Router needs to fairly allocate bandwidth ("QoS") while
not changing the IP address.

ORIGINAL TOPOLOGY:
WAN (DSL) <--->ethernet switch<-->four computers

CURRENT TOPOLOGY:
WAN <--> Router <--> ethernet switch <--> four computers

MY SOLUTION:
I needed a way for Router to listen to all 5 of the IP addresses on
the /29 DSL side, firewall, then forward the remaining packets on to
the 4 computers.  I chose to use proxyARP, mainly because it is the
most transparent way to accomplish this.  Also, should Router die, I
can just reconnect everything the way it was originally and it will
continue to work.  HTB + ESFQ handle the QoS issues, and because
Router is between the WAN and the switch, it can run HTB effectively
on both eth1 (external facing) and eth0 (internal facing), controlling
both upload and download bandwidth.  Note that this proxyARP setup
sets both eth1 and eth0 up with the same IP and netmask.  Yes, that
does work.

FILES (Beware line wrap!)

(rc.inet1 is disabled.  rc.proxyarp replaces it):
/etc/rc.d/rc.proxyarp (called from rc.M.):
#!/bin/bash
# /etc/rc.d/rc.proxyarp - Ethernet setup script for Router
echo "rc.proxyarp:  "

# testing
# set -x
# echo -n "rc.proxyarp:  "    >>/tmp/errors

# definitions
NIC0="3c59x"          # eth0 ---> Belkin switch
# eth0 is the internal interface
#NIC1="8139too"               # eth1 ---> DSL
NIC1="tulip"          # eth1 ---> DSL
IFI="eth0"
IFE="eth1"
IPNS="206.###.89.158"
NWI="206.###.89.152/29"               # unused
NMI="255.255.255.248"         # unused
GW="206.###.89.153"
BRD="206.###.89.159"
YIC="206.###.89.154/32"
NEWS="206.###.89.155/32"
SON="206.###.89.156/32"
NOP="206.###.89.157/32"
NS="206.###.89.158/32"                # unused

# Setup:
    ifconfig lo 127.0.0.1
    route add -net 127.0.0.0 netmask 255.0.0.0 lo
    /etc/rc.d/rc.netdevice
    ip link set dev $IFE up
    ip address add dev $IFE local $IPNS/32 broadcast $BRD
    ip link set dev $IFI up
    ip address add dev $IFI local $IPNS/32 broadcast $BRD

    ip route add $YIC  dev $IFI src $IPNS
    ip route add $NEWS dev $IFI src $IPNS
    ip route add $SON  dev $IFI src $IPNS
    ip route add $NOP  dev $IFI src $IPNS
    ip route add $GW/32 dev $IFE src $IPNS
    ip route add 0/0 via $GW dev $IFE src $IPNS

# we want proxyARP:
  echo 1 >/proc/sys/net/ipv4/conf/$IFE/proxy_arp
  echo 1 >/proc/sys/net/ipv4/conf/$IFI/proxy_arp

# turn on ip forwarding
  echo 1 >/proc/sys/net/ipv4/ip_forward

# Re rp_filter:  I have decided to leave it off
# turn on antispoofing protection
# for f in /proc/sys/net/ipv4/conf/*/rp_filter; do echo 1 >$f; done
# Shields Up!
  /usr/sbin/firewall.sh
# fi
# EOF /etc/rc.d/rc.proxyarp

Here's 'ip route':
206.###.89.154 dev eth0  scope link  src 206.###.89.158
206.###.89.155 dev eth0  scope link  src 206.###.89.158
206.###.89.153 dev eth1  scope link  src 206.###.89.158
206.###.89.156 dev eth0  scope link  src 206.###.89.158
206.###.89.157 dev eth0  scope link  src 206.###.89.158
127.0.0.0/8 dev lo  scope link
default via 206.###.89.153 dev eth1  src 206.###.89.158

Here's 'route -n':
Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref
Use Iface
206.###.89.154   0.0.0.0         255.255.255.255 UH    0      0
0 eth0
206.###.89.155   0.0.0.0         255.255.255.255 UH    0      0
0 eth0
206.###.89.153   0.0.0.0         255.255.255.255 UH    0      0
0 eth1
206.###.89.156   0.0.0.0         255.255.255.255 UH    0      0
0 eth0
206.###.89.157   0.0.0.0         255.255.255.255 UH    0      0
0 eth0
127.0.0.0       0.0.0.0         255.0.0.0       U     0      0
0 lo
0.0.0.0         206.###.89.153   0.0.0.0         UG    0      0
0 eth1

Here's 'ifconfig':
eth0      Link encap:Ethernet  HWaddr 00:10:5A:11:00:A6  
          inet addr:206.###.89.158  Bcast:206.###.89.159
Mask:255.255.255.255
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:443500 errors:0 dropped:0 overruns:0 frame:0
          TX packets:461429 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000
          RX bytes:339376967 (323.6 Mb)  TX bytes:452749889 (431.7 Mb)
          Interrupt:9 Base address:0xe800

eth1      Link encap:Ethernet  HWaddr 00:4F:4E:00:CC:83  
          inet addr:206.###.89.158  Bcast:206.###.89.159
Mask:255.255.255.255
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:472954 errors:0 dropped:0 overruns:0 frame:0
          TX packets:443399 errors:150 dropped:0 overruns:0
carrier:150
          collisions:2265 txqueuelen:1000
          RX bytes:453245578 (432.2 Mb)  TX bytes:338576759 (322.8 Mb)
          Interrupt:10 Base address:0x7000

lo        Link encap:Local Loopback  
          inet addr:127.0.0.1  Mask:255.0.0.0
          UP LOOPBACK RUNNING  MTU:16436  Metric:1
          RX packets:390 errors:0 dropped:0 overruns:0 frame:0
          TX packets:390 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:0
          RX bytes:33712 (32.9 Kb)  TX bytes:33712 (32.9 Kb)

Note for those who say "it doesn't work".  Yes, it does work.
However, when I first plugged in the Cat5, I waited ~45 minutes and
never once got an "ARP who has" for any of the 5 external IPs.
Gratituous ARPs were ignored, so I called the ISP and requested they
flush their ARP cache.  Within 5 minutes this setup was functional.

Credits, Etc.:
To all those responsible for the links above, thank you!

Blars Blarson.  You can't get there from here, so here is where I got
the basic setup for rc.proxyarp  http://andthatsjazz.org:8/sapaf.html

Raymond Ingles for ostiary:  http://ingles.homeunix.org/software/ost/

Emilio Grimaldo for chklogs:
http://home.iae.nl/users/grimaldo/chklogs.shtml

Nelson Murilo for chklogs: http://www.chkrootkit.org/

LARTC: http://lartc.org/

Here is my HTB + ESFQ QoS script.  If you decide to use this,
'fromdos' it first.
ftp://andthatsjazz.org/pub/lartc/ultimate.sh.tar.gz

Bob Sully: The firewall is based on his work.
http://www.malibyte.net/iptables/scripts/fwscripts.html

Here is my firewall script.  fromdos it.
ftp://andthatsjazz.org/pub/lartc/firewall.sh.tar.gz

"Thank you" to those who made suggestions in comp.os.linux.networking.
You'll see them as part of this thread.  "I'm sorry!" to anyone
missed.

FUTURE:
Next week a second DSL will be installed, so I'll have another
adventure setting up for load balancing and load sharing.  That is why
the Realtek NIC is installed but not up.  (Anyone want to give me a
good Intel or SMC NIC <grin>?)
--
buck