1. This site uses cookies. By continuing to use this site, you are agreeing to our use of cookies. Learn More.

Minor bug: No SSH remote access

Discussion in 'Tomato Firmware' started by Porter, Jan 12, 2014.

  1. Porter

    Porter LI Guru Member

    I just tried to enable remote access by SSH. I'm on Tomato v1.28.7634 Toastman-IPT-ND ND Std.
    For some reason no one from the outside saw the open port 2222. After disabling the "Limit Connection Attempts" further down it worked.

    This is what the iptables-rules look like on my system:

    root@unknown:/tmp/home/root# less /etc/iptables | grep shlimit
    -N shlimit
    -A shlimit -m recent --set --name shlimit
    -A shlimit -m recent --update --hitcount 4 --seconds 60 --name shlimit -j DROP
    -A INPUT -p tcp --dport 22 -m state --state NEW -j shlimit
    -A INPUT -p tcp --dport 2222 -m state --state NEW -j shlimit
    -A INPUT -p tcp --dport 23 -m state --state NEW -j shlimit
    Somewhere on tomatousb.org somebody said it went away after rebooting, but I didn't try that. I just needed remote access for this one time.

    As I understand the iptables-rules this should allow for 4 connection attempts every 60 seconds on each of the mentioned ports. I just can't imagine that all those attempts were already made when I opened port 2222. What I can imagine, though, is that for some reason the rules are not being jumped to. But that seems unlikely since the chain shlimit sees traffic.

    What's a bit strange is something else, too: In the GUI it says "3" connection attempts, but iptables says "4".

    Maybe somebody has an explanation.
  2. koitsu

    koitsu Network Guru Member

    I'm not even going to try to figure out what you're doing with all of that. I even see you're messing around with telnet (port 23) without mentioning it in your post.

    If all you're trying to do is, effectively, redirect connections to TCP port 2222 (on the WAN) to port 22 internally (e.g. on the router itself) so that from the Internet you can do ssh -p 2222 user@yourwanip and get SSH access to your router, then it's as simple as 2 rules:

    iptables -t nat -A WANPREROUTING -p tcp --dport 22 -j DNAT --to-destination :2222
    iptables -A INPUT -p tcp --dport 2222 -j ACCEPT
    And that's all.

    This will not open up port 22 on the WAN (i.e. connections to port 22 on your WAN IP will result in a timeout; in other words, 2222 will work, but 22 will not). And this will not affect connections on your LAN (LAN connections to the router via SSH should still be done on port 22).

    If your router is set up in some weird way with other interfaces (ex. VPN, PPTP, possibly even PPPoE), then this may not be precise enough and you should instead use:

    iptables -t nat -A WANPREROUTING -p udp -d `nvram get wan_ipaddr` --dport 22 -j DNAT --to-destination :2222
    iptables -A INPUT -p udp --dport 2222 -j ACCEPT
    I strongly recommend you do not open telnet (even on an alternate port) across the Internet. It's a plaintext protocol, which means your root password will be in plaintext. Stick with SSH.
  3. Porter

    Porter LI Guru Member

    Thank you for your time. I'm sorry, maybe I should clear something up: All I did was go to Administration/Admin Access and under SSH Daemon enable 'Remote Access'. I didn't add any iptables-rules myself. No port-forwards or redirects, nor anything in shlimit. Otherwise this would have been my fault and not the one of the firmware.

    Telnet doesn't even have an option to be made remotely accessible. I should probably disable it locally anyway.

    What I think about this right now is that something within the restart mechanism of the daemons probably doesn't work very reliably or just takes a random amount of time to be successful because even getting back local ssh access did take some restarts of the service via the GUI.

    Well, anyway. Just wanted to let people know, just in case somebody has already seen this behaviour.
  4. koitsu

    koitsu Network Guru Member

    Ah, I see what you're saying now.

    You're saying that the Remote Access checkbox works just fine, unless you also enable the Limit Connection Attempts checkbox, after which the "remote access capability" no longer works.

    Agreed -- I would classify that as a bug. :)

    The cat /etc/iptables | grep shlimit you did, however, isn't precise enough to help troubleshoot. You need to provide the full contents of /etc/iptables, I'm sorry to say. If you have private stuff in there you don't want the world to see, then the issue should be discussed with a firmware author directly/privately.
  5. quinezhu

    quinezhu Addicted to LI Member

    That means the actual listening port is 2222. Both the access from WAN via port 2222 and the one from LAN via port 22 (which would be redirected to 2222) are allowed.

    Is it possible to keep the actual listening port 1688, then both the access from WAN via port 8861 (which would be redirected to 1688) and the one from LAN via port 1688 are allowed?
  6. koitsu

    koitsu Network Guru Member

    This is the first mention in this thread of numbers 1688 or 8861.

    Wrong thread?
  7. quinezhu

    quinezhu Addicted to LI Member

    Sorry for the confusion. It doesn't matter about SSH. I have a listening port 1688 on a tomato router with kms svr installed, and just want the port like 8861 opened for WAN connections.
    Last edited: Oct 18, 2014
  8. koitsu

    koitsu Network Guru Member

    Okay, so what's hard about changing the above rules I gave to accomplish that? I.e.:

    iptables -t nat -A WANPREROUTING -p tcp --dport 1688 -j DNAT --to-destination :8861
    iptables -A INPUT -p tcp --dport 8861 -j ACCEPT
    I'm having to make a lot of assumptions about the protocol used and if you have some weird interface setup, but otherwise see my previous post for an explanation.
  9. quinezhu

    quinezhu Addicted to LI Member

    THX for you reply.

    These two lines doesn't work after I applies the command of "cscript ospp. vbs/setprt: 8861" except that I change them with the following two lines
    iptables -t nat -A WANPREROUTING -p tcp --dport 8861-j DNAT --to-destination :1688
    iptables -A INPUT -p tcp --dport 1688 -j ACCEPT
    Then the command will be OK. But in this case the listening port 1688 (can not be changed to 8861) will also be opened for WAN connections.

    Any way, thanks for your help.
    Last edited: Oct 20, 2014
  10. Bird333

    Bird333 Network Guru Member

    Your rules should work. Small correction from above, your lan connection from port 22 would not be redirected to port 2222. The WANPREROUTING chain only affects connections coming from the WAN.
  11. quinezhu

    quinezhu Addicted to LI Member

    Is it possible to disable the port 1688 (and enable 8861 only) opened for the WAN connections? I've installed kms svr on tomato and can not change the default listening port 1688 to the other number.
  12. koitsu

    koitsu Network Guru Member

    Okay, I'll rephrase this (for a 3rd time? Not sure): the rules I provided you will do the following:

    1. Allow LAN TCP connections to {routerLANip}:1688 to continue working as normal (such packets won't hit these rules, believe it or not)
    2. Allow WAN TCP connections to {routerWANip}:8861 to work (they will get transparently forwarded/rewritten to hit TCP port 1688, but clients from the Internet won't know the difference)

    The rules I provided WILL NOT allow WAN TCP connections to {routerWANip}:1688. It can't/won't happen due to how the existing firewall rules (not the ones I gave you) work.

    Both @Bird333 and myself can confirm this, and tons of other users have said the same thing (in this thread and others).

    cscript is a Windows thing and has no relevancy to what we're discussing, so whatever it is you're doing is not being made clear. It sounds like you're writing some Windows-based script that telnets into the router and executes some commands (why you're doing that I do not know, that's your business + your problem). And that's great, but what we're telling you is that the rules I gave you will do exactly what I described above.

Share This Page