MikroTik DHCP server logs to rsyslog [TESTED]

Very quick note on how to configure logging for DHCP server running on MikroTik RouterOS, send and store syslog messages on CentOS 7.x using rsyslog. In our configuration MikroTik device will have IP, CentOS (syslog server) will have, we will store syslog messages received from address into /var/log/remotelogs/ folder in a file named “desired_file_name.log”.

MikroTik configuration:

/system logging action set 3 remote=
/system logging add action=remote topics=dhcp

CentOS 7.x configuration:

[root@centos7 ~]# vi /etc/rsyslog.conf

# Provides UDP syslog reception
$ModLoad imudp
$UDPServerRun 514

# Rules for remote logs
if $fromhost-ip=='' then /var/log/remotelogs/desired_file_name.log
& ~

Then we will need to restart rsyslog service:

[root@centos7 ~]# systemctl restart rsyslog

Then we can generate test log message on MikroTik device:

[admin@MikroTik] > :log info TEST

If our local firewall is not blocking UDP/514 incoming packets you should be able to see that message in target file you specified in configuration:

[root@centos7 ~]# tail -f /var/log/remotelogs/desired_file_name.log | grep TEST

2020-05-25T20:36:20.829911-07:00 host-1-1-1-1.example.com script,info TEST

The last piece is to configure logrotate. I will create a new file in “/etc/logrotate.d/” folder for that:

[root@centos7 ~]# vi /etc/logrotate.d/remotelogs

/var/log/remotelogs/*.log {
# keep 30 versions online
        rotate 3
# rotate each day
# compress/nocompress
# add a YYYYMMDD extension instead of a number
        /bin/kill -HUP `cat /var/run/syslogd.pid 2> /dev/null` 2> /dev/null || true

You can also forcibly run logrotate to see the result:

[root@centos7 ~]# logrotate -fv /etc/logrotate.d/remotelogs
[root@centos7 ~]# ls -lah /var/log/remotelogs/

Good luck!

MikroTik The Dude 6.46.3 or older can not connect to RouterOS 6.46.4 or newer.

I recently had to troubleshoot an issue with “The Dude” v6.46.3 that could not connect to MikroTik v6.46.5. Interestingly enough, target MikroTik devices was showing nothing in its logs (no successful or failed connection attemts). I don’t remember what The Dude was showing, but it was not anything specific that could help to understand what’s wrong like authentication failure.

Captured traffic dump was showing normal TCP session over port 8291 what was active for 30 seconds and then normally terminated by The Dude server. Crazy!

I remember seeing changes regarding Winbox authentication method in some of recent RouterOS release notes. Simple google search showed me this thread - v6.46.4 [stable] is released!:

To get RouterOS data from the devices, Dude now requires RouterOS to be 6.46.4 or newer. The other stats and of course Ping will still work. This is due to security measures being strengthened.

Sure enough, here is what Release notes for 6.46.4 says:

Important note!!!

- The Dude server must be updated to monitor 6.46.4 and v6.47beta30+ RouterOS type devices.
- The Dude client must be manually upgraded after upgrading The Dude server.
- To get RouterOS data from the devices, The Dude now requires RouterOS to be 6.46.4 or v6.47beta30+.

I decided to downgrade MikroTik device to 6.46.3, but it didn’t fully fix the issue. The Dude started showing some specific error:

std failure: not allowed (9), next attempt at 18:35:57

To fix that you have to add “dude” into “full” user group:

/user group
set full name=full policy=local,telnet,ssh,ftp,reboot,read,write,policy,test,winbox,password,web,sniff,sensitive,api,romon,dude,tikapp skin=default

Good luck!

Admin area