0

On my laptop i do:

 openssl s_client  -connect w00d8dd4.kasserver.com:465

I can see that the connection works. I can also do :

telnet w00d8dd4.kasserver.com 465

Also no problem.

Now, if I log in to my cloud server - and run the same command(s) as above - such as:

 openssl s_client  -connect w00d8dd4.kasserver.com:465

Then there is NO output, nothing happens even after several seconds.

However, if I do :

openssl s_client -connect kyle.com:443 -showcerts

it immediately connects. I have also tested with -tls1 and -debug switches. There is no difference.

I believe, this might be due to certain outgoing connection being blocked by firewall. How can I debug?

I have seen this question - but I was not able to find a proper guide. I have installed ca-certificates (20211016ubuntu0.22.04.1). The cloud serve is running UBuntu :

uname -a says :

Linux myStep-ubuntu-4gb-nbg1-2 5.15.0-67-generic #74-Ubuntu SMP Wed Feb 22 14:14:39 UTC 2023 x86_64 x86_64 x86_64 GNU/Linux

UPDATE

I have tried tcptraceroute -p 465 w00d8dd4.kasserver.com from the could server. It finds a route to the target, the result is:

 1  172.31.1.1  6.736 ms  5.755 ms  5.271 ms

2  17332.your-cloud.host (49.12.141.110)  0.447 ms  0.311 ms  0.280 ms
 3  * * *
 4  static.173.0.47.78.clients.your-server.de (78.47.0.173)  1.230 ms  0.834 ms  0.914 ms
 5  spine12.cloud1.nbg1.hetzner.com (78.47.3.45)  16.399 ms  0.911 ms  1.044 ms
 6  213-239-239-141.clients.your-server.de (213.239.239.141)  1.003 ms  0.515 ms  0.701 ms
 7  core0.fra.hetzner.com (213.239.252.25)  3.715 ms  3.788 ms  3.842 ms
 8  ipv4.de-cix.fra.de.as34788.all-inkl.com (80.81.192.119)  21.491 ms  21.468 ms  21.351 ms
 9  dd5114.kasserver.com (85.13.130.50) [open]  21.720 ms  21.228 ms  21.275 ms
Sean
  • 127

1 Answers1

1

If you're testing this against your own server, a packet capture is a good start. It tells you whether the target system (which must be doing the capture) is actually receiving the packets at all.

tcpdump and tshark are two common tools that work via SSH (Wireshark being a graphical one). For example, to capture all packets from and/or to port 465, use:

tcpdump -n -i eth0 "port 465"

tshark -n -i eth0 -f "port 465"

You can additionally run the same capture on the source system as well – if you see certain packets leaving the source machine but not arriving at the target, that directly means something along the way is blocking them.

Meanwhile, if the target server does receive a TCP SYN packet to its port 465 but sends nothing back, then it's the server's own firewall that is likely to be blocking the packet instead. (Received packets are captured before the target system's firewalls such as iptables have a chance to drop them – though, of course, after all intermediate firewalls.)

grawity
  • 501,077