<?xml version="1.0" encoding="UTF-8"?>
<rss xmlns:content="http://purl.org/rss/1.0/modules/content/" xmlns:dc="http://purl.org/dc/elements/1.1/" xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#" xmlns:taxo="http://purl.org/rss/1.0/modules/taxonomy/" version="2.0">
  <channel>
    <title>topic Re: Login delay when accessing DMZ servers in Operating System - HP-UX</title>
    <link>https://community.hpe.com/t5/operating-system-hp-ux/login-delay-when-accessing-dmz-servers/m-p/3865684#M277474</link>
    <description>Do you see a visible difference in response for&lt;BR /&gt;netstat -a&lt;BR /&gt;and &lt;BR /&gt;netstat -an&lt;BR /&gt;</description>
    <pubDate>Tue, 19 Sep 2006 12:28:18 GMT</pubDate>
    <dc:creator>Pupil_1</dc:creator>
    <dc:date>2006-09-19T12:28:18Z</dc:date>
    <item>
      <title>Login delay when accessing DMZ servers</title>
      <link>https://community.hpe.com/t5/operating-system-hp-ux/login-delay-when-accessing-dmz-servers/m-p/3865683#M277473</link>
      <description>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?</description>
      <pubDate>Tue, 19 Sep 2006 12:25:00 GMT</pubDate>
      <guid>https://community.hpe.com/t5/operating-system-hp-ux/login-delay-when-accessing-dmz-servers/m-p/3865683#M277473</guid>
      <dc:creator>Kevin McNamara_1</dc:creator>
      <dc:date>2006-09-19T12:25:00Z</dc:date>
    </item>
    <item>
      <title>Re: Login delay when accessing DMZ servers</title>
      <link>https://community.hpe.com/t5/operating-system-hp-ux/login-delay-when-accessing-dmz-servers/m-p/3865684#M277474</link>
      <description>Do you see a visible difference in response for&lt;BR /&gt;netstat -a&lt;BR /&gt;and &lt;BR /&gt;netstat -an&lt;BR /&gt;</description>
      <pubDate>Tue, 19 Sep 2006 12:28:18 GMT</pubDate>
      <guid>https://community.hpe.com/t5/operating-system-hp-ux/login-delay-when-accessing-dmz-servers/m-p/3865684#M277474</guid>
      <dc:creator>Pupil_1</dc:creator>
      <dc:date>2006-09-19T12:28:18Z</dc:date>
    </item>
    <item>
      <title>Re: Login delay when accessing DMZ servers</title>
      <link>https://community.hpe.com/t5/operating-system-hp-ux/login-delay-when-accessing-dmz-servers/m-p/3865685#M277475</link>
      <description>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.&lt;BR /&gt;&lt;BR /&gt;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.</description>
      <pubDate>Tue, 19 Sep 2006 12:30:55 GMT</pubDate>
      <guid>https://community.hpe.com/t5/operating-system-hp-ux/login-delay-when-accessing-dmz-servers/m-p/3865685#M277475</guid>
      <dc:creator>Mel Burslan</dc:creator>
      <dc:date>2006-09-19T12:30:55Z</dc:date>
    </item>
    <item>
      <title>Re: Login delay when accessing DMZ servers</title>
      <link>https://community.hpe.com/t5/operating-system-hp-ux/login-delay-when-accessing-dmz-servers/m-p/3865686#M277476</link>
      <description>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.</description>
      <pubDate>Tue, 19 Sep 2006 12:50:42 GMT</pubDate>
      <guid>https://community.hpe.com/t5/operating-system-hp-ux/login-delay-when-accessing-dmz-servers/m-p/3865686#M277476</guid>
      <dc:creator>Bill Hassell</dc:creator>
      <dc:date>2006-09-19T12:50:42Z</dc:date>
    </item>
    <item>
      <title>Re: Login delay when accessing DMZ servers</title>
      <link>https://community.hpe.com/t5/operating-system-hp-ux/login-delay-when-accessing-dmz-servers/m-p/3865687#M277477</link>
      <description>Changing the DNS servers listed in the resolv.conf fixed the problem.  Thanks for your help.</description>
      <pubDate>Tue, 19 Sep 2006 14:41:49 GMT</pubDate>
      <guid>https://community.hpe.com/t5/operating-system-hp-ux/login-delay-when-accessing-dmz-servers/m-p/3865687#M277477</guid>
      <dc:creator>Kevin McNamara_1</dc:creator>
      <dc:date>2006-09-19T14:41:49Z</dc:date>
    </item>
    <item>
      <title>Re: Login delay when accessing DMZ servers</title>
      <link>https://community.hpe.com/t5/operating-system-hp-ux/login-delay-when-accessing-dmz-servers/m-p/3865688#M277478</link>
      <description>netstat -an will not attempt to resolv the address from DNS and will be faster if you have incorrect DNS setting.&lt;BR /&gt;&lt;BR /&gt;netstat -a will try to perform the name resolution and hence the delay.</description>
      <pubDate>Tue, 19 Sep 2006 14:45:37 GMT</pubDate>
      <guid>https://community.hpe.com/t5/operating-system-hp-ux/login-delay-when-accessing-dmz-servers/m-p/3865688#M277478</guid>
      <dc:creator>Pupil_1</dc:creator>
      <dc:date>2006-09-19T14:45:37Z</dc:date>
    </item>
  </channel>
</rss>

