Login delay when accessing DMZ servers

[Kevin McNamara_1]

I have 2 HP-UX 11.11 servers in our corporate DMZ. Our Network Security team has opened ssh access from the internal corporate network to these servers. When I try to ssh to these servers from within our corporate network it takes a long time (2 min). The "Login as:" prompt comes up very fast. But, after I enter my ID it takes about 2 minutes for the "password" prompt. Once I get logged in, response time is fine for all non-network commands. If I enter a "netstat -a" command, it takes several minutes to complete. What is causing the long delay during the login process?

[Pupil_1]

Do you see a visible difference in response for
netstat -a
and
netstat -an

[Mel Burslan]

I think the answer to your question is quite obvious: Your firewall rules are causing the delays. Without being the actual firewall admin, nobody can say what exactly is the cause, but from the common experience, when firewall admins open ports on a DMZ boundary, they are overly cautious not opening a port accidentally. Sometimes a port that needs to be open bidirectionally get opened only one way and this may (and most of the time will) cause delay of the nature you are describing.

Ask the firewall admins to put a sniffer on the firewall and you re-create the delay. They should be able to tell you what type of packets are being dropped while your server is waiting for a timeout on that communication.

[Bill Hassell]

Another thing to look at is DNS resolution. Terminal style protocols will do some reverse lookups to validate the incoming IP address. Missing reverse DNS records can cause these types of delays (about 20-30 seconds per DNS server listed in resolv.conf.

[Kevin McNamara_1]

Changing the DNS servers listed in the resolv.conf fixed the problem. Thanks for your help.

[Pupil_1]

netstat -an will not attempt to resolv the address from DNS and will be faster if you have incorrect DNS setting.

netstat -a will try to perform the name resolution and hence the delay.