I’m on Fedora 19 and I have a problem with ssh.
Ssh is up and running and I can connect when I enter my lan ip. But when I try my server name (blahblah.no-ip.org) I get a connection refused. No-ip is already running as a service and is working properly (sending the correct ip).
I’ve already set up port forwarding on my router, I also changed the port of ssh both on the service and on the router port forwarding (in case my beloved ISP decided to block those ports). But still I get a connection refused and when I nmap the hostname I see that the ssh port is closed.
One thing though: I have two PCs under the same external ip (I’ve set up the port forwarding to the correct internal ip). When I nmap blahblah.no-ip.org I get a Port 23 and 80 open. 80 seems OK but I’ve never started telnet service on my machine.
Any ideas what else to try? Router is zte zxv10 and port forwarding is correctly set up. I say this because I’ve already set up port forwarding for deluge and it’s working properly.
Answers:
Thank you for visiting the Q&A section on Magenaut. Please note that all the answers may not help you solve the issue immediately. So please treat them as advisements. If you found the post helpful (or not), leave a comment & I’ll get back to you as soon as possible.
Method 1
It’s not possible to connect to a port-forwarded public IP address from inside the same LAN. To explain this, I’ll need an example.
Let’s suppose your router’s private IP is 192.168.1.1 with public IP 10.1.1.1. Your server is on 192.168.1.2 port 2222. You set up port forwarding from 10.1.1.1:1111 to 192.168.1.2:2222.
If somebody on the Internet (10.3.3.3) wants to talk to you, they generate a packet:
Source: 10.3.3.3 port 33333 Dest: 10.1.1.1 port 1111
Your router receives the packet on 10.1.1.1 and rewrites it:
Source: 10.3.3.3 port 33333 Dest: 192.168.1.2 port 2222
Your server receives that packet and sends a reply:
Source: 192.168.1.2 port 2222 Dest: 10.3.3.3 port 33333
Your router receives that packet on 192.168.1.1 and rewrites it:
Source: 10.1.1.1 port 1111 Dest: 10.3.3.3 port 33333
And the connection works, and everybody is happy.
Now suppose you connect from inside your LAN (192.168.1.3). You generate a packet:
Source: 192.168.1.3 port 33333 Dest: 10.1.1.1 port 1111
Your router receives the packet on 10.1.1.1 and rewrites it:
Source: 192.168.1.3 port 33333 Dest: 192.168.1.2 port 2222
Your server receives that packet and sends a reply:
Source: 192.168.1.2 port 2222 Dest: 192.168.1.3 port 33333
Here’s where we hit a problem. Because the destination IP is on your LAN, your server doesn’t send that packet to the router for rewriting. Instead, it sends it directly to 192.168.1.3. But that machine isn’t expecting a response from 192.168.1.2 port 2222. It’s expecting one from 10.1.1.1 port 1111. And so it refuses to listen to this “bogus” packet, and things don’t work.
The way I get around this is to configure my router (which also provides DNS for my LAN) to return my server’s private IP address when I look up my DDNS hostname. That way, when I’m on my home network, I connect directly to the server and skip the port forwarding. (This solution only works when your port forwards aren’t changing the port number, just the IP address. And you can only have 1 server per public hostname.)
Method 2
Ports 23 and 80 open are because for connection to your router, port 23 to telnet to your router and port 80 to have your WebUI of your router. Since only these two are open port-forwarding is not in the picture. So a router restart and your SSH server restart will help.
All methods was sourced from stackoverflow.com or stackexchange.com, is licensed under cc by-sa 2.5, cc by-sa 3.0 and cc by-sa 4.0