If openssl s_client fails with BIO_connect: No route to host (errno 113), the TLS layer never came into play: the underlying TCP connection to the server could not be established, so no handshake was even attempted. In a home-hosted setup such as a Prosody XMPP server behind a consumer router, this almost always points at the network path rather than the server itself — and in the incident documented here, the culprit was a Fritz!Box whose firewall and port-forwarding state had silently degraded. The server configuration, including its self-signed certificate, was correct all along; a router reboot restored connectivity.
What "No route to host" really tells you
OpenSSL is a TLS library, but before it can negotiate anything it must obtain a TCP socket. The error therefore comes from the operating system's connect() call, not from any TLS logic. errno 113 is EHOSTUNREACH: either your own host has no route, or — far more common across the internet — a router or firewall somewhere along the path actively answered with an ICMP "host unreachable" message.
It helps to distinguish the three TCP connection errors you will typically see:
- No route to host (113) — something on the path actively signalled that the destination is unreachable; typical of a misbehaving firewall or router.
- Connection timed out (110) — packets are silently dropped; the classic symptom of a filtering firewall.
- Connection refused (111) — the host is reachable, but nothing is listening on that port, or it answered with a reset.
So the OpenSSL output is not unhelpful. It says precisely that TLS was never reached and that the failure lies below it. Your task is to find where the packets die.
Why DNS lookups and ping still succeed
nslookup exercises only DNS, and ping exercises only ICMP echo. Neither opens a TCP connection to port 5222, so both can report success while the actual service path is broken. A router can happily resolve names and answer ICMP while its forwarding rules for TCP are stuck.
One detail that looks alarming but is perfectly normal: on mobile networks, a client may connect to an address such as 64:ff9b::5900:df84. That is a DNS64/NAT64 translation of an IPv4 address — an IPv6-only carrier network translating towards your IPv4 server. Seeing such an address in a successful s_client run is not an error.
Tracing the failure hop by hop
- Confirm what clients actually resolve. Compare the DNS answer against the router's current WAN IP — with a dynamic address, the record can lag behind after an IP change.
- Capture on the server while repeating the connection attempt from outside:
tcpdump -ni any tcp port 5222- If SYN packets arrive, the problem is on the server itself: check the local firewall (
nftables/iptables) and confirm Prosody is listening withss -tlnp | grep 5222. - If nothing arrives, move the investigation upstream. Inspect the router's port-forwarding rules and event log, or capture from an independent vantage point such as a small VPS to see whether packets even leave your provider's network.
The decisive comparison is at the router: packets arriving on the WAN interface but never being forwarded towards the server mean the router itself is dropping or mis-routing them.
When the router itself is the fault
Consumer routers that run for months with a dynamic WAN address can accumulate stale state: after an IP change, port-forwarding bindings or the connection-tracking table can end up inconsistent, and the firewall stops accepting new connections to forwarded ports even though every rule looks correct in the web interface. Rebooting rebuilds NAT and firewall state from the stored configuration — which is exactly what resolved this case. Afterwards, s_client completed a full TLSv1.3 handshake (cipher TLS_AES_256_GCM_SHA384, X25519 key exchange), proving the service was healthy again.
Note that the remaining verify error: self-signed certificate is expected with certificates generated by prosodyctl and does not block clients that are configured to trust them.
Keeping a dynamic-IP home server reachable
- Schedule a periodic router reboot during a quiet hour.
- Monitor the real path — a TCP connection plus STARTTLS — not just ICMP.
- Automate DNS updates so the record tracks IP changes promptly.
- After each IP change, verify the port forwarding is still bound to the new address.
- Use native IPv6 end-to-end if your provider offers it; it removes NAT state from the equation entirely.
- Keep an out-of-band management path (for example, a VPN into the LAN) so you can reach the router even when forwarding is broken.
#!/bin/sh
# xmpp-watch: log when the STARTTLS path breaks
if ! openssl s_client -starttls xmpp -connect home.example.de:5222 \
</dev/null >/dev/null 2>&1; then
echo "XMPP STARTTLS unreachable at $(date)" >> /var/log/xmpp-watch.log
fiFrequently Asked Questions
Does "No route to host" indicate a TLS or certificate problem?
No. It is a TCP-level failure reported by connect() before any TLS bytes are exchanged. Certificates only become relevant once the TCP connection and the STARTTLS upgrade have succeeded.
Is openssl s_client related to SSH?
No. OpenSSL implements TLS; OpenSSH implements the SSH protocol. They are separate tools on separate ports. Debugging an SSH problem with s_client — or assuming a TLS error is an SSH error — sends the investigation down the wrong path.
Why did ping and nslookup work while the connection failed?
They test different things: name resolution and ICMP reachability. The failing component — TCP forwarding to port 5222 through the router — is exercised by neither, so both tools can stay green during the outage.
Is the "self-signed certificate" verification error a fault?
Not by itself. Prosody certificates created with prosodyctl are self-signed, so OpenSSL reports verify return code 18 while still completing the handshake. Clients that trust the certificate work fine; for less friction, deploy a certificate from a public CA such as Let's Encrypt.
What does connecting to a 64:ff9b:: address mean?
It is a DNS64/NAT64 address synthesized by a mobile carrier so that IPv6-only clients can reach IPv4 servers. The connection is translated back to your server's IPv4 address and is not an error.
How do I detect this failure automatically next time?
Run a scheduled check that performs a genuine STARTTLS connection, as in the script above, and alert on failure. Because ping and DNS can remain healthy throughout this kind of outage, the check must actually open a TCP connection to the service port.