After enabling VLAN filtering on my MikroTik CRS310-8G+2S+ switch with an incorrect configuration, I lost all management access. The switch was unreachable via SSH, web UI, and ping. This post documents the recovery process using MAC-Telnet to regain access at Layer 2.
The Problem
The switch had VLAN filtering enabled with the uplink port (ether5, connected to OPNsense) configured as tagged for VLAN 1 when it should have been untagged. This meant:
- Management traffic from the switch was being sent with VLAN tags
- OPNsense expected untagged traffic on that interface
- The switch became unreachable from the network
$ ping 192.168.4.101
PING 192.168.4.101 (192.168.4.101) 56(84) bytes of data.
--- 192.168.4.101 ping statistics ---
3 packets transmitted, 0 received, 100% packet loss
SSH and the web interface also failed to connect.
Network Topology
┌─────────────────┐
│ OPNsense │
│ 192.168.4.1 │
└────────┬────────┘
│ (expects untagged)
│
┌────────┴────────┐
│ MikroTik CRS310│
│ 192.168.4.101 │ (unreachable)
│ ether5 │ (sending tagged - wrong!)
└────────┬────────┘
│
┌────────┴────────┐
│ LAN Devices │
└─────────────────┘
Recovery Options
When locked out of a MikroTik device, the options are:
| Method | Requires | Preserves Config |
|---|---|---|
| MAC-Telnet | Layer 2 access to any port | Yes |
| Serial console | Physical serial connection | Yes |
| Reset button (5s) | Physical access | Loads backup config |
| Reset button (10s+) | Physical access | No (factory reset) |
MAC-Telnet was the best option since it works at Layer 2 regardless of IP configuration and preserves the existing configuration.
Step 1: Direct Physical Connection
Connected a laptop directly to port 1 (ether1) on the switch using a USB ethernet adapter.
$ ip addr show enp9s0u1u4u3
18: enp9s0u1u4u3: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500
link/ether a4:4c:c8:af:4e:cf brd ff:ff:ff:ff:ff:ff
The interface showed link UP but had no IP address assigned.
Step 2: Verify the Switch is Alive
Used tcpdump to check for any traffic from the switch:
$ sudo tcpdump -i enp9s0u1u4u3 -n
18:54:38.965030 STP 802.1w, Rapid STP, Flags [Proposal, Learn, Forward],
bridge-id 8000.04:f4:1c:1c:96:90.8001, length 36
18:54:40.962066 IP 0.0.0.0.bootpc > 255.255.255.255.bootps: BOOTP/DHCP,
Request from 04:f4:1c:1c:96:90, length 300
The switch was sending:
- STP (Spanning Tree Protocol) packets
- DHCP requests (trying to get an IP address)
This revealed the switch MAC address: 04:f4:1c:1c:96:90
Step 3: Build MAC-Telnet from Source
The mactelnet package is not available in Fedora repositories. Built it from source:
cd /tmp
git clone --depth 1 https://github.com/haakonnessjoen/MAC-Telnet.git
cd MAC-Telnet
./autogen.sh
make
Step 4: Scan for MikroTik Devices
Used MNDP (MikroTik Neighbor Discovery Protocol) to find the switch:
$ /tmp/MAC-Telnet/src/mndp -i enp9s0u1u4u3
Searching for MikroTik routers... Abort with CTRL+C.
IP MAC-Address Identity (platform version hardware) uptime
0.0.0.0 04:f4:1c:1c:96:90 MikroTik (MikroTik 7.20.6 (stable) CRS310-8G+2S+) up 0 days 2 hours
The switch appeared with IP 0.0.0.0 confirming it had no IP address assigned.
Step 5: Connect via MAC-Telnet
MAC-Telnet requires root for raw socket access:
$ sudo /tmp/MAC-Telnet/src/mactelnet -u admin 04:f4:1c:1c:96:90
This opened a RouterOS terminal session directly via Layer 2, bypassing the IP stack entirely.
Step 6: Diagnose the VLAN Configuration
Checked the bridge VLAN table:
[admin@MikroTik] > /interface bridge vlan print
Flags: D - DYNAMIC
# BRIDGE VLAN-IDS CURRENT-TAGGED CURRENT-UNTAGGED
0 bridge 1 ether5 ether7
1 bridge 100 ether5 ether6
2 D bridge 1 bridge, ether1
The problem: Entry 0 showed ether5 as tagged for VLAN 1. Since OPNsense sends untagged traffic, the switch was tagging outbound management traffic which OPNsense then dropped.
Step 7: Restore Management IP
First, added the management IP back:
/ip address add address=192.168.4.101/24 interface=bridge
/ip route add gateway=192.168.4.1
Attempted to fix the VLAN configuration:
/interface bridge vlan remove 0
/interface bridge vlan add bridge=bridge vlan-ids=1 tagged=bridge untagged=ether1,ether5,ether7
This still did not restore connectivity. The safest approach was to disable VLAN filtering entirely:
/interface bridge set bridge vlan-filtering=no
The MAC-Telnet session dropped as the bridge reconfigured, but the switch was now reachable:
$ ping 192.168.4.101
PING 192.168.4.101 (192.168.4.101) 56(84) bytes of data.
64 bytes from 192.168.4.101: icmp_seq=1 ttl=64 time=0.550 ms
64 bytes from 192.168.4.101: icmp_seq=2 ttl=64 time=0.256 ms
Step 8: Backup the Configuration
With access restored, created backups:
$ ssh [email protected] '/system/backup/save name=post-recovery'
Configuration backup saved
$ ssh [email protected] '/export file=post-recovery-config'
$ scp [email protected]:post-recovery.backup ./
$ scp [email protected]:post-recovery-config.rsc ./
The Root Cause
The VLAN misconfiguration occurred when setting up VLANs with the following incorrect entry:
/interface bridge vlan add bridge=bridge tagged=ether5 untagged=ether7 vlan-ids=1
This made ether5 (the uplink to OPNsense) a tagged port for VLAN 1. Since OPNsense was configured to receive untagged traffic on that interface, all management traffic from the switch was dropped.
The correct configuration should have ether5 as untagged for VLAN 1:
/interface bridge vlan add bridge=bridge tagged=bridge untagged=ether1,ether5,ether7 vlan-ids=1
Lessons Learned
- Always have console access available before enabling VLAN filtering on a managed switch
- MAC-Telnet is essential for MikroTik recovery - build it before you need it
- Test VLAN changes incrementally rather than enabling filtering with a complex configuration
- Backup before VLAN changes - MikroTik’s safe mode (
/system/safe-mode) can auto-revert if you lose connectivity - The bridge interface needs to be in the management VLAN either tagged or untagged for management access to work
Current Configuration State
The switch is now running with VLAN filtering disabled:
/interface bridge
add admin-mac=04:F4:1C:1C:96:90 auto-mac=no name=bridge
/interface bridge port
add bridge=bridge interface=ether1
add bridge=bridge interface=ether5
add bridge=bridge interface=ether6 pvid=100
add bridge=bridge interface=ether7
# ... remaining ports
/interface bridge vlan
add bridge=bridge tagged=ether5 untagged=ether6 vlan-ids=100
add bridge=bridge tagged=bridge untagged=ether1,ether5,ether7 vlan-ids=1
/ip address
add address=192.168.4.101/24 interface=bridge network=192.168.4.0
/ip route
add gateway=192.168.4.1
To re-enable VLAN filtering safely in the future:
/interface bridge set bridge vlan-filtering=yes
This will activate the VLAN configuration. If something goes wrong, physical console access or MAC-Telnet from a directly connected device will be required to recover.