In v3.27 is not working ssh port forwarding functionality (or not allowed in ssh service), experienced on RB433AH. By ssh port forwarding I mean tunneling TCP connection trough SSH session to Mikrotik router. For example (in terminal on Linux desktop):
ssh -L 8291:localhost:8291 admin@my-mikrotik;
After that trying winbox on localhost:8291 will not work and on ssh console is printed “channel 3: open failed: administratively prohibited: bla bla”.
Similar with
ssh -L 2222:OtherMikrotik:22 admin@my-mikrotik;
Ssh port forwarding is working in v3.22 and previous versions (did not try version between v3.22-v3.27). CHANGELOG_3 does not show any record about changing this feature → looks like a bug.
I’m experiencing same problem in 3.27 and 3.26. It works in 3.25 and older versions.
This feature is great to fast access remote network devices behind nat without classic port forwarding. I used this feature with ssh client putty. There is item Connection-SSH-Tunnels in menu of putty which is not working now.
Thank you for repairing in comming version of RoS.
From personal experience (IPv6 over PPPoE), I know how frustrating it is when features you rely on are removed with no notice and no apology, however, there is no justification for abuse at all - it doesn’t help things, it just upsets the people who you really don’t want to upset. What happens the next time you have a query? Why should they bother replying to somebody who abuses them? As I have found with the IPv6/PPPoE issue, Mikrotik simply ignore any topics in which they have been (mildly in this case) abused.
That having been said, Mikrotik’s release notes leave a lot to be desired and there really should have been some mention of changes to the SSH subsystem (if, indeed, there was one) and the reason for these changes.
I also agree that it can be frustrating that older versions of the software are not available. I strongly suspect that Mikrotik would supply any older version if you didn’t have it yourself, however having all versions on-line would be a nicer way of doing things. as the number of RBs we have increases, I think I will start archiving all the firmware (in all versions) just in case. It would have been sensible of me to have started doing this a long time ago.
Nick, over 50% of all technical support email question are fixed by simple upgrade. If people would just use the latest version, we would solve a lot of delays in email responses. In new versions there are certainly more fixes than issues. It’s obvious that new versions are released to improve older ones, and if people don’t use them, we can’t fix their issues. This is why we don’t advertise any old version archive, and this is why we have one older version listed (v3.13) so you have a fallback possibility in case of a sudden problem.
That may well be the case, but it wasn’t the point I was making.
I am surprised at your response though - I was trying to offer a measured post in response to the OP’s abusive language and tone which I found offensive and quite unnecessary.
However, I am puzzled why you suggest that everybody should be using the latest version when some features (e.g. IPv6/PPPoE) have been removed, forcing users to stay with older firmware versions. Unfortunately, the problems with the latest 3.x releases have certainly caused me to be more reluctant to immediately upgrade all our RBs as I simply don’t know what will work and what won’t any more.
Given the recent problems, I don’t think it is unreasonable to expect users to hang back one or two releases from the latest version just in case.
again - just so everyone knows, ipv6 over pppoe was NOT a feature. It just so happened it worked. It was not something they added on purpose. It broke encryption on certain PPP tunnels > 1280 MTU and so they disabled it. You could be running a tunnel unencrypted without knowing it. I would rather they have fixed the PPP code and not just disabled ipv6 over tunnels, but they must have their reasons.
Anyone else that needs ipv6 over a tunnel (l2tp, pptp, ipip, pppoe, etc) please just post to the original thread and ask for it to be fixed.
Normis, yes, RouterOS would do ssh tunneling probably because its just built into the ssh daemon. Sometimes a handy feature to have for a simple winbox or ssh redirect.
Understood, but given that other products support IPv6/PPPoE, that there is at least one RFC stating how it should work and that it did work (your point on encryption is also understood), I think it is fair to assume that it was a feature of RouterOS. Simply removing it and then writing everything which was said in the thread (I’ll not rehash it here) was, in my opinion, out of order.
To be clear, I understand why IPv6/PPPoE was disabled, I just don’t happen to agree with the reasons, nor with the opinion that I shouldn’t have been using it in the first place.
Anyway, that’s the last from me on IPv6/PPPoE in this thread. I didn’t want to discuss it here and was just using it as an example to try to persuade the OP to curb his abuse a little.
This feature was disabled because it posed a security risk to those, who didn’t know about it. We are making a new SSH package right now, where this feature will be integrated, and will be configurable (ie. you will be able to turn it on if you want).
A security risk? It is a feature that does not work unless you are actually connected to the router using SSH, which means you already authenticated.
Anyway, if you want to be paranoid about security, make it disabled by default, but configurable.
SSH port forwarding is THE swiss-army-knife of network admin, and having that in mikrotik has been the reason to replace lots of routers with mikrotik hardware.
On the other hand, this brings up the issue of “ChangeLog” being quite bogus, as a modification in the configuration of sshd (or dropbear) should be announced there.
Hello,
that feature wont be added back as it is grate security risk to your network.
Instead you should create dst-nat rules to forward ports and then you will be
aware that nat for that prot+host exists and you have to secure it. That Also
gives more power to create different policies using firewall filter, and thus,
results in more secure and safe network.
I would say it’s more secure than port forwarding+firewalling as MT suggest as an alternative.
First, we use firewall with ssh, (which I think should default with MT), so I can compare SSH with port forwarding+firewalling with respect to security.
Essentially, the goal could be done with either SSH or port forwarding. The SSH is authenticated with an ssh key, which is a very secure method of connecting. Port forwarding, no authentication.
If SSH isn’t safe in MT, it should be made so, and the tool for doing that is the firewall. OpenSSH has a LOOOONNNNNGGG history of security problems, and I’ve been adminning through most of it, so I have always kept SSH firewalled so that our servers are protected from ssh probing. It has been much better in the past couple years, but I feel better about people not probing my ssh. You see it all the time on MT if you don’t control access to ssh with firewall. It will fill up your logs.
Since newbies will use winbox most likely to access the router they’d be unaffected, something like this would go a long way to make MT more secure out of the box.
ip firewall filter
add action=accept chain=input comment="change src-address or duplicate for additional subnet to allow local lan admin" disabled=no dst-port=21-23 protocol=tcp src-address=192.168.0.0/16
add action=reject chain=input comment="disable to allow ssh/ftp/telnet from internet" disabled=no dst-port=21-23 protocol=tcp reject-with=icmp-network-unreachable src-address=0.0.0.0/0
Hello,
that feature wont be added back as it is grate security risk to your network.
Instead you should create dst-nat rules to forward ports and then you will be
aware that nat for that prot+host exists and you have to secure it. That Also
gives more power to create different policies using firewall filter, and thus,
results in more secure and safe network.
Dear Mikrotik,
As your humble user, I’d like to take liberty to remind You a very well known quote: Guns don’t kill people, people kill people - ssh port forwaring is no to be blamed, but unqualified admins. Like we don’t switch off php in apache if there is some unescaped sql queries which drop your databases? or do you?
That would be fine, disabled for unaware, enableable for ones who need it.