Am I looking for an impossible solution ???

[John Waller]

I currently have an interesting situation.

I have a number of remote support people who use SonicWall VPN to connect to our UNIX servers. Of course the IP address of these users is provided by their own ISP's and is unknown to our network. The problem I have is that a telnet takes about 60 seconds before it displays the login prompt.

I understand that this delay is caused by the server trying to perform a reverse lookup on the IP address to resolv the host name, but how can I prevent the delay?? We have 2 DNS servers on our network which is probably why it takes about 60 seconds but changing this to one still takes about 30 seconds.

I can't add every possible IP address to our DNS servers, but I can't find a way to an an generic address or zone to cover all address outside our subnet

To make this worse, we don't have the same situation if you telnet to a non Unix/Linux server.

[Paula J Frazer-Campbell]

John

I have not used Sonic Wall but would imagine the problem is in the config of somnic wall in that should it not do an address translation fot these vpn telnet users and only present a known pre-defined range of ip addresses to the server.

Paula

[Massimo Bianchi]

Hi,
justa thought: does this occur for every user or only for certain users ?

It may also be a problem related to NIS/NIS+/LDAP, do you have any of these facilities ?

Are you sure that the problem is the reverse lookup ? Or it might be related to tha handshaking of the VPN ?

HTH,
Massimo

[John Waller]

Paula,

The SonicWall VPM client just provides an IP tunnel to our network. Unfortunatly it does not support NAT (Network Address Translation), so the IP address provided by our users ISP's is the IP address seen by our servers, hence the problem.

[John Waller]

Massimo,

This happens for all users. I can prove its reverse DNS related by deleting the entry of my own office PC from our dns server. When I try to telnet to a UNIX server I get the delay, but a ping works straight away.

[Massimo Bianchi]

If you were NOT using DNS, this is the solution:

The following /etc/nsswitch.conf entries allowed immediate login via ftp/telnet
(my network is configured properly):

hosts: files [NOTFOUND=return UNAVAIL=return]

or

hosts: files [NOTFOUND=return UNAVAIL=return TRYAGAIN=return]


If you can avoid DNS, this might be a solution.

Still looking for case similar to yours....

HTH,
Massimo

[Massimo Bianchi]

To follow my previous reply: would be possible to limit the telnet of your user to a certain number of hosts, and on these disable DNS ?

I did a search but your problem looks well known, but not resolved in 11.00

There should be an enhancement in 11.11, where you can specify the timeout for the reverse lookup for telnetd, but a backpot to 11.00 it's not near.

YOu can try mny hint an afterwards decide.

HTH,
Massimo

[John Waller]

Massimo,
Yes it does happen for all users. I believe it is due to reverse lookup as I have removed the dns entry for my office PC from our dns server telnet to UNIX server and I get the same delay. The basic question is how can I telnet from an unknown hostname.

Its worse as this only effects my UNIX/LINUX servers.

[RAC_1]

If my memory sevres right, I remember to have read abt .nslookuprc file, where you can put DNS resolution parameters.

I remember to have read timeout value for DNS search. If you reduce this you will get telnet early.

But 30 sec seems to be default.

[Michael Steele_2]

I'm focusing on this statement "...we don't have the same situation if you telnet to a non Unix/Linux server..."

Please isolate the path and determine what network nodes are involved for both. Use tracert from your windows work stations.

> tracert 192.1.1.1
.
.
.
Trace Complete.

Isolate the differences and focus on the network node difference.

[Michael Kelly_5]

John,
this is almost certainly caused by your DNS timeout settings.
telnetd makes a gethostbyaddr() call to try to map the incoming IP address to a name. This triggers the resolver library routines which results in an nslookup. The nslookup eventually times out. The fact that using two DNS servers takes twice as long as one would seem to confirm this.
As Anil suggested you can create a .nslookuprc file (which should be in root's home directory as telnetd will be running as root) and specify the options you want to override.
I would start with "retry = 0"

HTH,
Michael.

[Michael Kelly_5]

Forgot to mention.
See 'man nslookup' for details of the options you and set.

Michael.

[John Waller]

Thanks for everybodies help so far.

Massimo your entry for the nsswitch.conf file file does work but it does cause problems with not having DNS. Unless somebody else comes in with a better answer I will allocate you another 3 points but I have not allocated 10 to try to encourage further ideas.

Mike , Anil, The .nslookuprc file makes no difference. If I do an nslookup 123.123.123.123 which is an unknown address to our dns server it returns sraight back with
Trying DNS
Trying NIS
looking up FILES
*** No hostname information is available for "123.123.123.123"
but the telnet still takes ages.

Michael, The trace route does not show any differece to between a UNIX server and an iseries or windows server.

I believe the problem is somewhere in the gethostbyname routine telnet must perform, else why does Massimo's fix for disabling DNS work. I'm guessing this function does not use a straight nslookup.

[Massimo Bianchi]

Hi,
if the people you mentioned connect rarely, i will not disable DNS.

This problem is not-blocking, it is only annoying.
So, if disabling DNS can held more problem, i will let situation as is.

Another solution: build just one server, with all secutiry cares on it, and have all the people connect to this server.

From this server, they can telnet/login to the others, without loss of functionality.

If security is a concern, and you must export also the X server, you can think of using ssh.

HTH,
Massimo

[Bill Douglass]

Try setting

retry 0

in your resolv.conf file.

[Steven E. Protter · Accepted solution]

You probably could pick up those UP addresses pretty easily.

Go through your /var/adm/syslog/syslog.log file and you'll see most of them.

Of course you'll want to run the daemons in inet.conf with the enhanced logging feature -l

From there you can collect some data off of your syslog and then write a script adding them to a dns zone called outside or unknown.

Most non dial-up users with dynamic IP addresses generally get the same one for months at a time.

As an alternative, you can just use made up hostnames for the same data in /etc/hosts and set the DNS servers to a quick timeout, so files gets used quickly.

This could disrupt internal dns, but probably not.

I don't think your situation is impossible. You merely need to think outside the box and patiently try some ideas.

Good Luck,

SEP

[Rita C Workman]

Well the telnet thing will do that...but there is a way to work with your VPN, from what I am hearing from our VPN person here.
I think Paula hit the issue...it's how you configure your VPN. That's what our VPN guy tells me.

Here we come from a variety of ISP's....and gain access. We pass through the firewall and login to our VPN. In other words...and body from anywhere can hit the VPN login, but must have an account and password to gain access (so all ports are open at that end).....once logged in each login get's a unique private IP that is within the IP ranges allowed on the UNIX servers, and allows the connection to then pass on through....

Can you tell I am not the VPN guy......but that is the basic scenario he outlined to me. He says this is just one of the ways you can configure VPN.

Hope that made some sense,
Rita

[Mark Greene_1]

Talk to your reseller about an upgrade. It appears the new, low-end version of SonicWall supports NAT:

http://www.sonicwall.com/products/soho3.html

Being able to NAT is really the issue, and then you won't have to bother with the DNS lookups.

HTH
mark

[Ron Brown_2]

Just a thought, but could the VPN router be configured to look for the MAC address of the client connection, thereby routing properly and without regard to IP address on the client end? Is that an option with the Sonicwall device?

[John Waller]

Rita, The main problem is that our VPN access has been done on the cheap and as such does not issue addresses within the private range. I have since found out from our PC guys who setup the software to use from home is that they used older PC's running Windows 95/98. Windows 2000 has an option to setup a virtual LAN connection which when used with a firewall acting as an DHCP relay will actually asign a DHCP allocated IP address and as have configure DHCP with BIND9 to auto update this will auto populate our DNS server and bingo no problem. Unfortunatly costs determine that this won't happen for a while so I think Stevens solution of manually adding the IP addresses either to DNS or to the /etc/host files could be the way to go.

Many thanks to everybody for their help on this one it's goo to know there are people out there willing to help.

[Brian Hackley]

John,

I give this tip out frequently:
Change the DNS resolver timeout!

The root cause of the issue is, as others have noted, the time to do the map of the incoming IP to a hostname using DNS. Change the DNS resolver timeout so that you won't get as long of a pause. e.g. retry 1 and retrans 1000

# cat /etc/resolv.conf
search mydomain.com anotherdomain.com
nameserver 10.10.10.10
retrans 1000
retry 1

resolver(4) man page sez:
retrans value in milliseconds
retry number of retries

Implemented in libc patches for 10.20 and 11.0 in 1999, implemented in 11.11 base release.

Hope that helps,

-> Brian Hackley