Port forward reverse SSH

Hello - how is it possible to port forward a reverse ssh tunnel to devices on the lan?

For example, i can reverse SSH to the router itself, allowing me to connect to port 22 on the Openwrt router. This is because :22 is open on the router itself, and it establishes the connection.

I want to create a reverse SSH tunnel to :5555 and forward to a lan ip>:443

When I try to do this, reverse SSH is causing it to try to connect to router>:5555 which is not listening, and sends a reset.

I have tried port forwarding, but it seems like I need a "local" zone to make it forward to LAN zone and masquerade, but there is no such option in the port forwarding in LUCI

I'm not following... what host is trying to connect to what device and where from and to? for example:

  • linux host on LAN > ssh to router
  • host on internet > ssh to router
  • host on internet > ssh to host on lan
  • router > ssh to host on lan

host on internet > ssh to router

That host on internet then creates a reverse SSH tunnel on the router for port :5555 with a command line this:
ssh -N -R root@

so sees an incoming connection to :5555 through the SSH port so I end up with this kind of thing in my tcpdump

 00:00:00.000000  In 00:00:00:00:00:00 ethertype IPv4 (0x0800), length 76: > Flags [S], seq 1337871935, win 65495, options [mss 65495,sackOK,TS val 22572588 ecr 0,nop,wscale 4], length 0
 00:00:00.000118  In 00:00:00:00:00:00 ethertype IPv4 (0x0800), length 56: > Flags [R.], seq 0, ack 1337871936, win 0, length 0

what I want it to do is forward that :5555 connection to a LAN device.

I think the problem is in Luci, when I go to port forwarding rules, I can not select "local" or something to indicate the traffic looks like it is originating from the device itself, not from WAN or LAN.

is the end goal that a host on the internet would be able to connect via ssh to a host behind your router?

Well, not SSH, but yes, a service running behind the router. I.E. I want to port forward 5555 to landevice>:5555

Honestly, the easiest way to handle all of this is to simply setup a VPN... you'd connect from your remote location to your router via VPN. once that tunnel is established, it'll be very similar to being on your network (although you'll still be routed)... I'd recommend Wireguard as an easy to setup VPN solution.

1 Like

I saw that there are other solutions mentioning a VPN, and creating a zone for the VPN interface, but I do not have that option. I was hoping someone could chime in with the equivalent iptable PREROUTING type of instruction - as I believe this uses nftables now and I am not quite sure how to do that.

why not? You don't necessarily need to create a new zone... but what is stopping from doing that or anything else with wireguard?

VPN traffic is not allowed, but SSH tunnel is allowed.

not allowed by port restrictions or DPI?

DPI or I would just change ports


I'll have to bow out now because I don't know much about ssh reverse tunneling (just never really needed to utilize it). Sorry. I'm sure others will see this thread and be able to jump in to help.

I don't think you are correctly applying SSH tunneling.

ssh -R bindaddress:PORT:remote causes the ssh server to listen on bindaddress:PORT, tunnel those packets to the remote client, and it is then the client that tries to connect to remote to send those packets on to.

You have a service that is inside the LAN and you want to connect to it remotely. Correct? Why are you using SSH for this, is it because it's an insecure service?

On the remote device you do this:
ssh -N -L 5555: root@
Then on the same remote device you connect that service's client to localhost:5555, which will get tunneled through the ssh connection to and then resent by the ssh server to There should be nothing you need to do with the firewall in LUCI, as long as the 101.1 can normally talk to 102.1.

1 Like

Edit: I see where you were going with the ssh tunnel comment. my command is ssh -N -R root@ because that is being issued from a device on the 101 LAN.

In this case 101.1 cannot normally talk to 102.1, because they are separated by a wan. Imagine that the tunnel for connecting the devices is between them. I can only SSH to 102.1 and I want devices connected to 101.1 to be able to connect to lan devices behind 102.1

I have started trying to mess with nftables but i dont seem to be able to have any progress:

chain user_custom {
type nat hook prerouting priority -1; policy accept;
tcp dport 5555 dnat ip to

my connections are still returning

 00:00:00.000000  In 00:00:00:00:00:00 ethertype IPv4 (0x0800), length 76: > Flags [S], seq 1343734469, win 65495, options [mss 65495,sackOK,TS val 2791868930 ecr 0,nop,wscale 4], length 0
 00:00:00.000121  In 00:00:00:00:00:00 ethertype IPv4 (0x0800), length 56: > Flags [R.], seq 0, ack 1343734470, win 0, length 0

And when I tcpdump with tcpdump -n -e -ttt -i any host
I do not see any traffic captured. Is this something to do with not being about to pre-route on the local interface?

Ok, so 101 and 102 are separate LANs separated by WAN. 102 contains the server. You want to allow devices on the 101 subnet to communicate over WAN to server on 102 net?

1 Like

Yes, correct. I updated the previous post as well.

Shouldn't need any nftables support.

On 101.1:
ssh -L 5555:192.168.102.X:5555 root@
Where X is the 102 LAN address of where the server is.

No further forwards or firewall rules required on 101

On 102, you need to allow inbound ssh connections from the WAN. Using LuCI or editor, alter /etc/config/firewall to add:

config rule
	option name 'Allow-External-SSH'
	option proto 'tcp'
	option src 'wan'
	option dest_port '22'
	option target 'ACCEPT'
	option enabled '1'

Any local LAN connections on 101 LAN to 101.1:5555 will be tunneled to 102.1 which will resend to 102.X:5555. No forwards or nftables rules should be required for this, as long as 102.1 can see and talk to 102.X.

1 Like

Sorry, I have just had another thought (must be getting tired). Is there any way to make my intitial SSH tunnel that I am establishing with the openwrt router to provide a virtual tunnel interface? does dropbear or some other package support that? I am wondering if that would help me create a routeable interface and solve some of these problems.