Hello,

I'm experiencing something very strange on a couple of Debian 3.0r2 and pre-3.1 installations.

I can surf with browsers and wget works normally against external internet based web servers. However, it seems that neither inbound or outbound SSH doesn't work from/to internet and I cannot telnet to port 80 towards web servers that I can browse with a browser or use wget with (the sites do use the default http port).

Telnet tests and SSH works fine in my internal 192.168.0.0/24 network, but when it comes to accessing internet these just won't work.

I tried to trace the problem with tcpdump to see how the wget and telnet requests differ, but I see no mentionable difference in the first package sent from the linux. It's just that no reply is never received from the remote host when using telnet 80.

I just installed a brand new D-Link DSL-504T adsl modem/firewall/nat router between the internal network and the internet. Obviously this could be causing this, but it seems kind a strange that the XP workstations in the 192.168 network work just fine including telnet tests and SSH. This is why I'm considering this as a Linux based problem or a feature.

Also on the Debian machines ping works fine against external hosts.

Does this sound familiar to anyone??

Tuomas.

I'm not sure of your setup but remember that when you telnet like that you probably won't be sending the hostname so only the first virtual host is likely to be accessed.

Hi, the problem is not about matching the http server configuration. Sure, when telnetting to a web server the HTTP request has to be properly formatted as it was sent by a real browser, but in my case the problem is that the telnet does not even connect to the remote socket; the tcp connection is never established. Telnet attempts freeze at the "Trying xxx.yyy.zzz.ccc ...".

Further, I cannot connect to any other ports like TCP 25 (smtp) either, it's not really not a http problem. Strange, hu?

With SSH, the client terminal just hangs after entering the remote server password -- it locks until the client process is terminated.

This really does seem odd, especially if you can wget from the same server. Can you telnet to another server - "www.google.com 80" for example?

If you monitor the connection with ethereal - do you get any response at all when you initiate the telnet connection?

No I don't. I have now used both tcpdump and ethereal to monitor the traffic in both situations when I do a "telnet www.google.com 80" and a "wget www.google.com". Telnet attempts only cause a single outbound TCP packet (and consequent identical packages if I wait long enough for the telnet program to retry). wget run results in a total of 37 packets with proper SYNs and ACKs -- even the google page is stored in a local file by wget.

Could this be somekind of a IPv4 vs. IPv6 conflict? This is an area that I'm not that familiar with. In the "ifconfig -a" listing I see a sit0 IPv6-in-IPv4 interface (it's normally DOWN, but I set it UP just to see if it has any chance -- didn't). It's probably not that I would have a IPv6 telnet or something, because the name is properly resolved and the telnet client prints:

"Trying 66.102.11.99..."

Hmm.. there might be something wrong with the DNS (the D-Link mentioned in the original post is configured as the only nameserver in resolv.conf), occasionally like just now when I tried "host www.google.com" I just got a A record with IP 1.0.0.0... But this can't be the only problem because of trying-line above, for example.

Maybe a good old reinstall will help

--

Hmm, did some investigating it seems that /usr/bin/telnet is a symlink to some /etc/alternatives/telnet (telnet.netkit), whatever that is?? Anyway, it works connecting to the D-Links telnet and http ports, so... at least the host port syntax is the same old.

An another thing, when installing these Debians a while ago I had to choose the 2.6.8-1-686-smp kernel to get the Serial ATA raids working.

Do these ring any bells regarding the problem?

This seems a bit odd.

For the DNS issue you may want to try using a public dns service:
http://www.newroot.com/

Like you said though - I can't see why that would cause the main problem as you can see that the address resolved correctly.

Do you have any iptables rules on that machine?
iptables -nL
iptables -nL -t nat

Is there another machine on the LAN you could try from? Even a knoppix disk in the same machine.

well this is getting passionate..

The iptables are all clear with the default policy of ACCEPT. No NATs on the Linux.

All three linuxes fail equally in the LAN, two XP workstations work like they should. Two of the linuxes are testing releases of Debian Sarge and the third is a stable Debian Woody..

I'll try booting from a old RedHat install cd and try telnet from there... ==> Well, the only DVD I could get booting is the same Sarge install disc. I configured the network interface, mounted the already installed partition that contains /bin and the necessary runtime libs, set lib paths and tried running the same telnet application. The result was the same, Trying... Name resolving and also wget worked fine. This really wasn't much of a test, but at least the problem persists in a significantly simpler environment under BusyBox prompt.