TR Forums

I have a raspberry pi at home which is behind a DD-WRT (build 18702) router. The Pi is running a ssh server on 192.168.1.137 port 22, and the router is directly connected to the internet. When I set up NAT from any chosen port on the WAN interface to the raspberry pi's IP address, the port will show up as "filtered" in nmap scans of my router's WAN IP. However, when I try to ssh in, like "ssh root@wanip -p 5000" the connection times out even though the port has clearly been opened, sshd is running on the Raspberry Pi.

So it looks like NAT is working properly on DD-WRT, but somehow it's still not reaching sshd on my raspberry pi. Where do I go from here?

Have you ssh'd in from inside your LAN? If so, it's definitely the router. If not, it's your sshd configuration.

Yes, I can ssh into 192.168.1.137. If it's "the router", what can I do? I told it to log all dropped, accepted and rejected packets, and when I tried to ssh in with the right port, it doesn't mention it.

It may not be your router or your RPi, some ISPs are now filtering/blocking inbound port 22, along with 80, 443, 8080, etc.

I personally have my SSH on another, high port, with the router doing full NAT from $HIPORT<->22 when it passes the router, in and outbound.

hey something funny happened. Apparently it takes a few minutes before the kernel gets the new routing instructions. I'm now able to ssh into my Pi from a VPS that I have, but I cannot ssh from another PC on the same LAN as the Pi to the WAN IP on the router and have it forwarded to the Pi. That always times out. What gives?

Forge wrote:

I personally have my SSH on another, high port, with the router doing full NAT from $HIPORT<->22 when it passes the router, in and outbound.

What do you mean, outbound? Why is there a need to NAT outbound?

Crayon Shin Chan wrote:

Forge wrote:

I personally have my SSH on another, high port, with the router doing full NAT from $HIPORT<->22 when it passes the router, in and outbound.

What do you mean, outbound? Why is there a need to NAT outbound?

Coming in, it converts the request from webside for $externalIP:Hi-number-port to $internalIP:23

Going out, the reply to $foreignIP:23 gets mangled to $foreignIP:Hi-number-port again.

It fully bypasses ISP filtering with the port conversions being done on the router, not the client.

Crayon Shin Chan wrote:

hey something funny happened. Apparently it takes a few minutes before the kernel gets the new routing instructions. I'm now able to ssh into my Pi from a VPS that I have, but I cannot ssh from another PC on the same LAN as the Pi to the WAN IP on the router and have it forwarded to the Pi. That always times out. What gives?

I would imagine that your router doesn't like LAN traffic to the WAN IP. You can get around this rather simply via hosts/local DNS/etc.

If the port is showing up as "filtered" in the scans then you likely haven't configured the port forward correctly. It should show as "open" if the forward is configured correctly and the target of the forward is accepting connections. You've verified that the target accepts connections, so the finger is pointing at the port forwarding configuration on your router.

Edit: Never mind, didn't read the entire thread carefully enough.

Edit 2: Forge is on point with regards to the local access. You need to use the local LAN IP if you are trying to access from inside the LAN.

Crayon Shin Chan wrote:

I cannot ssh from another PC on the same LAN as the Pi to the WAN IP on the router and have it forwarded to the Pi. That always times out. What gives?

I've never used DD wrt but the feature you're looking for is "nat reflection" or "nat loopback", could be it's something you have to specifically enable on your build if it supports it. (or get funky with DNS as Forge suggests.

Also make sure to set up keys on your sshd. Even if the portscanning bots find your random high port, they won't have a chance of getting in without that (password protected) key. Look into fail2ban or denyhosts to automatically ban bots as well.

It's a little weird that you're having problems with port forwarding. It worked right away when I set it up with Tomato; just had it forward from incoming port 3854/tcp to internal port 22/tcp & set up my ssh server with a static IP address.