7

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.

2
  • is your local and remote machine in the same subnet?
    – JohannesM
    Nov 30, 2012 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, 2012 at 8:40

5 Answers 5

3

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?

1
  • 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. Dec 7, 2012 at 4:52
1

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.

1

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?

0
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
2
  • that does not help either: openssl s_client -connect puppet.master.ip.address:8140 connect: No route to host connect:errno=113 Nov 30, 2012 at 7:57
  • updated the description with details Nov 30, 2012 at 8:04
0

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... https://stackoverflow.com/questions/8619706/running-curl-with-openssl-0-9-8-against-openssl-1-0-0-server-causes-handshake-er/8621263#8621263

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .