5

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.

  • 2
    Are you connecting to the same IP address that blahblah.no-ip.org resolves to? I get the impression you're trying to connect to your port-forwarding public IP address from inside your LAN. That doesn't work. – cjm Dec 11 '13 at 6:57
  • Well i'll be damned! I didn't know that i can't connect to my public IP from inside the LAN.. Can you briefly explain why this doesn't work? In other news, i tried to connect from another pc (other ip) to ssh and it worked, so problem solved! – nixxer Dec 11 '13 at 7:05
9

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.)

0

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.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.