Very Computer

I know this has been asked and answered before, but I can't get mine
working.
I have a three box set up like this:

  ~~~~~~~
(     Public   )
(  Network  )
  ~~~~~~~
         |
real.ip.address
  /---------\        /---------\         /---------\
  |  Box A  |        |  Box B  |         |  Box C  |
  |  Router  |        |  Linux   |         |   Linux   |
  \---------/        \---------/         \---------/
192.168.1.1     192.168.1.2     192.168.1.3
          |                       |                       |
/---------------------------------------------\
|                                Hub                              |
\---------------------------------------------/

1. All three boxes are running linux. Box A is using IPCHAINS to
masquerade.
2. All three boxes can ping each other.
3. Box A has no problem using dns servers for name lookup.
4. Box B and Box C seem unable to do dns lookups.
5. Box B and Box C can ping the outside world if they use IP addresses.
6. All three boxes have identical etc/resolv.conf files.
7. Implicit in #5 above, but stated separately for clarity, Box B and
Box C have Box A as the configured gateway.
8. There is only one rule in the forward chain on Box A, and it doesn't
filter by protocol:
    ipchains -A forward -i eth0 -s 192.168.1.0/24 -j MASQ
    where eth0 is the public interface.
9. None of the input and output rules are specific to protocol or port.
10. The primary and secondary DNS servers reside outside the private
network.

Now for the questions...
Why isn't DNS working on Box B and Box C?
How do I get it working?

Any help would be appreciated.

||  I know this has been asked and answered before, but I can't get mine
||  working.
||  I have a three box set up like this:
||
||    ~~~~~~~
||  (     Public   )
||  (  Network  )
||    ~~~~~~~
||           |
||  real.ip.address
||    /---------\        /---------\         /---------\
||    |  Box A  |        |  Box B  |         |  Box C  |
||    |  Router  |        |  Linux   |         |   Linux   |
||    \---------/        \---------/         \---------/
||  192.168.1.1     192.168.1.2     192.168.1.3
||            |                       |                       |
||  /---------------------------------------------\
||  |                                Hub                              |
||  \---------------------------------------------/

Oh dear.  Please use a fixed width font for ascii art.  It's the only
sane choice.  This is looking horrible.

||  1. All three boxes are running linux. Box A is using IPCHAINS to
||  masquerade.
||  2. All three boxes can ping each other.
||  3. Box A has no problem using dns servers for name lookup.
||  4. Box B and Box C seem unable to do dns lookups.
||  5. Box B and Box C can ping the outside world if they use IP addresses.
||  6. All three boxes have identical etc/resolv.conf files.
||  7. Implicit in #5 above, but stated separately for clarity, Box B and
||  Box C have Box A as the configured gateway.
||  8. There is only one rule in the forward chain on Box A, and it doesn't
||  filter by protocol:
||      ipchains -A forward -i eth0 -s 192.168.1.0/24 -j MASQ
||      where eth0 is the public interface.

But the kernel masquerading code looks at the protocol.

||  9. None of the input and output rules are specific to protocol or port.
||  10. The primary and secondary DNS servers reside outside the private
||  network.
||
||  Now for the questions...
||  Why isn't DNS working on Box B and Box C?

Probably box A isn't masquerading DNS traffic (properly).

||  How do I get it working?

Enable DNS masquerading (port 53), surely this must be possible, but I
don't know masquerading that well.

Otherwise, install a nameserver (caching-only or otherwise) on box A,
and point your resolv.conf there.

Ciao.                                                         Vincent.
--

"Xhost should be taken out and shot."                          Vincent Zweije

To be honest, Sean, I've never set this up (using linux) but reading through
what you've done it seems to me that their is no rule to forward the
information back to the private boxes.  Have you captured any packets to see
if the dns requests are getting out and coming back to eth0?

intersweat

Quote:> I know this has been asked and answered before, but I can't get mine
> working.
> I have a three box set up like this:

>   ~~~~~~~
> (     Public   )
> (  Network  )
>   ~~~~~~~
>          |
> real.ip.address
>   /---------\        /---------\         /---------\
>   |  Box A  |        |  Box B  |         |  Box C  |
>   |  Router  |        |  Linux   |         |   Linux   |
>   \---------/        \---------/         \---------/
> 192.168.1.1     192.168.1.2     192.168.1.3
>           |                       |                       |
> /---------------------------------------------\
> |                                Hub                              |
> \---------------------------------------------/

> 1. All three boxes are running linux. Box A is using IPCHAINS to
> masquerade.
> 2. All three boxes can ping each other.
> 3. Box A has no problem using dns servers for name lookup.
> 4. Box B and Box C seem unable to do dns lookups.
> 5. Box B and Box C can ping the outside world if they use IP addresses.
> 6. All three boxes have identical etc/resolv.conf files.
> 7. Implicit in #5 above, but stated separately for clarity, Box B and
> Box C have Box A as the configured gateway.
> 8. There is only one rule in the forward chain on Box A, and it doesn't
> filter by protocol:
>     ipchains -A forward -i eth0 -s 192.168.1.0/24 -j MASQ
>     where eth0 is the public interface.
> 9. None of the input and output rules are specific to protocol or port.
> 10. The primary and secondary DNS servers reside outside the private
> network.

> Now for the questions...
> Why isn't DNS working on Box B and Box C?
> How do I get it working?

> Any help would be appreciated.

I have not, but I know that ping is passing out and back in again. If it works
for ping traffic, it should work for DNS traffic, right? I don't have any rules
specific to either ping or DNS, so what works for one should work for the other.

what about the DNS settings in box B and C!!!! set anything?

Have you put the ISP's (?) DNS server Ip addresses in the
/etc/resolv.conf file on each of the internal network computers?

It sounds like all the internal network computers have the gateway set
properly, 192.168.1.1.  Also, the gateway computer seems to have MASQ
set up OK, quite often the step to activate
/proc/sys/net/ipv4/ip_forward is forgotten, and the proper modules
seem to be cmpiled in and loaded.

From my experience the thing missing looks to be /etc/resolv.conf.

Good luck and I hope this helps!

 ------------------------------------------------
   Doug Mitton - Brockville, Ontario, Canada
                 'City of the Thousand Islands'

          http://www.*tap.com/dmitton
         Other: mitton.dyndns.org
   SPAM Reduction: Remove "x." from my domain.
 ------------------------------------------------

3. Box A has no problem using dns servers for name lookup.
6. All three boxes have identical etc/resolv.conf files.

Quote:> From my experience the thing missing looks to be /etc/resolv.conf.

> Good luck and I hope this helps!

3. Box A has no problem using dns servers for name lookup.
6. All three boxes have identical etc/resolv.conf files.

Fraid not,  DNS defaults to udp so no connection is established on the
gateway to send the answers back to the requestor.  One could port forward
to a specific machine but only that machine would work.  A caching DNS works
well though.

In other words, when UDP traffic is sent out, it gets masq'ed just fine, except
that IPCHAINS doesn't make a record in the MASQed table; so when the DNS server
sends traffic back, IPCHAINS doesn't have a table entry to know how to unmask
it. Is that the problem?

I really didn't want to run a caching DNS, because that's just one more service
to run on a box that I want as thin (and secure) as possible.

Sean, I can see you are getting no where with this fast.

I use the identical setup and never had and problems with outside DNS.
I do however use someones pre-configured script to run IPCHAINS - it
must have something in it to resolve this issue.  I use the script form
http://firewall.langistix.com/ , they are superb and judging from the
few tests I've run against it very tight. I am afraid I don't understand
IPCHAINS that well to advise otherwise.

Secondly another alternative to a DNS caching server is to use a DNS
PROXY, the one I use is DNRD from http://members.home.com/garsh/dnrd/ .
 It is simple as typing dnrd -s isp.dns.add.ress  (once compiled on the
system).  It is a single execuatable - one other benefit is that it can
do local DNS too - derived from the servers hosts file. THat way you can
ping and use resources by name froma DNS source.  While this may not
seem like such a big deal on such a small lan the benefits are that
something like Netscape that tries to get something over the web when
access is down won't bomb out. It is also a lot less work and less cpu
intensive than a full blown caching DNS server. There are other DNS
proxies, search at freshmeat if you want to try something else. Be sure
to set the b and c boxes dns to your gateways IP.

Hope this helps.

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

Sent via Deja.com http://www.deja.com/
Before you buy.

OK, I remember this was very discouraging when I tried to get it to
go.  If you aren't sure you should get the appropriate How-To (I can't
put my hands on it right now) but the important things are:
1) Proper kernel options/modules for masq
2) Proper ipchains for masq
3) Turn on ip-forward in /proc
4) Have the local and internet interfaces properly configured
5) You do not need a local DNS server, I have been running a masq
setup for quite some time and I use my ISP's DNS from internal Win98
and linux machines as well as Linux on the masq machine.

Just to really clutter this up here is my MASQ configuration that I
execute in /etc/rc.d/rc.local to get my system to work.  (Sorry for
the line wrapping.)

-----------------------------<cut here>-------------------------------
echo "Start syn_cookies protection in proc ... "
echo 1 >/proc/sys/net/ipv4/tcp_syncookies
#
if [ -x /sbin/ipchains ]; then
        echo "Start masquerade so that local network PCs can access
outside."
        # Flush all existing rules - for safety!
        /sbin/ipchains -F forward
        # Set the timeout values ... from a UseNet post!
        /sbin/ipchains -M -S 7200 10 60
        # Set default forwarding policy to DENY; this I am confused
about.
        #  This apparently protects my system from another host
masquerading as ME!
        /sbin/ipchains -P forward DENY
        # Allow the local network to firewall/masquerade to anywhere.
        /sbin/ipchains -A forward -j MASQ -s 192.168.10.0/24 -i ppp0
        echo 1 >/proc/sys/net/ipv4/ip_forward

        echo "Block some ports required for the internal BUT not
external network."
        /sbin/ipchains -A input -i ppp0 -p tcp --dport 37 -j DENY
        /sbin/ipchains -A input -i ppp0 -p tcp --dport 137 -j DENY
        /sbin/ipchains -A input -i ppp0 -p tcp --dport 138 -j DENY
        /sbin/ipchains -A input -i ppp0 -p tcp --dport 139 -j DENY
        /sbin/ipchains -A input -i ppp0 -p tcp --dport 143 -j DENY
        /sbin/ipchains -A input -i ppp0 -p tcp --dport 513 -j DENY
        /sbin/ipchains -A input -i ppp0 -p tcp --dport 514 -j DENY
        /sbin/ipchains -A input -i ppp0 -p tcp --dport 515 -j DENY
        #
        /sbin/ipchains -A input -i ppp0 -p tcp --dport 110 -j DENY
        /sbin/ipchains -A input -i ppp0 -p tcp --dport 143 -j DENY
        /sbin/ipchains -A input -i ppp0 -p tcp --dport 1026 -j DENY
        /sbin/ipchains -A input -i ppp0 -p tcp --dport 6000 -j DENY
        #
        /sbin/ipchains -A input -i ppp0 -p udp --dport 37 -j DENY
        /sbin/ipchains -A input -i ppp0 -p udp --dport 137 -j DENY
        /sbin/ipchains -A input -i ppp0 -p udp --dport 138 -j DENY
        /sbin/ipchains -A input -i ppp0 -p udp --dport 139 -j DENY
        /sbin/ipchains -A input -i ppp0 -p udp --dport 143 -j DENY
        /sbin/ipchains -A input -i ppp0 -p udp --dport 513 -j DENY
        /sbin/ipchains -A input -i ppp0 -p udp --dport 514 -j DENY
        /sbin/ipchains -A input -i ppp0 -p udp --dport 515 -j DENY
        #
        /sbin/ipchains -A input -i ppp0 -p udp --dport 110 -j DENY
        /sbin/ipchains -A input -i ppp0 -p udp --dport 143 -j DENY
        /sbin/ipchains -A input -i ppp0 -p udp --dport 1026 -j DENY
        /sbin/ipchains -A input -i ppp0 -p udp --dport 6000 -j DENY
fi
-----------------------------<cut here>-------------------------------

 ------------------------------------------------
   Doug Mitton - Brockville, Ontario, Canada
                 'City of the Thousand Islands'

          http://www.*tap.com/dmitton
         Other: mitton.dyndns.org
   SPAM Reduction: Remove "x." from my domain.
 ------------------------------------------------

perhaps have a look on the linux-mag.com 's 98 Aug magazine would
help!!!

i made a mistake on the last message!
sorry should be 1999 Aug 's magazine!

What it all boiled down to was a bad route.
Redhat 6.2 automatically set up a default gateway for the internal NIC on
the router.
So I had a default gateway for eth0 (the external NIC) that went to a host
on the public network,
and another default gateway for eth1 (the internal NIC) that went to the
same host on the public network.
I just deleted the default gateway for eht1 and things worked fine.