Re: IP Firewalling/Redirect
Major'Trips' (major@jimco-fwt.com)
Sun, 3 Jan 1999 23:26:30 -0600
On Sun, Jan 03, 1999 at 04:55:43PM -0500, nads@bleh.org wrote:
> Major'Trips' wrote:
>
> > 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/
>
> ipchains doesn't handle management of port redirections. It only takes care of
> filtering. To the best of my knowledge, ipmasqadm is suppose to be used for port
> redirectiion. See: http://juanjox.linuxhq.com/ . However I have not been able to
Well .. Port Redirection isn't handled by Masquerading in the
kernel from what I understand. It is handled by the
Transparent Proxy Support.
A clip from the ipchains manual page shows us :
"REDIRECT is only legal for the input and user-defined
chains and can only be used when the Linux kernel is com-
piled with CONFIG_IP_TRANSPARENT_PROXY defined. With
this, packets will be redirected to a local socket, even
if they were sent to a remote host. If the specified
redirection port is 0, which is the default value, the
destination port of a packet will be used as the redirec-
tion port. When this target is used, an optional extra
argument (the port number) can be supplied."
As best as I can tell, the #define TRANSPARENT_PROXY
effects such files as ip_forward.c, ip_fw.c, ip_raw.c,
ip_input.c, raw.c, route.c, tcp_ipv4.c, udp.c, af_inet.c
and icmp.c .. All in all it isn't directly attached to the
masquerading itself.
Anyway, I am not certain why this is happening .. but I
sat down and traced out the network packets themselves to
see what the network thought was going on.
On an nslookup
I get a real basic set of events.
UDP Request to port 53
Trans Proxy redirects to port 54
Response comes back from port 54 to the source port of the request.
Another reqest from a new port to port 53
Trans Proxy redirects to port 54
Response get's sent back to the newly opened port.
Arp who-was source tell destination
Arp reply source is-at MAC
The nslookup has no problems handling the redirected ports.
Problems occure when one tries to do a ping, or a telnet, or
anything else so far as I can tell.
UDP request from source to destination on port 53
Trans Proxy redirects to port 54
UDP response from destination back to source via port 54
ICMP source udp port source unreachable
Another arp who-was source tell destination
Arp Reply source is-at MAC
I had assumed that the transparent proxy would have monitored
the output from port 54 and translated it on the way out to
appear to be from port 53 .. thusly nullifying this problem
and making transparent proxy to be trully transparent to
both ends of the data stream .. shrug.
As well, the trasparent proxy still does not appear to function
on redirecting data away from port 53 if the port is bound.
This behavior has thusly been observed in 2.1.131 and
2.2.0-pre4.
> get this to work either.
>
> -- Nadeem
--
"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/