On 04/02/2019 06:24 PM, Patrick Shanahan wrote:
Oh, are you running ipv6? it is enabled but not knowing enough about ipv6, I use ipv4 for internal net commands.
I mentioned ipv6 because I've seen rogue router announcements siphon off traffic to bit-buckets. For example, users used to be able to turn on Internet Connection Services (ICS) on Windows boxes, which allowed the boxes to advertise themselves as v6 routers. But the packets would just disappear. This manifested itself as failed ssh connections. ssh tries v6 addresses first, falling back to v4 if the server rejects the v6. But the rejects would never return with a bogus router on the subnet. In this case, "ssh -4 hostname" would work. I don't think this is your problem though.
Of course, things become more complicated if Windows are involved. All the machines are running Linux, right? there are windows machines on the net but not involved. afaics the*only* difficulty is between workstation 192.168.1.10 and the server 192.168.1.3 and stopping the server firewall allows ssh from workstation to succeed.
So try an nmap from client to the server, once with the server's firewall on, and once with it off. If nmap shows port 22 open with the firewall on, but "telnet 192.168.1.10 22" fails, then you've got a really interesting problem! You might also try "ssh -v 192.168.1.10" and see if you can find where it's failing. You could try this both from a working client, and the bad one. Could the server's firewall, which apparently has multiple Ethernet ports, be forwarding traffic off-network? Maybe just return packets? Some kind of a loop? What does "ip addr" and "ip route" have to say? When all else fails, maybe it's time to break out tcpdump or wireshark to see exactly what's coming and going. Carlos also has a point about the wahoo.no-ip.org name resolution. What does your /etc/resolv.conf look like? And /etc/hosts? Regards, Lew -- To unsubscribe, e-mail: opensuse-support+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-support+owner@opensuse.org