ssh refusing connection

[KenJackson]

Still no joy from inside the network, to outisde, to inside using ssh. Outside to inside works fine.

The only people that SSH into my PCs are me. Therefore I don't use port 22--I choose a high port and change the Port line in /etc/ssh/sshd_config and set the default port for all my machines in each ~/.ssh/config file.

The benefits are two: my ISP can't easily determine that I have an SSH server on the network, and evil-doers can't easily determine that I have an SSH server on the network.

Maybe your ISP is doing something that blocks you. Maybe a different port will work. I just tried--I can get in from inside with the outside IP address.

[jledhead]

correct me if I am wrong, but if you are port forwarding and inside the network, isn't it expected that you can't hit your external ip? and why would you want to, your internal, use the internal address

we have lots of stuff that is accessible outside but has to be access differently inside the network. dns makes this easy though. same namespace but outside gives a different ip then inside.

correct me if I am wrong but I am pretty sure I have seen this and its normal.

[snork]

Ken,

Thanks for the reply. I'm well aware of not having ssh on port 22. As I mentioned in my first post, I've tried numerous ports with no success. I'm currently trying with port 22 because it reduces the possibility of errors on my part and Cox is not blocking it.

jledhead,

To the best of my knowledge, port forwarding is for 'incoming' packets, not outgoing. Therefore, it really has nothing to do with outgoing traffic.

So, you're saying that you think it's normal that I cannot access my 'server' computer on port 22 (ssh) using the site IP, from within the network. In other words, I have two computers side by side. One is the server that the routers are forwarding port 22 to. On the other one, I can easily login with ssh using the internal IP of the server computer. BUT, I cannot login from the second computer by using the ISP supplied IP for the cable modem that both computers are hooked to.

Way deep in the back of my brain, I 'think' I remember many, many years ago having hit this problem, but if this is true, I would think there would be much more forum questions about this problem. And, as Ken pointed out in the previous post, he has no problem doing just that.

I can't see why you couldn't do it. I have no iptables rules on either computer. I'm forwarding port 22 on the router to the server computer. Someone from outside the network can, in fact ssh into it without problem. Why then can't I use the same IP that the person outside the network use and login with ssh to the server?

I just want to be able to test this, that's why I'm doing it. This has nothing to do with any production system. I just want to make sure people from outside the network can ssh into the server and I would like to test that somehow. So far, I have not been successful at it. I can't figure out why.

I think I've explained my entire setup throughout the posts, and what I've tried. The one major problem was that I had 3 older routers that for some reason didn't forward port 22 to the server. After buying a new one, that problem was solved, but I still can't test the WAN IP using ssh.

I'm open for ANY suggestions on how to troubleshoot this. I don't want to settle for someone else outside the network having to test this when I should be able to do it from within the network. All I ask is that you read my previous posts so you're not suggesting something that I've already tried, unless you think I should check it again for some reason.

[HROAdmin26]

Why then can't I use the same IP that the person outside the network use and login with ssh to the server?

No, a good/smart router will NOT "forward" packets that originate from "inside" your network thru the internal interface, to the external interface, and then back thru the internal interface again.

If you write an iptables script, an almost automatic rule is "drop packets if they say they originate from internal IP range but come in through the external NIC." This is the SAME thing. You have packets coming from "inside" your network that are then being forwarded back in the external interface. So why would a common rule like this be desirable for an iptables router and not for a Linksys router? (Which is running Linux/iptables anyways.) There are forms of address spoofing that work along these lines.

You can do more reading on how networking works and/or collect some packet captures. That will TELL you exactly what is going on vs. "guessing" on what you think is/will happen.

[snork]

HROAdmin26,

Thanks for the info. I don't do networking for a living, and I don't want to become a network expert. The little I picked up over the years, has allowed me to 'get by' when it comes to networking. I do have lots of books, manuals and white papers on networking, which, over the years, I have read some of. To become a network expert takes a lot of time and effort.

There are network experts out there that can and do help not-so-experts like myself, thankfully. I've enjoyed a long experience with the Linux/Open Source community and have both taken and given over the years.

What took most of my time in trying to figure out the solution to my original problem was hard to believe that I had 3 bad routers, that could not forward a port properly. I have since remedied that and seem to have another simpler problem. When this happens, I usually turn to the experts and ask for help.

So, with that in mind, and what you say, is there a way to do what I want to do?

That is to test the capability of my server to accept ssh logins from internet users, but do it from within my network.

Pardon my ignorance, but I have no iptables rules whatsoever on either machine right now. I don't see anything the the router configuration screens that has anything to do with outgoing traffic, so without being a network expert, I don't see what would be blocking what I am trying to do in this situation and I sure as heck don't see anything I can change to remedy this (even if its only for a short time to test stuff).

With your knowledge, it sounds like you might know the answer to this and I would forever be in your debt.

[HROAdmin26]

(Which is running Linux/iptables anyways.)

Your "home router" blocks some traffic and accepts others - this means it has an internal list of "rules." Some you can modify - some are built in. The rule you have an issue with is "built in." Most of these "home routers" run Linux and use iptables internally. You also didn't tell the router to "allow" all outgoing traffic or "block" all incoming traffic, but it is doing both by default.

If you write an iptables script, an almost automatic rule is "drop packets if they say they originate from internal IP range but come in through the external NIC." This is the SAME thing. You have packets coming from "inside" your network that are then being forwarded back in the external interface. So why would a common rule like this be desirable for an iptables router and not for a Linksys router?

It is almost "standard" practice when making your *own* firewall/router using iptables to block the type of traffic you are seeing blocked by your router.

So, with that in mind, and what you say, is there a way to do what I want to do?

Knowing the router is not going to pass internal traffic out and then back in, then for you to successfully "test" this way, you would have to "spoof" your traffic and make the router think it originated from outside your network. If you could do that easily, then your router would be a miserable defense against this type of attack. I don't think you want to find that is the case.

You can connect to an external machine, and then create a new connection back into your network to test. (SSH to an external machine, then SSH back in or use a telnet client to see if the required ports are open.)

If you know of/have access to a proxy server external to your network, that would probably work as well. You could also look at one of the security sites where you ask it to scan your router and verify what ports show as open.

[snork]

HROAdmin26

It seems in the olden days, you could do this easily. I guess that's why I thought it could still be done.

Your explanation is simple and clear. I thank you for that. I have done what you suggested in the past, about logging into a remote computer then back into one in a network that I'm on. I know that works well.

I did and do use grc.com to scan ports to determine which ones are open/closed/stealth. It's a great tool. In fact "ɹǝpɹosıplɐɹǝuǝƃ" from above suggested to use it to see which ports are open. This helped solve my port forwarding problem.

Again thank you and everyone for their help. It's people like you that make the world a better place.

p.s. I can't figure out how to edit the first post to mark it as 'solved'.

[warp4ever]

My response is a bit late, but as said:
You can't approach a LAN ip trough a WAN ip on the same network.
You will always end up at the router login.

Use a browser and goto your WAN IP xx.xxx.xxx.xx and you will be asked for a login name and a password.
Try this through a proxy server and you'll get in.