I cannot connect to my router via it’s IP and a web browser or WinBox or Telnet. It appears all my TCP traffic is going nowhere… but I’m not sure.
I set up a port forwarding DST-NAT to forward port 20-21 on TCP to a computer on my network. I don’t know the exact settings and can’t output them now because I can’t connect to my router. I obviously screwed something up with this rule. Also, I’m connecting to my network via an L2TP / IPSEC VPN and can’t get the router’s Mac address / I doubt it’d work over L2TP anyways with a MAC.
I can ping all hosts
I can traceroute -P UDP XX.XX.XX.XX (router IP) or any IP on my network
traceoute -P TCP XX.XX.XX.XX does not work for any IP or any port (I tried all my open ports, 20-21, SSH, etc.).
Trying to SSH on anything doesn’t work.
Doing NMAP on any IP address (including IPs that don’t exist) return a single port open (21). I’m guessing that’s a symptom of my screwed up rule above.
Doing TCP -sT NMAP on my router IP shows only dst-nat rules, which are above my screwed up one, properly (I have a hairpin nat that works properly before my mistake above). Port 80 / 23 or anything I could use on the router does not show up.
Doing NMAP with UDP -sU on my router shows 53, 137, 500, 1701, 4500 which are my L2TP/IPSEC, 137 is Netbios, and 53 is DNS. So it’s definitely routing to the correct device on UDP.
Any ideas how I can connect on my VPN? Also, since I can’t do anything via TCP, I can’t ssh / do any of the above techniques to any of my hosts on my network.
If anyone has any ideas of other tests I could run to figure out what exactly is going on, I’ll run them. Thank you.
When your dst-nat rule was so broad that it now catches all TCP traffic even via your VPN, you can still connect to the router locally via MAC address (from Winbox).
That will not be possible remotely so you need to go to the site of your router.
Next time you are experimenting, be sure to hit the “safe mode” button before you do things like this, and again after you verified everything is OK.
When you had done that, it would have removed the changes you made.
Thank you pe1chl. I will follow that advice for next time. I won’t be home for another week… so I was hoping there was some solution remotely with a good VPN, but it looks like there isn’t.
Strange. As we do not know what exactly happened, and it is a router without RS232 port, it is difficult to proceed from there.
Best is then to reset the config (powerup with paperclip in the reset hole, wait until the LED starts blinking, then release the reset immediately)
and then reconfigure it from scratch or load the latest backup and configure from there.
From the “inside” interfaces: set up /tool mac-server, then use /tool mac-telnet from another MikroTik to connect to it. I have multiple MikroTik routers set up to help recover using mac-telnet. You can find mac-telnet code online that might compile on Linux as well.
From the “outside” interfaces: set up /ip cloud (and save the DNS name somewhere), and also possibly IPv6. You can secure the connections with port knocking or ipsec if you need. I use IPv6 as an out of band connection when I mess up IPv4 since the 2 are not related at all when changing your IPv4 settings.
Not sure. I think not. Here is a standard router (I think):
[me@MikroTik] > /tool mac-server print
allowed-interface-list: none
[me@MikroTik] > /tool mac-server set allowed-interface-list=
AllowedInterfaceList ::= all | none | dynamic | discover | mac-winbox
all -- contains all interfaces
dynamic -- contains dynamic interfaces
none -- contains no interfaces
I’m asking in another thread about LLDP what a “dynamic” interface is and why we can’t control this on a per interface basis anymore.
Enabling this on “all” means your internet facing interface will have mac-server enabled which isn’t so desirable. I have a commercial switch between my cable modem and router to prevent layer 2 vulnerabilities like this.
In the 6.41 version the enabling of mac-telnet mac-winbox and ip neighbor discovery is no longer done using flags per interface, but using
the new “interface list” feature introduced recently. Now you can create your own interface list (in the interfaces menu) and use it
to enable mac-telnet and mac-winbox on some interfaces. When you had manually set some interfaces in 6.40 or earlier and upgraded
in-place, it has automatically converted by creating interface lists and populating them according to your old settings.
New here…but maybe you can use ipv6 link local address to connect SSH to the box.
link local address can be derived from MAC address, still visible in arp table of your computer
Thank you for all the ideas. The worst part of having to factory reset is that I won’t know what went wrong. I wish there were other tests I could do to see what exactly was happening to the traffic.
By the way, my buddy could SSH other users from inside my network. It appears my issue only occurs on traffic which touches the router (which I guess makes sense since they are on the same Subnet and the host would use ARP while not on a VPN).
