On Sun, 2004-01-25 at 00:22, David Demland wrote:
> First, all networks must have a router at their edge. On the other side of
> the public IP are all the private IPs. It is unreasonable to have all IPs on
> the network public IPs. Since this means that there will be two networks,
> the public and the private, coming together, then by definition there must
> be a router. This is because a router bridges two networks. Since a router
> works on this level, layer 3 of the OSI model, it makes it a good place to
> implement a firewall as well as routing. This gives an added level of
> security protection. I have also heard this router referred to as an Âedge
> routerÂ. This too makes since because the router is at the edge of the
> private network. This is a common configuration with every network that I
> have every worked on.
>
> The word Bastion comes from the French work Bastille which means to fortify.
> The actual context means to have two lines coming from the main foreclosure
> in the front and two lines at each of the flanks. It is a term that has been
> used for defense and security. Since this term has been traditionally been
> used for two levels of defense it is well replicated in networks by having
> two levels defense. This is where the second router/firewall comes in.
> Putting a router/firewall behind the edge router now gives a second level of
> security. It also creates a true DMZ in that the systems in the DMZ are all
> truly not part of the internal, or external, network. The following is a
> picture that shows the setup:
>
> +--------+ Public IP +------+ DMZ +--------+ Private Network
> |Internet|---------->|Router|----->|Firewall|---------------->
> +--------+ +------+ +--------+
>
> This design also gets us an extra level of security, which is always good
> when protecting a network.
>
> What makes this a very interesting situation is if the outside world needs
> to talk to a system on the private network. What this means is that the edge
> router needs to forward the request to the router/firewall, then the
> router/firewall needs to covert this request to the proper server IP on the
> internal network and pass it to the right server. All of this should be
> rather straight forward. But I have ran into a small problem I am not sure
> how to implement.
>
> I have the edge router configured to pass the request to the
> router/firewall. This was not hard to do. The router takes any request on a
> certain port and forwards that request to a DMZ network address. In this
> case that is 10.0.0.253. The route/firewall is a Sparc 5 running Debian 2.2
> on it. The goal is to get the route/firewall to change this request from the
> DMZ address to the proper IP of the server on the internal network. My
> thought was that I would need to do some masquerading or forwarding. The
> only way I could think of doing this was to create an IP alias for the
> 10.0.0.253 on the NIC that services the DMZ. This works in that the request
> are passed from the router to the router/firewall. The problem this that the
> request is not coverted and passed to internal network. My reading shows
> that forwarding only works to the IP of the interface assigned to the NIC.
> This creates a problem since the internal router rules will send this
> request right back to the NIC on the router/firewall.
>
> I have tried everything to get this system to work, but I have been unable
> to get the requested coverted and passed to the internal network IP. Since I
> am trying to do nothing more than forward information to a different IP I
> only need to know how to covert one IP to a different one with ipchains.
> This should be a simle NAT but I have been unalbe to implement it.
>
> I am also locked into ipchains because, what the Debian SPARC list has said,
> is that the only stable kernel for the Sparc 5 is the 2.2 kernel right now.
> Since this is a production box I can not run the risk of not having
> something stable.
>
> I hope this gives a more complete picture of what I am doing so someone
> might be able to at least put me on the right track.
----
I read through all of this and it's difficult to decipher - routing
ain't as difficult as you make it to be.
One thing I am gathering and you need to get clear on this.
A NIC has but one real ip address. You can alias all the ip addresses
that you want. The only 'forwarding' or NAT (SNAT or DNAT) that I have
ever seen done is via the NIC's real ip address. Alias ip addresses
don't work for forwarding, only as endpoints. Somebody may claim to have
done it but I've never seen it done. What I typically do in these
instances is simply throw in another NIC (lemme see, cheap network card,
real IP address, easy to forward / NAT vs excrutiatingly difficult if
not impossible to accomplish via aliased ip addresses, yep, the add
another NIC seems to be the idea).
If you have say a web server that you are using with virtual hosts and
virtual ip addresses, this permits direct dns resolved access and apache
server and end user are happy - things work. If you plan to forward or
NAT via a virtual IP (an aliased ip address), you are embarking upon a
futile trail.
Your new ascii drawing and picture still leave me shivering about your
concept of what constitutes a DMZ - my drawing would have the design
more like...
-------- | -------- --------- ---------
|public |--|public | |public | |private |
| router| | router| | or | | ip |
| | | | |private| | |
-------- -------- --------- ---------
| | | |
| ------------- |
|------------------------------------|
The router that creates the DMZ zone - handling the traffic for a server
or servers in the public or private ip space cannot allow those servers
to create a connection into the private LAN space for any reason -
authentication, data store, forwarding mail or whatever. Once that is
permitted, it ceases to be a DMZ.
What you are doing is putting two routers between your network and the
internet. This may not be necessary as my picture would suggest if you
have 2 public ip addresses, you can have a real DMZ and probably a much
easier time routing things.
Craig
(text/plain)