telnetd: Time out occurred in the initial option negotiation

[Bob Moore_1]

I have a system that we are trying to put into our dmz so it can be accessed safely by outside parties. Everytime i change the ip from it's public lan subnet ip to the dmz subnet ip, everything seems to break. ftp, ssh, telnet, rlogin, remsh. Everything.

It looks like a problem with reverse lookups for telnet. but like i said.."looks like". Cause i'm not convinced that it is. since the system has no problem resolving ip's and hostnames. I've even put a bunch of hosts in the /etc/hosts file to rule this out. And i've put files first in /etc/nsswitch.conf. But the syslog file contains messges like this:

telnetd[2995]: Time out occurred in the initial option negotiation

and

sshd[3156]: Did not receive identification string from 192.168.99.33
(192.168.99.0)=vpn subnet

other info: the fw had been opened up so much that it was pretty much just a gateway. so i'm not convinced that it's the fw. Also, this only happens when coming from certain other subnets. for instance: we have a subnet 172.16.74 that my workstation sits on, and i have not had any problem getting to the system. BUT, our server subnet, vpn subnet, and pc subnet all get the connected to screen with no login prompt, and that's where it stays until telnetd times it out. I have even put another system out there and configed it just like the one in question. no problems at all. It seems to be something with THIS one system. I have been over all the files that i can think of that might have anything remotely to do with this. I can't find anything that would cause this kind of behavior.

If anybody has any ideas i would appreciate it.

thanks

[Fred Ruffet]

resolving names only implies that you can reach your name server. From the server, can you do a "ping -o" to a machine an the subnet where you can't telnet ? and to you machine ?

regards,

Fred

[Bob Moore_1]

With the firewall rules in place that will block anybody from accessing our internal network from that system..ping -o breaks. I think it's because traceroute is not allowed either. but i can ping both ip's and hostnames internally from the system in the dmz.

[Mel Burslan]

This is looking more than anything else, like a firewall rule issue. When you are talking about DMZs and timeouts, which usually means, firewall has not been opened bidirectionally. Most probably initiation of telnet is taking place all right but communication going out of your server is not passing thru or your firewall rules are too strict o let any other port than 23 for telnet and at the further stage of port negotiation, it is bumming out.

This is my educated guess as I have lived thru a similar but not the same problem in the past. Take it with a grain of salt but I hope it gives you somewhere else to investigate at the least.

[Bob Moore_1]

Mel..this was my first thought as well..but even after all restrictions were lifted on the fw..still..none of the services would work. thanks though.. :-)

[RAC_1]

sshd -ddd
Try ssh to host and post.

Anil

[Mel Burslan]

do you by any chance have PHNE_24762 or superseeding patch PHNE_26096 applied to your system. It looks like 24762 is somehow mentions the issue you are having but I am not quite sure if it is introducing the timouts or remedies them. Another thing to check.
lifting all FW rules and having the same result is perplexing.