Take the 2-minute tour ×
Server Fault is a question and answer site for professional system and network administrators. It's 100% free, no registration required.

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.

share|improve this question
    
is your local and remote machine in the same subnet? –  JohannesM Nov 30 '12 at 8:10
    
And just for completeness, from the same client from which you did openssl s_client -connect 198.51.100.1:8140 above, can you cut-and-paste the output of telnet 198.51.100.1 8140? –  MadHatter Nov 30 '12 at 8:40
add comment

5 Answers

up vote 2 down vote accepted

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?

share|improve this answer
    
the problem was indeed the IPv4 routing. There the firewall on the VM-Host blocked the communication between VMs on different VM-Hosts. I found this out using traceroute. –  Clemens Bergmann Dec 7 '12 at 4:52
add comment
Connected to athena.hidden.tld.

Looks like you're connecting via hostname. Try using IP address to eliminate the possibility of DNS issues:

openssl s_client -connect puppet.master.ip.address:8140
share|improve this answer
    
that does not help either: openssl s_client -connect puppet.master.ip.address:8140 connect: No route to host connect:errno=113 –  Clemens Bergmann Nov 30 '12 at 7:57
    
updated the description with details –  Clemens Bergmann Nov 30 '12 at 8:04
add comment

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.

share|improve this answer
add comment

You have to check the versions of openssl. There is an odd error out there that reports 113...if you dig a little deeper you may see a "handshake" problem....IIRC, 0.9.8 had the problem...if you are at that rev. or below...try updating your openssl.

Check this out... http://stackoverflow.com/questions/8619706/running-curl-with-openssl-0-9-8-against-openssl-1-0-0-server-causes-handshake-er/8621263#8621263

share|improve this answer
add comment

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?

share|improve this answer
add comment

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.