"No route to host" with ssl but not with telnet
I have a strange problem with connecting to a https site from one of my servers.
When I type:
telnet puppet 8140
I am presented with a standard telnet console and can talk to the Server as always:
Connected to athena.hidden.tld.
Escape character is '^]'.
GET / HTTP/1.1
<!DOCTYPE HTML PUBLIC "-//IETF//DTD HTML 2.0//EN">
<html><head>
<title>400 Bad Request</title>
</head><body>
<h1>Bad Request</h1>
<p>Your browser sent a request that this server could not understand.<br />
Reason: You're speaking plain HTTP to an SSL-enabled server port.<br />
Instead use the HTTPS scheme to access this URL, please.<br />
<blockquote>Hint: <a href="https://athena.hidden.tld:8140/"><b>https://athena.hidden.tld:8140/</b></a></blockquote></p>
<hr>
<address>Apache/2.2.16 (Debian) Server at athena.hidden.tld Port 8140</address>
</body></html>
Connection closed by foreign host.
But when I try to connect to the same host and port with ssl:
openssl s_client -connect puppet:8140
It is not working
connect: No route to host
connect:errno=113
I am confused. At first it sounded like a firewall problem but this could not be, could it? Because this would also prevent the telnet connection.
As Firewall I am using ferm on both servers. The systems are debian squeeze vm-boxes.
[edit 1]
Even when I try to connect directly with the IP address:
openssl s_client -connect 198.51.100.1:8140 #address exchanged
connect: No route to host
connect:errno=113
Bringing down the firewalls on both hosts with
service ferm stop
is also not helping.
But when I do
openssl s_client -connect localhost:8140
on the server machine it is connecting fine.
[edit 2]
if I connect to the IP with telnet it also is not working.
telnet 198.51.100.1 8140
Trying 198.51.100.1...
telnet: Unable to connect to remote host: No route to host
The confusion might come from IPv6. I have IPv6 on all my hosts. It seems that telnet uses IPv6 by default and this works. For example:
telnet -6 puppet 8140
works but
telnet -4 puppet 8140
does not work. So there seems to be a problem with the IPv4 route. openssl seems to only (or by default) use IPv4 and therefore fails but telnet uses IPv6 and succeeds.
Solution 1:
Can you check whether you can actually ping the target host? (IPv4) It seems that
- your IPv4 connection is broken
- there is an AAAA and an A record
- telnet manages to prefer IPv6
- openssl avoids IPv6
This might merely be an issue boiling down to IPv4 connections not working to the target host. Is your IPv4 routing OK on both machines?
Solution 2:
As you note, it looks like you're running up against a lack of ipv6 support in openssl. An LWN article gives some background, but it looks like your easiest solution (short of rebuilding a custom patched openssl) is to switch to gnutls.
Solution 3:
Depending on what telnet you have available to you, there may be a -4 or -6 switch to restrict the IP version forcefully, allowing you to rule in or out the IPv4 vs IPv6 concern.
What does the netstat -arn output look like? Are there IPv6 routes for the destination and/or default IPv6 route that is viable?