How to establish connections to the servers inside a DMZ?

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

On Sat, 29 Jan 2005 10:20:49 -0800, buck <(E-Mail Removed)> wrote:

>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.

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.

On Sat, 29 Jan 2005 10:20:49 -0800, buck wrote:


> 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.
>
>
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.

Michael W Cocke <(E-Mail Removed)> wrote in
news:(E-Mail Removed):

> 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-

Mike,

The shorewall docs are superb. Thank you. I don't know why I ignored
shorewall in my searches <shrug>.

Based on what the shorewall docs describe, "DMZ" is not an appropriate
term; they use "firewall". That's what we want. Looks as if
arping -U -I eth1 206.###.89.153
may be the trick we've been looking for. Shorewall's docs are very well
done but we will need to spend more time reading them in order to
understand.

buck

buck wrote:
> 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.

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).

> 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.linuxguruz.com/iptables/

See especially: http://lartc.org/wondershaper/

> 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.

> 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.

> What keywords should I use in a google search?

See above... and:
http://iptables-tutorial.frozentux.n...-tutorial.html

> 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.

> 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?

> 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).

> 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
snuff with the number/kind of services you are exposing to the public.
hth,
prg
email above disabled

On 30 Jan 2005 11:16:44 -0800, buck <(E-Mail Removed)> wrote:

>Michael W Cocke <(E-Mail Removed)> wrote in
>news:(E-Mail Removed) :
>
>> 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-
>
>Mike,
>
>The shorewall docs are superb. Thank you. I don't know why I ignored
>shorewall in my searches <shrug>.
>
>Based on what the shorewall docs describe, "DMZ" is not an appropriate
>term; they use "firewall". That's what we want. Looks as if
>arping -U -I eth1 206.###.89.153
>may be the trick we've been looking for. Shorewall's docs are very well
>done but we will need to spend more time reading them in order to
>understand.
>
>buck

I've been using shorewall ever since I switched from OS/2 for my
firewall. I've got to say, as a compromise position between bare
iptables and getting the job done without having to take a degree in
network engineering, it's really the best I've ever found - I don't
know why it's not more popular.

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.

On 30 Jan 2005 11:22:55 -0800, "prg" <(E-Mail Removed)> wrote:

>
>buck wrote:
>> 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.
>
>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).
>
>> 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.linuxguruz.com/iptables/
>
>See especially: http://lartc.org/wondershaper/
>
>> 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.
>
>> 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.
>
>> What keywords should I use in a google search?
>
>See above... and:
>http://iptables-tutorial.frozentux.n...-tutorial.html
>
>> 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.
>
>> 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?
>
>> 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).
>
>> 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
>snuff 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

buck wrote:
> On 30 Jan 2005 11:22:55 -0800, "prg" <(E-Mail Removed)> wrote:
>
[snip]
> 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?!

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.

> 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...rticle&sid=493
http://www.linuxexposed.com/internal...ews&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/so...lnx_fw_1.shtml
http://www.shorewall.net/
http://www.smoothwall.org/
http://www.astaro.com/firewall_netwo...security_facts
.. The one above is commercial.

Google:
http://www.google.com/search?num=50&...nux+router+dmz
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

On 31 Jan 2005 14:25:18 -0800, "prg" <(E-Mail Removed)> wrote:

>buck wrote:
>> On 30 Jan 2005 11:22:55 -0800, "prg" <(E-Mail Removed)> wrote:
>>
>[snip]
>> 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?!
>
>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.

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.n...al.html#AEN263

buck

buck wrote:
> On 31 Jan 2005 14:25:18 -0800, "prg" <(E-Mail Removed)> wrote:
>
> >buck wrote:
> >> On 30 Jan 2005 11:22:55 -0800, "prg" <(E-Mail Removed)>
wrote:
> >>
> >[snip]
> >> 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?!
> >
> >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.
>
> 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.n...al.html#AEN263

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_s...ide.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/i...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/index.htm
http://www.cisco.com/univercd/cc/td/...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