Re: How to establish connections to the servers inside a DMZ?
From: buck (buck_at_private.mil)
Date: 01/31/05
- Next message: Juha Laiho: "Re: firewall using iptables DHCP IP may change?"
- Previous message: Steffen Koepf: "iptables/SNAT not working"
- In reply to: prg: "Re: How to establish connections to the servers inside a DMZ?"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Date: Mon, 31 Jan 2005 10:02:33 -0800
On 30 Jan 2005 11:22:55 -0800, "prg" <rdgentry1@cablelynx.com> 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.net/iptables-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
- Next message: Juha Laiho: "Re: firewall using iptables DHCP IP may change?"
- Previous message: Steffen Koepf: "iptables/SNAT not working"
- In reply to: prg: "Re: How to establish connections to the servers inside a DMZ?"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Relevant Pages
|
