Outside LAN ssh into leap 15.6 - connection timed out

Hi SUSE community,
this is my first post here!

I’m new to SUSE’s Leap distribution but I know my way around using other Linux distributions(Debian, Ubuntu, Fedora, Arch).
I’d like to ask the community to help me figuring out my configuration problem I have with a brand new installed, console only Leap 15.6

The closest topic here to my problem is this : Remote ssh = Connection Timed Out. Difference is my ISP doesn’t filter anything.

I’m going to recap what I did:
a) I’m able to connect from any machine inside LAN,
b) firewalld is stopped,
c) even FW is stopped, I checked iptables input chain( is empty ):
Chain INPUT (policy ACCEPT)
target prot opt source destination
d) apparmor stopped,
e) /etc/hosts.allow/.deny both empty(I commented anything),
f) default /etc/ssh/sshd_config - nothing I changed there

Funny thing is, on that machine, before Leap I had an Ubuntu server that I could connect to from outside. I didn’t mentioned, I didn’t change anything on the router(forwarding rule is untouched). I fired up a Leap 15.6 KDE Live USB on that machine and I can connect there.

I’m out of ideeas.
What do you make of this ?

Are IP addresses and other network configuration identical on all three systems?

All devices have unchanged network configurations since before install. New machine, the one having Leap 15.6 has the same IP as Ubuntu server(that is the same IP before OS install).

So, run tcpdump or tshark or wireshark or dumpcap or whatever packet capture tool you are comfortable with, try to connect and check whether you see any connection request at all. If in doubt, provide binary capture file to check.

First of all,
thank you very much for answering so quick and for your time !

I can see them landing on the interface

How to continue debugging from here.
Something decides to drop these packets before they reach sshd.

Maybe I cropped the screenshot too much. It says:
5 packets captures
7 packets received by filter
0 packets dropped by kernel

Have you checked the log?
See the output of a connection with ssh -v.
Are you trying to connect with root user?

Are you kidding? All you show is some scrambled text with unknown filter applied to packet capture. Assuming what is visible indicates connection requests - you apparently have something that drops them. Check your netfilter rules (and “netfilter” is not limited to iptables). Start with checking nftables.

a) checked the logs but couldn’t find obvious errors messages. I’m not ruling out overlooked as unimportant misconfiguration warnings, though.
b) ssh client output - see below(just con timed out)
c) no, I’m not using root to ssh into that box.
d) the machine is headless - I don’t have a monitor attached. I’m ssh-ing from LAN; this is why I applyed a filter:
sudo tcpdump -i eth0 ‘not (src client_lan) and not (src sshd) and port 22’
e) sudo nft list tables - has no output whatsoever.

That machine is a diy NAS.
The install included sshd and I changed networking from wicked to NM
After install, I added nfs&friends, samba, zfs, Apache and Docker.
Docker added a bridge but also added no less than 4 iptables chains but I doubt these interfere with sshd.

It’s obviously something between NIC and sshd, possibly something I did after clean install. I guess, my next move should be a reinstall and right after test ssh connection. Then add whatever I need to, test after each install and figure when something interferes.

Thank you all for your messages!

There are no miracles. Something drops or redirects ssh traffic. Troubleshooting it requires the exact configuration. As long as you are not willing to show it, that leads nowhere.

I have no idea what sshd means here, but it sounds like it will exclude traffic from sshd itself which makes this capture rather useless. If you need to restrict, just restrict based on the client address (from where you try ssh).

It’s working after a reinstall. I changed two settings:
a) change AppArmor->none at security,
b) ip forwarding at networking.

I don’t understand the ramifications though. I probably could have made those two changes from old install with the same effect.

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.