I have a problem with The Dude, I need to manage, monitor and even update my mikrotiks with this monitor but I can not establish connection with the device, every time I try to reject the connection throwing this error ("connection timeout (6), next attempt at 15:59:28 ") I have read several forums and also seen tutorials but still the connection is not established.
It should be noted that I am using the correct ports and my devices do not have firewall rules that interfere with the connection.
Hello, my equipment is routed locally, I can add the equipment without any problem to the dude and consult snmp, ping among other qualities, my problem is when I try to connect the dude to an MK either to update or manipulate it.
It gives me error as in the image that I show you, it should be noted that my IP address, user and password are correct and there are no firewall rules that prevent the connection
Hello, thanks for your prompt responses, I don’t know how to verify if the final team has permission, where can I verify it?
Basically I want to drive the Mikrotik from The Dude? Is that possible ? How do I do it?
I have seen that it is possible to update it from The dude according to the wiki manual but I cannot establish communication at that level between the dude and the device
If the user I am using has “full” permissions but still can’t connect, do you know any other way or steps I should follow?
because I have a lot of equipment and I would like to handle them from one place and update them at the same time instead of doing a manual job one by one
Is there anything valuable in the device’s logs when dude is trying to connect?
Does winbox run on the default port?
Can you confirm with torch, that dude packets are reaching the device?
As unfortunate as it is, for now there is no other way to do this, other than performing dst-nat.
And you can’t perform dst-nat for the packet originated from the router itself.
Instead of doing it on all 500 end devices you can place additional router between dude server and the network, to do it in one place (or use existing router, if all the traffic to end devices is routed through it).
Another possible workaround is to loop the traffic back to the dude server connecting two of it’s ports with a patchcord (of course if it is physical device, not a CHR).
