How to establish connections to the servers inside a DMZ?

Discussion in 'Linux Networking' started by buck, Jan 29, 2005.

  1. buck

    buck Guest

    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
    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):
    | | | |
    proxy nntp demo http

    Any help, examples and ideas will be sincerely appreciated.

    buck, Jan 29, 2005
    1. Advertisements

  2. 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. :cool:>

    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.

    Alternatively, try :

    Michael W Cocke, Jan 29, 2005
    1. Advertisements

  3. buck

    chud Guest

    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
    chud, Jan 30, 2005
  4. buck

    buck Guest


    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

    buck, Jan 30, 2005
  5. buck

    prg Guest

    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
    The GW/firewall can shape traffic going to the dmz. See here for
    various scripts, tutorials, etc.:

    See especially:
    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
    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.
    See above... and:
    Most common, standard setup is to have the GW/firewall with 3 nics --
    eg., eth0 to ISP, eth1 to dmz, eth2 to (private) LAN.
    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?
    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).
    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

    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.
    email above disabled
    prg, Jan 30, 2005
  6. 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.

    Michael W Cocke, Jan 30, 2005
  7. buck

    buck Guest

    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

    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 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, Jan 31, 2005
  8. buck

    prg Guest

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

    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).
    .. The one above is commercial.

    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.
    email above disabled
    prg, Jan 31, 2005
  9. buck

    buck Guest

    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:

    buck, Feb 2, 2005
  10. buck

    prg Guest

    prg, Feb 3, 2005
  11. buck

    buck Guest

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

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

    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

    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.

    WAN (DSL) <--->ethernet switch<-->four computers

    WAN <--> Router <--> ethernet switch <--> four computers

    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.):
    # /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
    NWI="206.###.89.152/29" # unused
    NMI="" # unused
    NS="206.###.89.158/32" # unused

    # Setup:
    ifconfig lo
    route add -net netmask lo
    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!
    # 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 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 UH 0 0
    0 eth0
    206.###.89.155 UH 0 0
    0 eth0
    206.###.89.153 UH 0 0
    0 eth1
    206.###.89.156 UH 0 0
    0 eth0
    206.###.89.157 UH 0 0
    0 eth0 U 0 0
    0 lo 206.###.89.153 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
    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
    RX packets:472954 errors:0 dropped:0 overruns:0 frame:0
    TX packets:443399 errors:150 dropped:0 overruns:0
    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: Mask:
    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

    Raymond Ingles for ostiary:

    Emilio Grimaldo for chklogs:

    Nelson Murilo for chklogs:


    Here is my HTB + ESFQ QoS script. If you decide to use this,
    'fromdos' it first.

    Bob Sully: The firewall is based on his work.

    Here is my firewall script. fromdos it.

    "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

    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, Feb 19, 2005
    1. Advertisements

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments (here). After that, you can post your question and our members will help you out.