Access OpenWrt Router From WAN (SSH)

Hi,

I'm trying to connect to the router through SSH for learning purposes. I know that the best way is to connect through VPN and I'm currently trying to achieve this with the help of @ulmwind who I can't thank enough.

Here is what I've tried so far :

  • Redirected the port 22 of the ISP to the port 22 of the WAN address of the router

Set the firewall rule :


config rule
        option name 'Allow-SSH'
        option target ACCEPT
        option src 'wan'
        option dest_port '22'
        option proto 'tcp'
        option family 'ipv4'

I still get the connection refused warnning :

root@OpenWrt:~# ssh root@176.170.xx.xxx
ssh: connect to host 176.170.xx.xxx port 22: Connection refused

Dropbear's config :

config dropbear
        option PasswordAuth 'on'
        option RootPasswordAuth 'on'
        option Port         '22'

So, what am I missing ?

Did you restart the firewall after you set the rule?
service firewall restart
If it still doesn't work verify that you have hits on the firewall
iptables-save -c | grep Allow-SSH
At the beginning of the line the counters [X:Y] must not be 0
If it still doesn't work install tcpdump and see if packets are reaching the router.

opkg update; opkg install tcpdump; tcpdump -i `uci get network.wan.ifname` tcp port 22
1 Like

thank you for this very insightfull help.

I'll try that later and keep you posted

root@OpenWrt:~# iptables-save -c | grep Allow-SSH
[6:276] -A zone_wan_input -p tcp -m tcp --dport 22 -m comment --comment "!fw3: Allow-SSH" -j ACCEPT
root@OpenWrt:~#

It doesn't show a warnnig anymore but ressource unavailable.

I don't have a clue about what the messages at the left mean

It seems that dropbear is not responding to the incoming SSH packets.
Do you see anything in the logs? logread | grep -i dropbear
Try to restart dropbear
service dropbear restart
If this doesn't help do a reboot of the router.

In fact I'm testing through the router itself using a VPN provider connexion. So the connexion go through the router to go out and in again.

Maybe it's the reason why it deosn't work ? I'll try using putty on a phone so that the connexion come really from outside.

What do you think ?

Does it work without OpenVPN connection? If yes, it is the same issue, as with OpenVPN-server.

Look if dropbear is listing on the wan ip?
Maybe dropbear start before the wan interface is up?

That you should have mentioned that from the beginning.
I cannot tell if the VPN is the problem, but most likely it is. You have configured the SSH for access from the internet, so test it accordingly.
If you test from VPN then you should hit the internal IP of the router.

1 Like

Hi @trendy

So I installed Termux on an Android phone.

Here is what happens when I ssh the router :

root@OpenWrt:~# tcpdump -i `uci get network.wan.ifname` tcp port 22 -v
tcpdump: listening on eth0.2, link-type EN10MB (Ethernet), capture size 262144 bytes
13:03:40.557554 IP (tos 0x0, ttl 54, id 40122, offset 0, flags [DF], proto TCP (6), length 60)
    unn-185.246.211-92.datapacket.com.43984 > 192.168.2.20.22: Flags [S], cksum 0xb6d2 (correct), seq 4174284961, win 65535, options [mss 1326,sackOK,TS val 3                 216411 ecr 0,nop,wscale 8], length 0
13:03:41.568798 IP (tos 0x0, ttl 54, id 40123, offset 0, flags [DF], proto TCP (6), length 60)
    unn-185.246.211-92.datapacket.com.43984 > 192.168.2.20.22: Flags [S], cksum 0xb5d5 (correct), seq 4174284961, win 65535, options [mss 1326,sackOK,TS val 3                 216664 ecr 0,nop,wscale 8], length 0
13:03:43.565855 IP (tos 0x0, ttl 54, id 40124, offset 0, flags [DF], proto TCP (6), length 60)
    unn-185.246.211-92.datapacket.com.43984 > 192.168.2.20.22: Flags [S], cksum 0xb3dd (correct), seq 4174284961, win 65535, options [mss 1326,sackOK,TS val 3                 217168 ecr 0,nop,wscale 8], length 0
13:03:47.625627 IP (tos 0x0, ttl 54, id 40125, offset 0, flags [DF], proto TCP (6), length 60)
    unn-185.246.211-92.datapacket.com.43984 > 192.168.2.20.22: Flags [S], cksum 0xafed (correct), seq 4174284961, win 65535, options [mss 1326,sackOK,TS val 3                 218176 ecr 0,nop,wscale 8], length 0
13:03:55.807929 IP (tos 0x0, ttl 54, id 40126, offset 0, flags [DF], proto TCP (6), length 60)
    unn-185.246.211-92.datapacket.com.43984 > 192.168.2.20.22: Flags [S], cksum 0xa7ed (correct), seq 4174284961, win 65535, options [mss 1326,sackOK,TS val 3                 220224 ecr 0,nop,wscale 8], length 0
13:04:11.939271 IP (tos 0x0, ttl 54, id 40127, offset 0, flags [DF], proto TCP (6), length 60)
    unn-185.246.211-92.datapacket.com.43984 > 192.168.2.20.22: Flags [S], cksum 0x982d (correct), seq 4174284961, win 65535, options [mss 1326,sackOK,TS val 3                 224256 ecr 0,nop,wscale 8], length 0
13:04:47.297229 IP (tos 0x0, ttl 54, id 40128, offset 0, flags [DF], proto TCP (6), length 60)
    unn-185.246.211-92.datapacket.com.43984 > 192.168.2.20.22: Flags [S], cksum 0x76ed (correct), seq 4174284961, win 65535, options [mss 1326,sackOK,TS val 3                 232768 ecr 0,nop,wscale 8], length 0

I don't know how to interpret this...

Dropbear doesn't see anything :

root@OpenWrt:~# logread | grep -i dropbear
Sat Feb 29 11:51:24 2020 authpriv.info dropbear[5580]: Exit (root): Keepalive timeout
Sat Feb 29 11:53:43 2020 authpriv.info dropbear[4352]: Exit (root): Keepalive timeout
Sat Feb 29 11:54:03 2020 authpriv.info dropbear[6285]: Exit (root): Keepalive timeout
Sat Feb 29 12:44:50 2020 authpriv.info dropbear[7005]: Child connection from 192.168.1.209:62288
Sat Feb 29 12:44:54 2020 authpriv.notice dropbear[7005]: Password auth succeeded for 'root' from 192.168.1.209:62288
root@OpenWrt:~#

WAN ip is the ISP Box's IP, I did a port forwarding on the ISP Box, see above.

Maybe dropbear start before the wan interface is up?

if this is true I just need to reload dropbear so that it seen the wan interface, right?
Anyway, I reloaded the file but it didn't change anything.

As always, you were right.

When I stopped openVPN on the router (NordVPN) it worked just fine.

So i it means that I need to add a rule that says : don't use VPN for incoming connexion from WAN on port 22 in the VPN Policy routing file, right?

Yes, because router tries to send response via VPN, whereas incoming packet came from WAN. However we are dealing with general PBR. I'll ask here, hope, @stangri will read it.

General question concerning Policy-Based Routing package. We've added simple policy, and router creates additional chain in mangle table:

-N VPR_PREROUTING
-A PREROUTING -m mark --mark 0x0/0xff0000 -j VPR_PREROUTING

Rules, specific for policy, have been created in VPR_PREROUTING. But they don't work, counters remain equaling zero, and we couldn't find rule, where mark 0x0/0xff0000 was set.

1 Like

That you have incoming packets and nothing going back.
It is explained by the asymmetric routing you have because of the vpn client on the OpenWrt, which you didn't mention earlier.

2 Likes

Tried to reply via e-mail and it didn't work.

For services running on the router (VPN server, ssh server, etc), the policies should be created in the output chain.

I believe it's covered in the readme for OpenVPN server setup.

2 Likes

OK, thank you. I admit, that I've tried to configure not by my hands, but the answer seems to be trivial and don't occupied lot of time. Thank you!

It's not a first time I've encountered this confusion. Maybe my decision to not show the output column by default was erroneous. However I figured majority of users would only need prerouting chain and seek additional information in the README. What do you think?

Now we are discussing the same issue. I don't see this column on screenshot from user, and see on screenshot from Readme. I think, it is reasonable to show column explicitly with default value, and not to hide it. Because user asked me, I tried to solve problem by his hands, and in result I am obliged to seek solution to the trivial problem. If column present, I would think about it, and likely have solved the issue myself. I know about OUTPUT, and FORWARD chains in general usage, but now I've encountered with similar issue concerning marking packets.

1 Like

Thank you for your feedback. Let me sleep on this.

OK, now it works. Thank you. Also I want to add, that even in config file there is no chain by default, so user added policy, sent me config, and I didn't know, what to do. In case chain option have been added by default equaling something, it would be better. But in current situation there is obscure 'default' option, not present in config.