telnet session closed after some minutes

[Ute Schmalz]

Hello,

I have a problem to keep on the connection to the internet or any external computer.
After reboot of the B2000 with HP-UX-11.0 I start a telnet session to external machine. All is going ok for about 2 minutes. Then the connection is killed without any messages.
Then it is not possible to connect to external net. Message is: "Network is unreachable"
Telnet sessions inside our internal subnet are ok.
Who can help me with this problem ?

Thanks.
Ute

[Alexander M. Ermes]

Hi there.
Did you try a ping after you have been kicked out ? Try an ftp to the other computer.
Check the profile files for timeout parameters
( TMOUT=nn ). Check your /etc/inetd.conf for timeout parameters as well.
Rgds
Alexander M. Ermes

[Paula J Frazer-Campbell]

Hi
Also speak to your ISP to see if they have timeout problems.

Paula

[Sandor Horvath_2]

Hi !

If the external machine is the other subnet, and You lost default gatway may be this happened.
Check You can ping the default gatway, may be the router denied ping. IF the HP can't ping default gateway it will be lost about 1-2 minutes.
You can check the default gateway netstat -r

regards, Saa

[Ute Schmalz]

Hi,

thanks for your replies. But it could not help me.
I will give some more informations about the problem.
the b2000 (hp-ux-11) is a machine behind a firewall. The firewall is the gateway. ping will not be accepted from the firewall (because of security). With all other machines an alive connection to external net is possible. But I found a message in the /var/adm/vtdaemonlog file:
"Cannot set IEEE802 source sap for vt requests"
Which files have I to configure for right behavior ? Our default network device is configured as lan0. Do I need a snap0 interface too ? If yes, how is it to configure ?

Thanks in advance.
Ute

[Paula J Frazer-Campbell]

Hi

Check or have checked the firewall for what is allowed / not allowed,

If you can establish and maintain a telnet session albeit internal then an external telnet session is therefor dependant upon the devices that you are going through.

An option is to open ping/traceroute on the firewall to one of your destinations and ping and traceroute to test.

Just a few ideas

Paula

[Brian Hackley]

Ute,

I would suggest your either get a nettl network trace, sniffer trace, or netmon trace of the connection in question. This will tell you which host is sending the TCP Reset (RST) to abort the connection.

ITRC documents KBAN00000068 and KBRC00001272 contain instructions on how to do this. However, I would suggest that you use -e ns_ls_ip instead of -e all in Step #1 when you start the trace.

Note that if you cannot find the RST in the trace, it is possible that an intermediate host is causing the abort, so filtering on the source/target IP of the destination of the telnet may not capture the precise event.

Hope this helps,

-> Brian Hackley

[Jeffrey S. Sims]

I am having the same exact problem you seem to be having. I would appreciate it if you would share your solution if and when you get one. Thanks.

[Gary Lee_2]

Yes, please summarize any resolution -- I too am experiencing a similar problem.

We have numerous HP-UX 11.0 boxes behind Cisco firewalls all working without any problem. But we've shipped a couple of A500's to a customer's site who have a combined firewall/router and they are experiencing the same loss of connectivity you describe, approximately 5 minutes after bootup.

Both HP-UX machines exhibit the same behaviour, and a non-HP-UX machine will work fine using the same network cable and IP address.

[Christopher Caldwell]

Cisco firewalls (at least the PIX) usually use NAT (network address translation) and a proxy-like connection scheme.

In a nutshell, there's a configurable timeout on the firewall like
timeout xlate 00:05:00 conn 00:05:00 udp 00:05:00

which says, in effect
time out a translation and any connections in 5 minutes, give that the connection is not in use, where use is defined to be actively passing traffic.

If you have an uncooperative firewall manager, try running top and walk away from your telnet session for a while. It shouldn't time out because you're passing traffic.

If you have a cooperative firewall manager, ask what the timeout is set to, ask if it might be extended, or ask for them to provide a work around (static conduit, etc.) if they don't want to mess with the timeout.

Your mileage may vary if the firewall is not a PIX, but it probably won't vary far if it's a Cisco.

[Gary Lee_2]

I forgot to mention, the Customer's firewall/router is a Lucent appliance type device. The HP-UX machines behind this firewall/router experience the problem.

HP-UX machines behind our Cisco equipment do not have any problems.

[Gary Lee_2]

resolution found!!!

The problem is with the ire_gateway_probe setting. Apparently, this probe tries to detect if your gateway is alive by ping'ing it. If your gateway refuses ICMP, then HP-UX refuses to use the route.

To fix,

# ndd -set /dev/ip ip_ire_gw_probe 0

then delete and re-add the route.

To fix longterm, edit /etc/rc.config.d/nddconf and add the following lines ...

TRANSPORT_NAME[0]=ip
NDD_NAME[0]=ip_ire_gw_probe
NDD_VALUE[0]=0

Credit should go to Berlene Herren, who answered the question for Nadeem Rahman in the networking forum Subject: "default route don't work after couple of minutes" dated Jan 31, 2001