Messages in this thread | | | Date | Sun, 3 Jan 1999 05:50:38 -0600 | From | "Major'Trips'" <> | Subject | IP 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/
| |