I have (yet another) location where the MT device is unresponsive.
I lost Wireguard connectivity, but I can ping it. No response to telnet, ssh or mac telnet.
I understand it is not advised, and there has been a (warranted) scare of two, but how insecure is leaving port 8291 (Winbox) open to the Internet?
Is there any other way I can leave a way to get in?
Thanks.
ZeroTier if ARM since it will try a few different path to connect, and not as exposed to configuration issues that WG would be firewall/etc.
Winbox does not use very good encryption and does not have robust DoS features is why it’s not generally recommended to be open to internet. But same logic kinda apply to SSH, although you can use stronger keys.
[IP] Telnet being enabled is worse than winbox however.
If you can ping it, it should be reachable.
You can also use port-knocking scheme ?
Or other VPN protocol as backup (IPSEC / SSTP / …) ?
Yup, some backup VPN might be a good idea.
Beyond ZeroTier. If you have two Mikrotik, SSTP is pretty trivial to setup between them. L2TP is also pretty easy to configure if you need VPN from a desktop. Or even a container with CloudFlare ZeroTrust WARP tunnel be another option too, although way more complex to setup.
If you have some central Mikrotik router, another option might be EoIP+IPSec connected from remotes to the central router. If you enable RoMON on all the routers… then you connect the central router via winbox+romon, you’d see all the remotes via the EoIP tunnels. The EoIP do NOT need to be bridged to anything, and it’s “Use IPSec” option make encryption pretty trivial.
The nice option here is RoMON runs independent of firewall, and EoIP makes it look like a LAN to RoMON. And if NOT bridged, just a plain interface, it should just carry RoMON.
Yup.
Well known concept to me.
I use Romon via unbridged EOIP over Wireguard quite frequently, works brilliantly for this purpose.
Telnet is not enabled on any of my devices.
The only way to access any of my devices is by being on the LAN or connected via WG.
Many of my devices are hEX, so not ARM.
I had someone go and cycle the power, and I know it comes back up because I have a netwatch script that emails when connectivity to the upstream (provider’s) router changes from up to down and from down to up.
And I can ping the device.
But the WG tunnel is down and I have no access to it. And I really don’t want to make the trip there, or buy/configure/overnight a new AC3.
I do have cloud DDNS enabled, so I have the DDNS name, but that’s not helping get into the device.
Anything else I can try?
Thanks.
So the dyndns address check out to the current WANIP of the remote device and you can ping the device but WG does not come up??
Did you make any changes to the config prior to losing connectivity as there is no clear reason I can think of that would cause loss of connectivity.
I have been had on my to-do list to play with EoIP for a while.
Can EoIP be set up between MT devices independently of Wireguard?
I ask because the WG tunnel is not up to that device, so if EoIP relied on it, EoIP would not work.
I don’t know how to set it up.
Well, I can’t be sure of the wan up address without being at the site (I believe).
Absolutely no changes were made to the MT device at that location. Internet service went down but then came back up. I had the MT device power cycled. That’s all.
EOIP works between two IP addresses and doesn’t care about how its packets move from point A to point B. So one can use any kind of connectivity to do the job. Since EOIP doesn’t do any encryption, it’s wise to use something that does it. IPsec is fine, wireguard is fine, etc.
Only point was EoIP is easily encrypted with the “Use IPSec” checkbox, which uses a PSK defined on EoIP interface… which is kinda handy. Since pure IPSec is a lot of config…
And if you mess-up a firewall config remotely, you’d want some Layer2 VPN IMO.
It sounds like a great.
I’m concerned (don’t know if justified) that doing this will create one large broadcast lan. I’m sure there are good ways to prevent all traffic on all eoip-connected devices from hearing each other. Something better than a firewall drop rule.
Interesting proposal I always used SSTP ( mt to mt approach ) without certificates as my preferred Mt to Mt backup to wireguard.
Before ros7 and wireguard, sstp was also my choice for direct connection.
Yeah but without certificate how safe is it… As for IPIP sounded better, more secure than SSTP without certificate BUT, a big BUTT, is that it appears BOTH sides need to have publicly reachable WANIPs ( and maybe even static ones ). All the clowns at MT and youtube always show the easy EFFING lab examples of two static WANIPS. If so, then IPIP is useless…
Hence SSTP remains better as only only needs one reachable public IP.
The Let’s Encrypt certificate obtained with /certificate/enable-ssl-certificate can be used for SSTP without problems. Everything then works with the built-in SSTP client on Windows and no site-to-site configuration is needed if we just want an emergency entry point to the router. The downside is that the certificate setting needs to be updated every 3 months, the LE auto-update feature currently only modifies the www-ssl setting, not the SSTP Server setting (beside that the LE auto-update feature should not be relied on anyway, because it requires WebFig on port 80 to be permanently exposed to the internet, and who wants that?).
SSTP sounds very interesting.
Renewing a certificate every 3 months does like a recipe for disaster.
Any downside to using SSTP without a cert?
I like the idea of EoIP because of the advantages of layer 2 connectivity to all devices, but I am concerned about traffic or taxing the MT devices with firewall rules.
I would use EOIP or IPIP before SSTP, but both of those require two publicly reachable IP addresses at both ends, which removes about 95 of use cases, I run up against.
The idea is EoIP just carries RoMON protocol. If EoIP is NOT bridge to anything, and each end has a unique IP address in same subnet (and subnet it NOT used by anything else), there shouldn’t be much traffic since nothing route to it. I would NOT use EoIP to replace your existing WG – use that for normal traffic. The idea here is to have some “backup” management interface beyond WG (e.g. in case you misconfigured WG remotely).
The trick is since EoIP is ethernet-like interface, it works with RoMON. And since RoMON on a local router will find more routers on other “real” ethernet lines. So if the EoIP terminated at some central router, it be able to see anything with RoMON enabled – even if it’s two hops aways (e.g. hub router --(eoip)–> remote --(etherX)–> ap).
There is nothing special to configure on RoMON to use EoIP, other making sure RoMON is enabled and secrets match. You can limit the interface RoMON will use, but obviously it have to include at least the EoIP interface (under ports).