lkml.org 
[lkml]   [1999]   [Jan]   [3]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectIP Firewalling/Redirect

I don't know if this is expected behavior .. but it didn't seem
right to me so here goes.

I ran across an interresting concept in a BIND FAQ that
discussed having two bind servers running on one machine and
servering requests based on IP for ussage on networks behind
a firewall or in resolving IP's on a network that wheren't ment
for say the outside world.
The section of the FAQ concerning this can be located at:
http://www.intac.com/~cdp/cptd-faq/section5.html#split_DNS

To quote the FAQ:
"A corporation may impose the following policy: if someone asked
for the IP address of WWW.DOMAIN.COM, they may want to:
* Answer that the IP address is 172.16.2.3, if the request came from
one of the following IP networks: 172.1/16, 172.2/16 or 172.10/16.
* Answer that the IP address is 172.16.1.1, if the request came from
the IP address 172.16/16 or 172.17.128/18.
* By default, for all other requests send the answer that the IP
address is 172.16.2.3."

The utilities recommended for the process where either udprelay
or NAT.

I saw no obvious reasons why the linux transparent proxy and ip couldn't
handle this aspect. The end theory is that each named sits on it's
own port on the same server and a set of rules based on source
address decide which port the request will be directed at.

In hopes of utilizing this configuration for my network in order
to keep a single unified nameserver that handles requests for all
hosts I ran across the following "features" that appeared fairly odd.

Initially I had configured one named to listen-on port 53 as default.
This named would answer all public requests. Anything comming
from outside the local network.
The second named was bound to port 54 for answering all requests
for the internal network.

The initial ipchains rule I settup to handle this request was as
follows:
ipchains -A input -p tcp -s 192.168.1.0/24 -d 192.168.1.42 53 \
-j REDIRECT 54
ipchains -A input -p udp -s 192.168.1.0/24 -d 192.168.1.42 53 \
-j REDIRECT 54

This I assumed would redirect any requests from the local network
to port 54 to be handled by the second named. This failed misserably.
It turns out that the redirection does not function if the initial
destination port ( port 53 ) is bound to.
( so far only true for named for unknown reasons )

Not to be one to be discouraged overly about this I settup the first
named on port 55 and modified my rules some.
In particular I applied a another rule that simply stated
ipchains -A input -p tcp -s ! 192.168.1.0/24 -d 192.168.1.42 53 \
-j REDIRECT 55
ipchains -A input -p udp -s ! 192.168.1.0/24 -d 192.168.1.42 53 \
-j REDIRECT 55

Feeling odd at this time that I would be using 3 ports to do the job
of 2 I went ahead and attempted to use this configuration.

nslookup of hosts via the local network worked flawlessly. As did
any and all nslookups of hosts from a machine outside the network,
at this time I was like yeh .. it works .. all is well.

Problems came when I tried to ping/telnet ..ect.. ( use anything
other then nslookup ). The request would hang and I would get back
something to the aspect of "host not found" after a timeout period.

I have not yet ripped apart a whole lot to figure out what is going
on, but with logging rules turned on I do get reports that the
requests are comming in and beeing redirected. But for some reason
the applications are having a bad hair day handling it.

Since then I have reverted back to just returning public only data
for all requestes regardless of host and setting up an /etc/hosts
file for all machines inside the private network.

A note: this does not appear to be true for inetd. I can settup
an entry in the inetd to run a script for port connections and
the redirection appearrs to work flawlessly regardless if inetd
is handling requests to a port already or not. This only appears
to be a conflict of interests in named at the moment that I can tell.

--
"Reality is what you can get away with!"
++Robert Anton Wilson
Major'Trips'
E-Mail : shadow@cyberwizards.com || major@jimco-fwt.com

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/

\
 
 \ /
  Last update: 2005-03-22 13:49    [W:0.045 / U:0.948 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site