firewall subnets -- reorganizing question
okay. this may of course be a linux question as opposed to a
debian-specific question, but several of my components are
debian, and y'all are knowledgeable and helpful types--
i moved my server from the local subnet (192.168.1.*) to its own
lan (192.168.0.*) for security purposes, and now i can't get dns
service from it. ssh and http work fine, tho. aaugh!
i've got a firewall (ipcop) between me (browsing from the green
interface) and the web (on the red interface). i've been doing a
no-no in having my webserver behind the green interface; with
port-forwarding most visitors to my address aren't likely to
know they're routed to a behind-the-scenes internal ip -- but
badness could occur if there's a breakin there; the rest of the
internal net could be in jeopardy.
note that the server serves http:80, ssh:22, *and* dns:53.
old insecure setup:
web *.*.*.*
|
==+========
11.22.33.44 [red interface]
firewall
192.168.1.5 [green interface]
==+========
|
[hub]---192.168.1.1 [debian server]
| \
| \=============
| 192.168.1.2
| debian client
| =============
|
==+==========
192.168.1.100
mac client
=============
now i'm trying to move to the orange demilitarized zone concept:
web *.*.*.*
|
==+==============================+
11.22.33.44 [red] |
firewall [orange] 192.168.0.5 +----192.168.0.1 [debian server]
192.168.1.5 [green] |
==+==============================+
|
[hub]
| \
| \=============
| 192.168.1.2
| debian client
| =============
|
==+==========
192.168.1.100
mac client
=============
so now the server has a new ip (zero dot one, instead of one
dot one).
i changed port-forwarding settings on the firewall to point to
the new address; and external dns and http requests get through
as expected. i also updated my clients (mac and linux) to use
192.168.0.1 as primary dns...
internally i can point a browser (on .1.2, say) to
192.168.0.1:80 and i get the apache server as expected; but for
the life of me i cannot figure out why the dns won't work...
on 192.168.1.2 (debian client) i set /etc/resolv.conf to point
to 192.168.0.1 which answers properly to ssh and to http
requests (which go through the firewall -- in via the green
interface, out via the orange).
not knowing what better tool there might be for the job, i try
"iptraf -i" and see this--
UDP (54 bytes) from 192.168.1.2:1137 to 192.168.0.1:53 on eth0
UDP (54 bytes) from 192.168.0.1:4042 to 208.33.88.5:53 on eth0
UDP (156 bytes) from 208.33.88.5:53 to 192.168.0.1:4042 on eth0
UDP (156 bytes) from 192.168.0.1:53 to 192.168.1.2:1137 on eth0
ICMP dest unreach (host) (184 bytes) from 192.168.0.5 to 192.168.0.1 on eth0
UDP (61 bytes) from 192.168.1.2:1137 to 192.168.0.1:53 on eth0
UDP (156 bytes) from 192.168.0.1:53 to 192.168.1.2:1137 on eth0
ICMP dest unreach (host) (184 bytes) from 192.168.0.5 to 192.168.0.1 on eth0
ARP request for 192.168.0.1 (46 bytes) from 0020af1b084c to 00608c82c459 on eth0
ARP reply from 192.168.0.1 (28 bytes) from 00608c82c459 to 0020af1b084c on eth0
208.33.88.5 is my isp's dns -- set as forwarder in my server's
/etc/bind/named.conf settings.
i see that a dns request starts out as udp on port 53; the
server doesn't have the zone requested so it forwards the
request upline to my isp's dns; the reply comes back on the same
channel -- but apparently the firewall doesn't let the reply
back (line four seems okay at the server as shown above, but it
doesn't reach the client).
ICMP dest unreach (host) (184 bytes) from 192.168.0.5 to 192.168.0.1 on eth0
what does THAT indicate? .0.5 is the orange card in the
firewall; 0.1 is the server on the other end of the orange
subnet (where iptraf was running).
then my client .1.2 tries again, and the reply goes back again
-- but the client never gets it.
i swear i've got the port forwarding and dmz pinholes set
properly in the firewall, but apparently i'm missing something.
somebody whap me with a clueclub, would ya?
--
I use Debian/GNU Linux version 2.2;
Linux server 2.2.17 #1 Sun Jun 25 09:24:41 EST 2000 i586 unknown
DEBIAN NEWBIE TIP #39 from Roy Culley <tgdcuro1@gd2.swissptt.ch>
:
Wondering why the pundits say that CSH SCRIPTS ARE CONSIDERED
HARMFUL? Although "tcsh" has improved on "csh" there are still
issues. For the full scoop, read
http://www.faqs.org/faqs/unix-faq/shell/csh-whynot/
Also see http://newbieDoc.sourceForge.net/ ...
Reply to: