name service through proxy/gateway

["Dr. P. Sriram" <sriram@xxxxxxxxxxxxxxxxxx>]

On Tue, 7 Dec 1999, Anna University wrote:

> Hi luggies
> command line. So let's assume a user on a Win9x machine in the 192 subnet
> points the browser at www.hotmail.com . The Win9x machine, we assume, is
> already configured to use the gateway as the primary namerserver. So it
> sends a packet ( UDP, right ? ) to get the IP address for www.hotmail.com
> . And the gateway gets the IP in the usual manner. I hope this is
> what happens.
>      Now if the Win9x machines had their nameserver IP set to say
> 202.54.6.1 ( vsnl's nameserver ), then the machines would no longer be
> able to browse using website names right ?

once again, two solutions are available. one is to run a nameserver on the
firewall/gateway which will in turn retrieve names from the internet and
serve them; or, one can masquerade (masquerade, not simply forward) dns
packets also with another suitable entry in the ipfwadm tables. in fact,
with ipfwadm type gateway, one would have to have a suitable entry for
every service that needs to be ontained through the gateway. however, all
services can be set up using a single ipfwadm command by giving a range of
port numbers in the command so that all required services are covered.


>      RHL 6 and above I think comes with ipchains instead of ipfwadm. But
> will we still have to use those "/sbin/modprobe ip_masq_ftp.o" lines to
> enable services like ftp, CuSeeMe through the masquerading host ? 
>      

ftp through a masquerading gateway is always tricky. unlike almost all
other services, ftp uses multiple connections (sockets/ports) for a single
link. so, if machine a ftp's to machine b, a will first open a connection
(on the standard ftp port 21) of machine b. now, if a issues a ls command,
machine b will open a connection back to machine a and send the directory
listing over this connection. this all works fine in normal setups. if
there is an intervening masquerading gateway, this wont work. say, g is
the gateway, then b thinks the ftp is coming from g (though it is actually
coming from a; but then, only a and g know this); so, when a opens ftp, b
thinks g has opened an ftp. when a does an ls, b will try to open a data
connection to g and since g does not have an ongoing ftp to b, it will not
accept the ls data; this will show on the a-(g)-b ftp screen as ls failed
or some such.  the good old solution to this is to issue the passive
directive in the ftp session. then, when an ls command is issued by a, b
will not open the data connection, but wait for a to open a data
connection and then send the ls data over this. this connection also needs
to be opened up for masquerading in the gateway. then, ls will work like
normal. the other way to do this is to have ip_masq_ftp (i have not used
this myself, so my comments below may be totally false). this module
running on the gateway accepts the ls data connection from b and passes it
along to a. in this case, of course, the passive declaration is not
needed. 

sriram
(the original)


---
Send e-mail to 'ilugc-request@xxxxxxxxxxxxxxxxxx' with 'unsubscribe' 
in either the subject or the body to unsubscribe from this list.