> > info coming from the daemon sitting on port 1153 ( named) is seen by the
> > net app (ftp, telnet etc) making a dns request to port 53 as coming from
> > port 1153 rather than 53 as would be expected.these net apps ( aside from
> > nslookup) don't like this at all and cannot receive the dns info from the
> > 1153 port.
>
> And this surprises you *why* exactly? You really want NAT going the
> other way, which we don't have. I don't think even ipportfw will help
> you here.
i guess it helps to know what transparent proxying is. from the jos vos
paper describing ipfwadm:
"................................Transparent proxying redirects
sessions passing the firewall to local proxy servers in a fully
transparent way. Clients (both software and users) do not know their
session is handed over to a proxy process: they still think they have
a direct connection with the target they specified. Because it relies
on port numbers, transparent proxying only works for TCP or UDP
traffic."
you can read the rest of the section on the linux/ipfwadm transparent proxy
capability at :
http://www.xos.nl/linux/ipfwadm/paper/node5.html#SECTION00050000000000000000
As i said...it works just fine for tcp in 2.0.34. udp is broken .
i am setting up a 2.7.2.3 gcc to compile the kernel so that i will have
a "supported" configuration, and thus the linux kernel gods may deign to
favor me with a patch ... ;-))
however, since the 34 kernel compiled with 2.8.1 is so stable, i'm sure that
i'll be back reporting this problem exists with 2.7.2.3 made kernels too.
this is a really nice thing and i want to see it working fully.
fractoid
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu